From aj at erisian.com.au Sun Jul 11 04:10:00 2021 From: aj at erisian.com.au (Anthony Towns) Date: Sun, 11 Jul 2021 14:10:00 +1000 Subject: [Lightning-dev] Eltoo Burst Mode & Continuations In-Reply-To: Message-ID: <20210711041000.GB4597@erisian.com.au> On Sat, Jul 10, 2021 at 02:07:02PM -0700, Jeremy wrote: > Let's say you're about to hit your sequence limits on a Eltoo channel... Do you > have to go on chain? > No, you could do a continuation where for your *final* update, you sign a move > to a new update key. E.g., That adds an extra tx to the uncooperative path every 2**30 states. > Doing layers like this inherently adds a bunch of CSV layers, so it increases > resolution time linearly. I don't think that's correct -- you should be using the CLTV path for updating the state, rather than the CSV path; so CSV shouldn't matter. On Sat, Jul 10, 2021 at 04:25:06PM -0700, Jeremy wrote: > [...] signing a eltoo "trampoline". > essentially, begin a burst session at pk1:N under pk2, but always include a > third branch to go to any pk1:N+1. I think this is effectively reinventing/special casing channel factories? That is you start an eltoo channel factory amongst group {A,B,C,...}, then if {A,B} want an eltoo channel, that's a single update to the factory; that channel can get updated independently until A and B get bored and want to close their channel, which is then a single additional update to the factory. In this case, the factory just doesn't include the additional members {C,...}. On Sat, Jul 10, 2021 at 05:02:35PM -0700, Jeremy wrote: > suppose you make a Taproot tree with N copies (with different keys) of the > state update protocol. This feels cleverer/novel to me -- but as you point out it's actually more costly than the trampoline/factory approach so perhaps it's not that great. I think what you'd do is change from a single tapscript of "OP_1 CHECKSIG <500e6+i> CLTV" to a tree of tapscripts: " CHECKSIG <500e6+j+1> CLTV" so if your state is (i*2**30 + j) you're spending using with a locktime of 500e6+j, and you're allowing later spends with the above script filled in with (i,j) or (i',0) for i You can take a random path through which leaf you are using which, if you're > careful about how you construct your scripts (e.g., keeping the trees the same > size) you can be more private w.r.t. how many state updates you performed > throughout the protocol (i.e., you can see the low order bits in the CLTV > clause, but the high order bits of A, B, C's relationship is not revealed if > you traverse them in a deterministically permuted order). Tapscript trees are shuffled randomly based on the hashes of their scripts, so I think that's a non-issue. You could keep the trees the same size by adding scripts " CHECKSIG <500e6+j+1> RETURN". > The space downside of this approach v.s. the approach presented in the prior > email is that the prior approach achieves 64 bits with 2 txns one of which > should be like 150 bytes, a similar amount of data for the script leaves may > only gets you 5 bits of added sequence space.? You'd get 2**34 states (4 added bits of added sequence space) for about 161 extra bytes (4 merkle branches at 32B each and revealing the pubkey for 33B), compared to about 2**60 states (2**30 states for the second tx, with a different second tx for each of the 2**30 states of the first tx). Haven't done the math to check the 150 byte estimate, but it seems the right ballpark. Cheers, aj