Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-10 📝 Original message: Let's say you're about to ...
📅 Original date posted:2021-07-10
📝 Original message:
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.,
start at: IF "N+1" CLTV DROP <pk_u> CHECKSIG ELSE 2016 CSV DROP <pk_s_i>
CHECKSIG ENDIF
before N+1 = last, sign a txn with pk_s_last that moves coins to
IF "1" CLTV DROP <*pk_u**2*> CHECKSIG ELSE 2016 CSV DROP <pk_s_i> CHECKSIG
ENDIF
This essentially lets you do 32 bits worth of updates and then fwd to a new
contract by paying 1x extra transaction.
This is potentially better than just directly closing because we keep it
off chain for longer. However... this also adds an additional CSV.
(We can get around this by modifying the script branch which ends a CLTV
domain with:
<pk_s_last> CHECKSIG
since any updates past that point are done through the continuation
state... but let's ignore that for the next part)
What if we *always* used this every update? Then we'd essentially have 64
bits of sequence space. Each layer of this trick adds 32 bytes.
Doing layers like this inherently adds a bunch of CSV layers, so it
increases resolution time linearly.
One possibility to mitigate this is to do a "semitrusted burst mode" with a
counterparty. Suppose you're at sequence M and it's a normal txn.
Party A requests to Party B to initiate burst mode. A and B move to
sequence M+1 where state M+1 passes through to a 2 step Eltoo update.
This burst now has 32 bits of sequences to blow through.
B or A then indicates to the other party to terminate the burst at
"internal state number" Q. Then B and A sign M+2 where M+2 reflects the
last state at internal state number Q. This gets rid of the temporary extra
locking time for when parties are offline.
This has a benefit for privacy as well because if this protocol is used,
then top level state numbers do not reflect the # of payments strongly as
they're more akin to how many burst mode payments were done.
The semi trusted nature of this is that if a malicious peer induces you
into starting this, you double your funds lockup time. There are some
mitigations:
1) Only enter burst mode with long lived peers
2) Only enter burst mode when initiator has more funds in the channel than
you (or has some ratio) which imposes an opportunity cost for attacking.
3) Only allow a certain % of liquidity to be moved during a burst -- e.g.,
any time the delta in balance goes above a threshold, force a higher order
channel state update.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/1267b270/attachment.html>;
📝 Original message:
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.,
start at: IF "N+1" CLTV DROP <pk_u> CHECKSIG ELSE 2016 CSV DROP <pk_s_i>
CHECKSIG ENDIF
before N+1 = last, sign a txn with pk_s_last that moves coins to
IF "1" CLTV DROP <*pk_u**2*> CHECKSIG ELSE 2016 CSV DROP <pk_s_i> CHECKSIG
ENDIF
This essentially lets you do 32 bits worth of updates and then fwd to a new
contract by paying 1x extra transaction.
This is potentially better than just directly closing because we keep it
off chain for longer. However... this also adds an additional CSV.
(We can get around this by modifying the script branch which ends a CLTV
domain with:
<pk_s_last> CHECKSIG
since any updates past that point are done through the continuation
state... but let's ignore that for the next part)
What if we *always* used this every update? Then we'd essentially have 64
bits of sequence space. Each layer of this trick adds 32 bytes.
Doing layers like this inherently adds a bunch of CSV layers, so it
increases resolution time linearly.
One possibility to mitigate this is to do a "semitrusted burst mode" with a
counterparty. Suppose you're at sequence M and it's a normal txn.
Party A requests to Party B to initiate burst mode. A and B move to
sequence M+1 where state M+1 passes through to a 2 step Eltoo update.
This burst now has 32 bits of sequences to blow through.
B or A then indicates to the other party to terminate the burst at
"internal state number" Q. Then B and A sign M+2 where M+2 reflects the
last state at internal state number Q. This gets rid of the temporary extra
locking time for when parties are offline.
This has a benefit for privacy as well because if this protocol is used,
then top level state numbers do not reflect the # of payments strongly as
they're more akin to how many burst mode payments were done.
The semi trusted nature of this is that if a malicious peer induces you
into starting this, you double your funds lockup time. There are some
mitigations:
1) Only enter burst mode with long lived peers
2) Only enter burst mode when initiator has more funds in the channel than
you (or has some ratio) which imposes an opportunity cost for attacking.
3) Only allow a certain % of liquidity to be moved during a burst -- e.g.,
any time the delta in balance goes above a threshold, force a higher order
channel state update.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210710/1267b270/attachment.html>;