David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-23 📝 Original message: On 22.03.2022 15:10, ...
📅 Original date posted:2022-03-23
📝 Original message:
On 22.03.2022 15:10, Olaoluwa Osuntokun wrote:
> ### Should the proof+verification strongly bind to the LN context?
> Today, nodes use the two bitcoin keys and construct a p2wsh
> multi-sig script and then verify that the script matches what has been
> confirmed on chain. With taproot, the output is actually just a single
> key. So if we want to maintain the same level of binding (which makes
> it
> harder to advertise fake channels using just a change output have or
> something), then we'd specify that nodes reconstruct the aggregated
> bitcoin public
> key
I think there's a significant difference between P2WSH and P2TR that's
not being considered here. With P2WSH, if I want to fake the creation
of a channel by making my change outputs OP_CMS(2-of-2) with myself, I
pay for that deception by incurring extra fee costs at spend time due to
the need to provide more witness data over plain single-sig. With
P2TR/MuSig2,
I can make my change outputs MuSig2(2-of-2) with myself without
incurring
any additional onchain spend costs.
In short, I don't believe that you can maintain the same level of
binding-to-LN-usage currently provided by P2WSH when P2TR keypath
spends are allowed.
Thanks,
-Dave
Published at
2023-06-09 13:05:36Event JSON
{
"id": "f553caee53d197e6c52a44515f22fa3b8e3d2d473cbd5efc4870a6a969d8068c",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315936,
"kind": 1,
"tags": [
[
"e",
"419acf3f070d6ca83161dbf976fadb6b16d7e209ce13dcb1aef6e54afa4692f4",
"",
"root"
],
[
"e",
"36bf51fd36a6ab9dabc53a35893aa96582ded3c545fb4489fd58ef4d807cf06f",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2022-03-23\n📝 Original message:\nOn 22.03.2022 15:10, Olaoluwa Osuntokun wrote:\n\u003e ### Should the proof+verification strongly bind to the LN context?\n\u003e Today, nodes use the two bitcoin keys and construct a p2wsh\n\u003e multi-sig script and then verify that the script matches what has been\n\u003e confirmed on chain. With taproot, the output is actually just a single\n\u003e key. So if we want to maintain the same level of binding (which makes \n\u003e it\n\u003e harder to advertise fake channels using just a change output have or\n\u003e something), then we'd specify that nodes reconstruct the aggregated \n\u003e bitcoin public\n\u003e key\n\nI think there's a significant difference between P2WSH and P2TR that's\nnot being considered here. With P2WSH, if I want to fake the creation\nof a channel by making my change outputs OP_CMS(2-of-2) with myself, I\npay for that deception by incurring extra fee costs at spend time due to\nthe need to provide more witness data over plain single-sig. With \nP2TR/MuSig2,\nI can make my change outputs MuSig2(2-of-2) with myself without \nincurring\nany additional onchain spend costs.\n\nIn short, I don't believe that you can maintain the same level of\nbinding-to-LN-usage currently provided by P2WSH when P2TR keypath\nspends are allowed.\n\nThanks,\n\n-Dave",
"sig": "02b2eb21cf23641891903b5d9b9a1b13de9321b19b2467aaa2cb18f772e656e496d3c283236d355d14d850c26f5580f3aa71fa53ab0cb1baf3b7bf33ecdcccdd"
}