Sjors Provoost [ARCHIVE] on Nostr: 📅 Original date posted:2018-08-01 📝 Original message: +1 on this idea, no ...
📅 Original date posted:2018-08-01
📝 Original message:
+1 on this idea, no opinion on data structure
> Op 29 jul. 2018, om 15:43 heeft Robert Olsson <robban at robtex.com> het volgende geschreven:
>
>
> Regarding abuse:
> Nodes checking blockchain can discard erroneous messages. If the messages slip thru to a wallet that doesn't verify, how much could this possibly hurt and where? Today for instance Eclair assumes all channels are wide enough anyhows.
>
> Regarding bandwidth:
> Nodes should not broadcast updates after every packet, but do it wisely. And optionally. You could just announce the original capacity.
And Christian Decker wrote:
> (incidentally that is the main reason we started tracking an internal
> UTXO set so we can stop asking bitcoind for full blocks just to check a
> channel's capacity).
This could be very useful for fresh pruned nodes. When they receive gossip from before their birth, they would simply take notice in order to construct a map of the network, but hold off on fetching historical blocks to verify. Only when they need to make a payment, they would generate a bunch of candidate routes and fetch the relevant blocks to see if those channels were really created (and the UTXO set to make sure it's not closed).
It could still leave a bit of DOS risk if you gossip lies about lots of potentially useful channels in every historical block, forcing the pruned node to fetch these blocks one by one. Perhaps that can mitigated by a strong preference for channels created after wallet birth. There could also be cap on how many historical blocks are fetched before giving up. Anyway, this proposal doesn’t change that risk profile.
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/d3405fae/attachment.sig>;
📝 Original message:
+1 on this idea, no opinion on data structure
> Op 29 jul. 2018, om 15:43 heeft Robert Olsson <robban at robtex.com> het volgende geschreven:
>
>
> Regarding abuse:
> Nodes checking blockchain can discard erroneous messages. If the messages slip thru to a wallet that doesn't verify, how much could this possibly hurt and where? Today for instance Eclair assumes all channels are wide enough anyhows.
>
> Regarding bandwidth:
> Nodes should not broadcast updates after every packet, but do it wisely. And optionally. You could just announce the original capacity.
And Christian Decker wrote:
> (incidentally that is the main reason we started tracking an internal
> UTXO set so we can stop asking bitcoind for full blocks just to check a
> channel's capacity).
This could be very useful for fresh pruned nodes. When they receive gossip from before their birth, they would simply take notice in order to construct a map of the network, but hold off on fetching historical blocks to verify. Only when they need to make a payment, they would generate a bunch of candidate routes and fetch the relevant blocks to see if those channels were really created (and the UTXO set to make sure it's not closed).
It could still leave a bit of DOS risk if you gossip lies about lots of potentially useful channels in every historical block, forcing the pruned node to fetch these blocks one by one. Perhaps that can mitigated by a strong preference for channels created after wallet birth. There could also be cap on how many historical blocks are fetched before giving up. Anyway, this proposal doesn’t change that risk profile.
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180801/d3405fae/attachment.sig>;