📅 Original date posted:2020-08-03
📝 Original message:Thanks AJ for the updated BIP - very exciting!
I'm also interested in this in the context of a Taproot version of
Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your
thoughts on how this would work. I have had some difficulty understanding
when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this
is a clever demonstration of how the differences can be exploited.
I sketched out the protocol you described to help my understand it (below)
and some questions came to mind:
1) If you do a collaborative close, would you need to use script-path
spending, or could you use key-path spending instead to improve privacy?
2) You mention 1.5 round trips for the (two party) MuSig signing session.
Must there be separate 1.5 round trips for each of the two signatures
produced (update, settlement) for each state update?
3) A related question: can the 1.5 round trips for signing be combined with
the 1.5 round trips required to update the channel (ie. A signs settlement
tx, B signs settlement & update txs, A signs update tx)?
Perhaps something like this:
-> A provides partial signature for settlement tx
<- B provides complete signature for settlement tx and partial signature
for update tx
-> A provides complete signature for update tx
4) I'm not sure why AJ's formulation included an addition sig(X), but
otherwise is it similar to what you're suggesting?
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
All the best,
-- Richard
------- my interpretation of your scheme ----
[Fund Channel]
|
|
|
v
P=Musig(A,B)+scripts (Taproot internal key, aka script path key?)
Q=Musig(A,B) (Taproot output key, aka root key?)
OR ----------- [Cooperative Close]
||| Sig(Q) -----+
||| |----> Sig(A)...
||| |
||| |----> Sig(B)...
|||
|||
||+-->[Update(n)]
|| nlocktime/state > n
|| Sig(P)+ANYPREVOUTANYSCRIPT
||
|| OR ---------->[Settle(n)] [Uncooperative Close @
state n]
|| | Sig(P)+ANYPREVOUT
|| | csv [delay] --------+---> Sig(A)... [HTLCs
& Settled
|| | |
Outputs ]
|| | |---> Sig(B)...
|| v
|+---->[Update(n+1)]
| nlocktime/state > n+1
| Sig(P)+ANYPREVOUTANYSCRIPT
|
| OR ----------->[Settle(n+1)] [Uncooperative Close @
state n+1]
| | Sig(P)+ANYPREVOUT
| | csv [delay] -------+---> Sig(A)... [HTLCs
& Settled
| | |
Outputs ]
v v |---> Sig(B)...
On Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
...
> Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction
> could, in theory, have only a single internal taproot pubkey, `P = MuSig(A,
> B)` for a channel between A and B.
>
> So the funding outpoint would be spent with a taprooted P + a single
> tapscript `<1> OP_CHECKSIG`.
>
> Update transactions would be signed with the internal taproot pubkey using
> `SIGHASH_ANYPREVOUTANYSCRIPT`.
> The update transaction output would be spendable with a taprooted P + a
> single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1>
> OP_CHECKSIG`.
> Each update transaction would have a monotonically-increasing `nLockTime`,
> i.e. the above `index`.
>
> Then a state transaction would be signed with the internal taproot pubkey
> using `SIGHASH_ANYPREVOUT`, which commits to the exact script including
> `<index + 1>`, which is unique for each update transaction.
> Thus a state transaction can only spend the specific update transaction,
> but the update transaction can spend the funding outpoint or any update
> transaction outpoint.
> State transaction input would have an `nSequence` requiring a relative
> locktime of the agreed-upon unilateral close delay.
>
> The above assumes MuSig signing, which requires 1.5 round trips for a
> channel, or three broadcast rounds for a multiparticipant (n >= 3)
> construction.
>
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200803/fadaa364/attachment.html>;
Richard Myers [ARCHIVE] /
npub12j…hfxgj
2023-06-07 18:26:07
in reply to nevent1q…mp2t
Author Public Key
npub12jllrss5nmygfhg7j9ztk2te80t96kumx7cllfc29skut6phqh5qfhfxgjPublished at
2023-06-07 18:26:07Event JSON
{
"id": "50c133d141e7a7676d3d07b253a32998df95edc4ccaa10aa6137d591ae2fefb5",
"pubkey": "54bff1c2149ec884dd1e9144bb29793bd65d5b9b37b1ffa70a2c2dc5e83705e8",
"created_at": 1686162367,
"kind": 1,
"tags": [
[
"e",
"b580beba13e993f0feaede9804bbc73901ee03ff94bf8b01329f909e32c379c0",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2020-08-03\n📝 Original message:Thanks AJ for the updated BIP - very exciting!\n\nI'm also interested in this in the context of a Taproot version of\nDecker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your\nthoughts on how this would work. I have had some difficulty understanding\nwhen someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this\nis a clever demonstration of how the differences can be exploited.\n\nI sketched out the protocol you described to help my understand it (below)\nand some questions came to mind:\n\n1) If you do a collaborative close, would you need to use script-path\nspending, or could you use key-path spending instead to improve privacy?\n\n2) You mention 1.5 round trips for the (two party) MuSig signing session.\nMust there be separate 1.5 round trips for each of the two signatures\nproduced (update, settlement) for each state update?\n\n3) A related question: can the 1.5 round trips for signing be combined with\nthe 1.5 round trips required to update the channel (ie. A signs settlement\ntx, B signs settlement \u0026 update txs, A signs update tx)?\n\nPerhaps something like this:\n -\u003e A provides partial signature for settlement tx\n \u003c- B provides complete signature for settlement tx and partial signature\nfor update tx\n -\u003e A provides complete signature for update tx\n\n4) I'm not sure why AJ's formulation included an addition sig(X), but\notherwise is it similar to what you're suggesting?\n\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html\n\nAll the best,\n\n -- Richard\n\n------- my interpretation of your scheme ----\n\n\n [Fund Channel]\n |\n |\n |\n v\n P=Musig(A,B)+scripts (Taproot internal key, aka script path key?)\n Q=Musig(A,B) (Taproot output key, aka root key?)\n\n OR ----------- [Cooperative Close]\n ||| Sig(Q) -----+\n ||| |----\u003e Sig(A)...\n ||| |\n ||| |----\u003e Sig(B)...\n |||\n |||\n ||+--\u003e[Update(n)]\n || nlocktime/state \u003e n\n || Sig(P)+ANYPREVOUTANYSCRIPT\n ||\n || OR ----------\u003e[Settle(n)] [Uncooperative Close @\nstate n]\n || | Sig(P)+ANYPREVOUT\n || | csv [delay] --------+---\u003e Sig(A)... [HTLCs\n\u0026 Settled\n || | |\nOutputs ]\n || | |---\u003e Sig(B)...\n || v\n |+----\u003e[Update(n+1)]\n | nlocktime/state \u003e n+1\n | Sig(P)+ANYPREVOUTANYSCRIPT\n |\n | OR -----------\u003e[Settle(n+1)] [Uncooperative Close @\nstate n+1]\n | | Sig(P)+ANYPREVOUT\n | | csv [delay] -------+---\u003e Sig(A)... [HTLCs\n\u0026 Settled\n | | |\nOutputs ]\n v v |---\u003e Sig(B)...\n\n\n\n\n\nOn Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n...\n\n\u003e Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction\n\u003e could, in theory, have only a single internal taproot pubkey, `P = MuSig(A,\n\u003e B)` for a channel between A and B.\n\u003e\n\u003e So the funding outpoint would be spent with a taprooted P + a single\n\u003e tapscript `\u003c1\u003e OP_CHECKSIG`.\n\u003e\n\u003e Update transactions would be signed with the internal taproot pubkey using\n\u003e `SIGHASH_ANYPREVOUTANYSCRIPT`.\n\u003e The update transaction output would be spendable with a taprooted P + a\n\u003e single tapscript `\u003cindex + 1\u003e OP_CHECKLOCKTIMEVERIFY OP_DROP \u003c1\u003e\n\u003e OP_CHECKSIG`.\n\u003e Each update transaction would have a monotonically-increasing `nLockTime`,\n\u003e i.e. the above `index`.\n\u003e\n\u003e Then a state transaction would be signed with the internal taproot pubkey\n\u003e using `SIGHASH_ANYPREVOUT`, which commits to the exact script including\n\u003e `\u003cindex + 1\u003e`, which is unique for each update transaction.\n\u003e Thus a state transaction can only spend the specific update transaction,\n\u003e but the update transaction can spend the funding outpoint or any update\n\u003e transaction outpoint.\n\u003e State transaction input would have an `nSequence` requiring a relative\n\u003e locktime of the agreed-upon unilateral close delay.\n\u003e\n\u003e The above assumes MuSig signing, which requires 1.5 round trips for a\n\u003e channel, or three broadcast rounds for a multiparticipant (n \u003e= 3)\n\u003e construction.\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200803/fadaa364/attachment.html\u003e",
"sig": "030a4f0561190534508cfadd49866702ae50fa22cc76b5ee3c0dd6ee169174df451280c7dc44c284416197955ec81bb1d15a31c49edb96fe063c4b6063910aea"
}