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