Jim Posen [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-02 📝 Original message: Regarding ping flooding, ...
📅 Original date posted:2018-03-02
📝 Original message:
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 <kiwigb at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180302/e1a8e668/attachment.html>;
📝 Original message:
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 <kiwigb at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180302/e1a8e668/attachment.html>;