Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-11 📝 Original message: On Sat, Jul 10, 2021 at ...
📅 Original date posted:2021-07-11
📝 Original message:
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
📝 Original message:
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