Regarding ping flooding, if it is problematic, the best solution is probably including a small proof-of-work with the ping, similar to BIP 154. However, the whole purpose of the ping in the first place is to be a cheaper way to collect routing information than attempting to send a payment, so I think adding a PoW starts to become counterproductive. Note that the sender needs to expend a certain amount of computation just creating the onion packet up front (on the order of a few ms, I believe), so perhaps that is sufficient.
Also, if someone wanted to DoS the network, there are much better ways than using this proposed ping mechanism. For example, someone can send payments along any circuit with a randomly generated payment hash (for which the preimage is unknown), and force a payment failure at the end of the route. That is basically a way to ping that works now, but is more expensive for everyone. On Thu, Mar 1, 2018 at 4:16 PM, gb <kiw...@yahoo.com> wrote: > .... and any thoughts on protections against flood pinging? > > On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote: > > > > The main benefit is that this should make it quicker to send a > > successful payment because latency is lower than sending an actual > > payment and the sender could ping all possible routes in parallel, > > whereas they can't send multiple payments in parallel. The main > > downside I can think of is that, by the same token, it is faster and > > cheaper for someone to extract information about channel capacities on > > the network with a binary search. > > > > > > -jimpo > > _______________________________________________ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
