Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2022-03-23 📝 Original message: Hi Harding, That's a ...
📅 Original date posted:2022-03-23
📝 Original message:
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 <dave at dtrt.org> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220323/90c12121/attachment.html>;
📝 Original message:
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 <dave at dtrt.org> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220323/90c12121/attachment.html>;