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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
