From dave at dtrt.org Wed Mar 23 21:02:12 2022 From: dave at dtrt.org (David A. Harding) Date: Wed, 23 Mar 2022 11:02:12 -1000 Subject: [Lightning-dev] Taproot-aware Channel Announcements + Proof Verification In-Reply-To: <CAO3Pvs9T7Pyi4cZcrJa8bBg6LR7Eyp0dDFUGfhtS810OMDse7g@mail.gmail.com> References: <CAO3Pvs9T7Pyi4cZcrJa8bBg6LR7Eyp0dDFUGfhtS810OMDse7g@mail.gmail.com> Message-ID: <7498cd47626bb2ad40acb2770abc7cd4@dtrt.org> 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