Devs,

One sketch of an idea on how to improve Eltoo like constructions by making
the contract "optically isolated".


Create an output F with:

Amount: A, Key: MuSig(A,B)

Create a second output R with:

Amount: Dust, Key: Musig(A', B')

and sign ratchet updates something like:

Amount: Dust, Key: tr(Musig(A', B'), {OP_1 CHECKSIG <N> CLTV, <Timeout> CSV
OP_1 CHECKSIG 0 OP_CHECKINPUTOUTPOINT <F> EQUAL})

And also sign a Tx where {F, R using path with OP_CHECKINPUT} -> {A's
amount, B's amount}.
F's signature must commit to R's script for Ratchet with N, but not R's
TXID.


Why go through the trouble of two UTXOs per channel? Is it even two
channels?

Here are some properties this 'flipped channel' might have. Are there
others you can think of?

1) Privacy: funds are unlinked from being a channel until end of contested
close period. All Ratchet txns look the same on the network, harder for
third parties to shake you down for more fees.
2) Reuse: Ratchet can be reused if channel cooperatively closes / splits
funds out
3) Cooperative close can't be pinned by past reveals of ratchet state for
M-N channels
4) Ratchet can create multiple ratchet outputs at a time to drive multiple
channel balances -- updating ratchet requires N-N, but each
subfunds requires only M-M
6) Some types of issue in the ratchet protocol still permits recovery in
the custody layer
7) If you still want to carry value along the ratchet, you can splice in
funds indirectly into that ratchet without linking the funds on-chain
(e.g., in a channel factory, can use the trick in 4 to dynamically add a
sub M-M of the N-N for a new separate balance), only linked on
uncooperative closes.

I know this is handwave WRT the sighash flags/opcodes required, but I'm
merely here to inspire and figured the idea of abstracting the ratchet was
novel.

Best,

Jeremy






--
@JeremyRubin <https://twitter.com/JeremyRubin>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to