On Tue, Dec 13, 2022 at 08:22:55PM -0500, Antoine Riard wrote:
> > prior to (1): UA.k (k <= n) -- However this allows Bob to immediately
> > broadcast one of either CA.n or RA.n, and will then have ~150 blocks
> > to claim the HTLC before its timeout
> From my understanding, with two party eltoo w/punihsment, UA.k has a
> tapscript path with "1 CHECKSIGVERIFY k<n CLTV", where the internal pubkey
> substituted is "musig(A,B)/1. Mallory should receive Bob's signature for
> UA.k, though also UA.k+1, UA.k+2, UAk+3, until k=n.
Yes, Mallory can be assumed to be able to generate signatures for UA.0
through UA.n. They all spend the funding transaction (only) though,
so she can only choose one of them, which I called UA.k above.
More particular, I'm imagining scriptPubKeys something like:
F: taproot(AB)
UA.n: taproot(AB/1, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
WB.n: taproot(AB/1, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
UB.n: taproot(AB/2, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
WA.n: taproot(AB/2, "IF CODESEP <n> CLTV DROP ENDIF OP_1 CHECKSIG")
where AB=musig(A,B) and AB/1 and AB/2 are unhardened HD subkeys of AB.
(The outputs of SA/RA/CA and SB/RB/CB are the balances and active HTLCs)
Then I think the following setup works to allow each transaction to only
spend from the transactions that it's supposed to:
UA.n have ALL or SINGLE|ANYONECANPAY signatures spending F with key
AB.
CA.n/WA.n have ANYPREVOUTANYSCRIPT signatures with codesep_pos=2
against AB/2, with locktime set to n
RA.n has an ANYPREVOUTANYSCRIPT signature with codesep_pos=2
against AB/2, with locktime set to n-1
SA.n has an ANYPREVOUT signature with codesep_pos=FFFFFFFF
against AB/1, with nSequence enforcing to_self_delay
B's signatures are similar, swapping AB/2 and AB/1.
(In order to do the fast forward stuff via scriptless scripts, you also
need F to have an "A CHECKSIGVERIFY B CHECKSIG" tapscript path as well,
and there's probably other things I've glossed over)
> Or is this a tapscript only existing for the dual-funding case ? I think
> this a bit unclear from the gist construction, how Mallory is restrained to
> use the tapscript path on UA.k, with UA.k+1 as she should be in possession
> of Bob's signature for this state.
You lock Mallory into using a particular signature with a particular
script template by only using the key for that signature within that
script template, and you lock them into using a particular path through
that script via use of OP_CODESEPARATOR.
> While update transaction 1 could spend update transaction 0 immediately,
> there is no reliable knowledge by U*.1 transaction broadcaster of the state
> of the network mempools.
That doesn't need to be true; we can easily have lightning nodes
gossip mempool state for channel closes by pattern matching on the
close transaction, including offering "catchup" info for nodes that
were offline, even if that isn't something we do for regular mempool
transactions.
I don't really think getting into the weeds on that now is very productive
though; it's still an open question whether we can get eltoo working in
a laboratory environment, let alone in the wild.
> While I think this solution of eltoo nodes quickly replacing any state K
> previous to the latest state N, there is no guarantee the latest state K
> doesn't offer a higher feerate than state N, making it more attractive to
> the miners.
I think there's really two situations here: one is where miners are
just running friendly mempool software that tries to do right by the
network, in which case "always update to the newest state, even if the
fee rate goes down" is probably workable; the other is where miners want
to profit maximise on every single block and will run MEV software; in
which case all we need is for the final state to be relayed -- provided
its at a reasonable feerate, the MEV miner will include it on top of the
high-fee paying chain of earlier states, even if that would mean it has
"too many" in-mempool descendants.
Cheers,
aj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
