Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-01 📝 Original message: Hey Rusty, Great to hear ...
📅 Original date posted:2022-11-01
📝 Original message:
Hey Rusty,
Great to hear that you want to try to implement the proposal. I can polish
my golang proof of concept code a bit and share if that's useful? It's just
doing the calculation in isolation. My next step after that would be to see
what it looks like integrated in lnd.
16 hops sounds fine to me too, but in general I am not too concerned about
the size of the message. Maybe a scheme is possible where the sender
signals the max number of hops, trading off size against privacy. Probably
an unnecessary complication though.
I remember the prepay scheme, but sounds quite a bit more invasive than
just touching encode/relay/decode of the failure message. You also won't
have the timing information to identify slow nodes on the path.
Joost.
On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Joost Jager <joost.jager at gmail.com> writes:
> > Hi list,
> >
> > I wanted to get back to a long-standing issue in Lightning: gaps in error
> > attribution. I've posted about this before back in 2019 [1].
>
> Hi Joost!
>
> Thanks for writing this up fully. Core lightning also doesn't
> penalize properly, because of the attribution problem: solving this lets
> us penalize a channel, at least.
>
> I want to implement this too, to make sure I understand it
> correctly, but having read it twice it seems reasonable.
>
> How about 16 hops? It's the closest power of 2 to the legacy hop
> limit, and makes this 4.5k for payloads and hmacs.
>
> There is, however, a completely different possibility if we want
> to use a pre-pay scheme, which I think I've described previously. You
> send N sats and a secp point; every chained secret returned earns the
> forwarder 1 sat[1]. The answers of course are placed in each layer of
> the onion. You know how far the onion got based on how much money you
> got back on failure[2], though the error message may be corrupted.
>
> Cheers,
> Rusty.
> [1] Simplest is truncate the point to a new secret key. Each node would
> apply a tweak for decorrelation ofc.
> [2] The best scheme is that you don't get paid unless the next node
> decrypts, actually, but that needs more thought.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221101/2872425f/attachment.html>;
📝 Original message:
Hey Rusty,
Great to hear that you want to try to implement the proposal. I can polish
my golang proof of concept code a bit and share if that's useful? It's just
doing the calculation in isolation. My next step after that would be to see
what it looks like integrated in lnd.
16 hops sounds fine to me too, but in general I am not too concerned about
the size of the message. Maybe a scheme is possible where the sender
signals the max number of hops, trading off size against privacy. Probably
an unnecessary complication though.
I remember the prepay scheme, but sounds quite a bit more invasive than
just touching encode/relay/decode of the failure message. You also won't
have the timing information to identify slow nodes on the path.
Joost.
On Tue, Oct 25, 2022 at 9:58 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Joost Jager <joost.jager at gmail.com> writes:
> > Hi list,
> >
> > I wanted to get back to a long-standing issue in Lightning: gaps in error
> > attribution. I've posted about this before back in 2019 [1].
>
> Hi Joost!
>
> Thanks for writing this up fully. Core lightning also doesn't
> penalize properly, because of the attribution problem: solving this lets
> us penalize a channel, at least.
>
> I want to implement this too, to make sure I understand it
> correctly, but having read it twice it seems reasonable.
>
> How about 16 hops? It's the closest power of 2 to the legacy hop
> limit, and makes this 4.5k for payloads and hmacs.
>
> There is, however, a completely different possibility if we want
> to use a pre-pay scheme, which I think I've described previously. You
> send N sats and a secp point; every chained secret returned earns the
> forwarder 1 sat[1]. The answers of course are placed in each layer of
> the onion. You know how far the onion got based on how much money you
> got back on failure[2], though the error message may be corrupted.
>
> Cheers,
> Rusty.
> [1] Simplest is truncate the point to a new secret key. Each node would
> apply a tweak for decorrelation ofc.
> [2] The best scheme is that you don't get paid unless the next node
> decrypts, actually, but that needs more thought.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221101/2872425f/attachment.html>;