From rusty at rustcorp.com.au Mon Oct 24 22:32:52 2022 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 25 Oct 2022 09:02:52 +1030 Subject: [Lightning-dev] Fat Errors In-Reply-To: References: Message-ID: <87tu3s97jf.fsf@rustcorp.com.au> Joost Jager 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.