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 <ru...@rustcorp.com.au> wrote: > Joost Jager <joost.ja...@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. >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
