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
📝 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