From laolu32 at gmail.com Wed Mar 23 22:30:40 2022 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Wed, 23 Mar 2022 15:30:40 -0700 Subject: [Lightning-dev] Taproot-aware Channel Announcements + Proof Verification In-Reply-To: <7498cd47626bb2ad40acb2770abc7cd4@dtrt.org> References: <7498cd47626bb2ad40acb2770abc7cd4@dtrt.org> Message-ID: Hi Harding, That's a really good point: the false signal is more costly with witness v0 outputs, as they need to pay for the extra bytes in the witness. I agree we can't 100% maintain the same level of binding for pure taproot channels. However by having validators verify the final key derivation, we still effectively further restrict the _type_ of outputs that can be used to advertise channels, as this means that someone can't use "normal" P2TR wallet outputs for channel proofs (barring the existence of some new threshold schnorr wallet, but that would use different key aggregation (FROST?) all together). -- Laolu On Wed, Mar 23, 2022 at 2:02 PM David A. Harding wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: