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: "<P_i> CHECKSIG <500e6+j+1> CLTV" so if your state is (i*2**30 + j) you're spending using <P_i> 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<i'<N. That means you're paying extra to specify a merkle path of lg(N)*32 and the key P_i (33 bytes). > 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 "<P_i> 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev