Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A3012C0029 for ; Mon, 19 Jun 2023 01:14:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7703F81C58 for ; Mon, 19 Jun 2023 01:14:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7703F81C58 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=A4HxkNVW X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FVAZ-u1UGUZ for ; Mon, 19 Jun 2023 01:14:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C90B681448 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by smtp1.osuosl.org (Postfix) with ESMTPS id C90B681448 for ; Mon, 19 Jun 2023 01:14:22 +0000 (UTC) Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-7623a6c24f2so284885085a.0 for ; Sun, 18 Jun 2023 18:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687137261; x=1689729261; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FtHGf5ukD7EalhB32daT0jSIe1h6FHYvHOYVsX8FQWY=; b=A4HxkNVWrUDidYfWROpQ7G+zf6tHVtsnSHqGpXMfm/Cn17W7C57Y36u8qQVprT/A+m lx8gTo7bx92DW19PVP2RlbsWg01BnPLK1o15viFIBbIkO25apKG3yToh78ILditMyfQ+ 5Zw2ja2sP9n1ffYLZFVeFBZSPJqXmNpHZUyantuEw/3CKexWVX12X90nzM0E+m1b0JmT +OVWO0HEN2leAT3B836XRC9/FvMXIyHSJdWggU4fZX2JBWha8WoEG1RFxRohj+MmNauM UM4CddOa+3TL+vAAC5qlMVh0fHtRMXMVqQ/E1isrr5pnjTWIEqgDFaawETvdkXSdi9YF pL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687137261; x=1689729261; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FtHGf5ukD7EalhB32daT0jSIe1h6FHYvHOYVsX8FQWY=; b=JTwWUjdwyyTo2XhxNjssh/w9XizZnMSENkvqFTifzp+91c1bp9cUUGqpzJK7JvuLPI xF1qTsl0lhD1KK8/ttiHoFJz0njLT3Eiun1iJ3ZBBnoPZojLQ8ZeMQrxSD7rEks49gh2 A1PvBx5V6JUZtQy45IUT/QOmVVsUyV9g0+vxMzDLXJ7KXjNF8qqfx14B4O8sh/7Dhvxs PW7MCghFLCAchmwFvsoZ8A4bbXsPUxFVn+BP7U/SWkup9pGk4r14pwklnQUjMlNRvvzN rl9PmDZ/FPt5a4zq98l7BnG38gagD0wc3+bj4bM/Re5FYNVUswSm4nMbZXc/5lekrk73 JJGA== X-Gm-Message-State: AC+VfDwMGnIz/kJu3eot31+JdlOSvLV7n9QNJkt7e2IlBtb6PXPjLsi9 oKMabX4He0UPyTN0tHKyoyaVoWXZzCs9UD4AqNc20KI4CH0= X-Google-Smtp-Source: ACHHUZ6m1i2ascmNZBHkyLj7/1w/LBy8j3lOEXldTjJjLdbDtSR9YOUzJXNag/fC8B67u3TBywyq0M4mVS4m2b5r3FI= X-Received: by 2002:a05:620a:424d:b0:75b:23a1:3606 with SMTP id w13-20020a05620a424d00b0075b23a13606mr9752461qko.23.1687137261397; Sun, 18 Jun 2023 18:14:21 -0700 (PDT) MIME-Version: 1.0 References: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org> In-Reply-To: From: Antoine Riard Date: Mon, 19 Jun 2023 02:14:10 +0100 Message-ID: To: Greg Sanders Content-Type: multipart/alternative; boundary="000000000000272c8a05fe7141c0" X-Mailman-Approved-At: Mon, 19 Jun 2023 08:39:05 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2023 01:14:24 -0000 --000000000000272c8a05fe7141c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, > Going to need a citation for this. Sorry for the confusion, this was in reply to Joost's point on "Opt-in annex (every input must commit to an annex even if its is empty) -> make sure existing multi-party protocols remain unaffected" What is unclear to me is if we're talking about opt-in of non-deployed-yet protocols like the pre-signed vaults or deployed protocols like coinjoin/lightning spending P2TR outputs, where a counterparty script spend path can inflate the witness, and we would like to commit *now* to avoid future interferences. E.g 0-conf dual-funding and we loosened the limit from 126 bytes to 256, the worst-case liquidity griefing is not the same anymore. If the opt-in mechanism we're talking about is just adding an annex for non-deployed-yet protocols as a script spend path of a currently deployed protocol could always be opted-in to the new annex policy through script spend path in the context of collaborative added inputs, no ? > People should really not be building protocols that are meant to go into production on top of undeveloped upgrade hooks, and we should not be encumbered by these premature choices if so. > People should really not be building protocols that are meant to go into production on top of undeveloped upgrade hooks, > and we should not be encumbered by these premature choices if so. Maybe I'm misunderstanding, which is why a citation > would be handy. Yes ideally we should not be encumbered by these premature choices. Still if those use-cases catched up in terms of economic weight, the coordination cost of deploying a new policy might be prohibitive, or require very long periods, somehow like we're seeing with mempoolfullrbf. And I don't think we can say the use-cases would be illegitimate, or that base-layer policy should always have the last word. In the example of lightning, we're doing major re-work of the mempool, partially to improve lightning operations. Personally, I think we should care more about sound and "firewalled" signaling and upgrading mechanisms that let us deploy new policy rules for new use-cases more smoothly. Best, Antoine Le dim. 18 juin 2023 =C3=A0 21:41, Greg Sanders a = =C3=A9crit : > Hi Antoine, > > > If I understand correctly, this would require modifying current Taproot > support on the Lightning-side, where all P2TR spends must add an annex an= d > commit to it in the BIP341 signature digest. > > huh? > > Going to need a citation for this. > > People should really not be building protocols that are meant to go into > production on top of undeveloped upgrade hooks, > and we should not be encumbered by these premature choices if so. Maybe > I'm misunderstanding, which is why a citation > would be handy. > > Best, > Greg > > On Sun, Jun 18, 2023 at 4:32=E2=80=AFPM Antoine Riard > wrote: > >> Hi all, >> >> > * Opt-in annex (every input must commit to an annex even if its is >> empty) -> make sure existing multi-party protocols remain unaffected >> >> By requiring every input to commit to an annex even if it is empty, do >> you mean rejecting a transaction where the minimal annex with its 0x50 t= ag >> is absent ? >> >> If I understand correctly, this would require modifying current Taproot >> support on the Lightning-side, where all P2TR spends must add an annex a= nd >> commit to it in the BIP341 signature digest. This would be quite a >> mandatory upgrade for Lightning nodes, as failure to do so would break >> propagations of their `option_taproot` channel transactions. >> >> > * Limit maximum size of the value to 256 bytes -> protect opt-in users >> >> There is another approach where the maximum size/weight of the >> witness/transaction is introduced as a TLV record itself: >> https://github.com/bitcoin-inquisition/bitcoin/pull/28 >> >> Note this branch also implements the "only allow tlv record 0" with the >> TLV format from bips #1381. >> >> Best, >> Antoine >> >> Le ven. 16 juin 2023 =C3=A0 14:31, Greg Sanders via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : >> >>> Hi Joost, >>> >>> I haven't thought a ton about the specific TLV format, but that seems >>> like a reasonable place to start as it shouldn't unduly >>> impact current users, and is pretty simple from an accounting >>> perspective. >>> It also can be further relaxed in the future if we so decide by using >>> max tx size policy "hints" in an annex field. >>> >>> I'll let others chime in at this point! >>> >>> Cheers, >>> Greg >>> >>> On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager >>> wrote: >>> >>>> Hi Greg, >>>> >>>> On Thu, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders >>>> wrote: >>>> >>>>> > Would it then still be necessary to restrict the annex to a maximum >>>>> size? >>>>> >>>>> I think it's worth thinking about to protect the opt-in users, and ca= n >>>>> also be used for other anti-pinning efforts(though clearly not suffic= ient >>>>> by itself for the many many pinning vectors we have :) ) >>>>> >>>> >>>> Thinking about the most restrictive policy that would still enable >>>> annex-vaults (which I believe has great potential for improving bitcoi= n >>>> custody) and is in line with work already done, I get to: >>>> >>>> * Opt-in annex (every input must commit to an annex even if its is >>>> empty) -> make sure existing multi-party protocols remain unaffected >>>> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 >>>> -> future extensibility >>>> * Only allow tlv record 0 - unstructured data -> future extensibility >>>> * Limit maximum size of the value to 256 bytes -> protect opt-in users >>>> >>>> Unfortunately the limit of 126 bytes in >>>> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't >>>> sufficient for these types of vaults. If there are two presigned txes >>>> (unvault and emergency), those signatures would already take up 2*64= =3D128 >>>> bytes. Then you also want to store 32 bytes for the ephemeral key itse= lf as >>>> the key can't be reconstructed from the schnorr signature. The remaini= ng >>>> bytes could be used for a third presigned tx and/or additional vault >>>> parameters. >>>> >>>> Can you think of remaining practical objections to making the annex >>>> standard under the conditions listed above? >>>> >>>> Joost >>>> >>>>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> --000000000000272c8a05fe7141c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

> Going to need a citation = for this.=C2=A0

Sorry for the confusion, this was = in reply to Joost's point on "Opt-in annex (every input must commi= t to an annex even if its is empty) -> make sure existing multi-party pr= otocols remain unaffected"

What is unclear to= me is if we're talking about opt-in of non-deployed-yet protocols like= the pre-signed vaults or deployed protocols like coinjoin/lightning spendi= ng P2TR outputs, where a counterparty script spend path can inflate the wit= ness, and we would like to commit *now* to avoid future interferences. E.g = 0-conf dual-funding and we loosened the limit from 126 bytes=C2=A0to 256, t= he worst-case liquidity griefing is not the same anymore.

If the opt-in mechanism we're talking about is just adding an a= nnex for non-deployed-yet protocols as a script spend path of a currently d= eployed protocol could always be opted-in to the new annex policy through s= cript spend path in the context of collaborative added inputs, no ?

> People should really not be building protocols that = are meant to go into production on top of undeveloped upgrade hooks,
<= div>and we should not be encumbered by these premature choices if so.
=

> People should really not be building protocol= s that are meant to go into production on top of undeveloped upgrade hooks,=
> and we should not be encumbered by these premature choices = if so. Maybe I'm misunderstanding, which is why a citation
&g= t; would be handy.

Yes ideally we should not= be encumbered by these premature choices. Still if those use-cases catched= up in terms of economic weight, the coordination cost of deploying a new p= olicy might be prohibitive, or require very long periods, somehow like we&#= 39;re seeing with mempoolfullrbf. And I don't think we can say the use-= cases would be illegitimate, or that base-layer policy should always have t= he last word. In the example of lightning, we're doing major re-work of= the mempool, partially to improve lightning operations. Personally, I thin= k we should care more about sound and "firewalled" signaling and = upgrading mechanisms that let us deploy new policy rules for new use-cases = more smoothly.

Best,
Antoine
=
Le=C2= =A0dim. 18 juin 2023 =C3=A0=C2=A021:41, Greg Sanders <gsanders87@gmail.com> a =C3=A9crit=C2=A0:
<= /div>
Hi Antoine,

> If I understand correctly, this would require modifying current Tapro= ot support on the Lightning-side, where all P2TR spends must add an annex a= nd commit to it in the BIP341 signature digest.=C2=A0

hu= h?

Going to need a citation for this.=C2=A0
<= div>
People should really not be building protocols that are = meant to go into production on top of undeveloped upgrade hooks,
= and we should not be encumbered by these premature choices if so. Maybe I&#= 39;m misunderstanding, which is why a citation
would be handy.

Best,
Greg

On Sun, Jun 18, 2023 at 4:= 32=E2=80=AFPM Antoine Riard <antoine.riard@gmail.com> wrote:
Hi all,

> * Opt-in annex (ev= ery input must commit to an annex even if its is empty) -> make sure exi= sting multi-party protocols remain unaffected

By requiring=C2= =A0every input to commit to an annex even if it is empty, do you mean rejec= ting a transaction where the minimal annex with its 0x50 tag is absent ?

If I understand correctly, this would require modify= ing current Taproot support on the Lightning-side, where all P2TR spends mu= st add an annex and commit to it in the BIP341 signature digest. This would= be quite a mandatory upgrade for Lightning nodes, as failure to do so woul= d break propagations of their `option_taproot` channel transactions.
<= div>
> * Limit maximum size of the value to 256 bytes ->= ; protect opt-in users

There is another approach w= here the maximum size/weight of the witness/transaction is introduced as a = TLV record itself:

Note this branch also imple= ments the "only allow tlv record 0" with the TLV format from bips= =C2=A0#1381.

Best,
Antoine
Le=C2=A0= ven. 16 juin 2023 =C3=A0=C2=A014:31, Greg Sanders via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Hi Joost,

I haven't tho= ught a ton about the specific TLV format, but that seems like a reasonable = place to start as it shouldn't unduly
impact current users, a= nd is pretty simple from an accounting perspective.
It also can b= e further relaxed in the future if we so decide by using max tx size policy= "hints" in an annex field.

I'll let= others chime in at this point!

Cheers,
= Greg

On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager <joost.jager@gmail.com> wrote:
Hi Greg,
On Th= u, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders <gsanders87@gmail.com> wrote:
=
> Would it then still be ne= cessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and c= an also be used for other anti-pinning efforts(though clearly not sufficien= t by itself for the many many pinning vectors we have :) )

Thinking about the most restrictive policy that= would still enable annex-vaults (which I believe has great potential for i= mproving bitcoin custody) and is in line with work already done, I get to:<= /div>

* Opt-in annex (every input must commit to an anne= x even if its is empty) -> make sure existing multi-party protocols rema= in unaffected
* Tlv format as defined in=C2=A0https://github.com/bit= coin/bips/pull/1381 -> future extensibility
* Only allow tlv reco= rd 0 - unstructured data -> future extensibility
* Limit maxim= um size of the value to 256 bytes -> protect opt-in users

=
Unfortunately the limit of 126 bytes in=C2=A0https://g= ithub.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient for = these types of vaults. If there are two presigned txes (unvault and emergen= cy), those signatures would already take up 2*64=3D128 bytes. Then you also= want to store 32 bytes for the ephemeral key itself as the key can't b= e reconstructed from the schnorr signature. The remaining bytes could be us= ed for a third presigned tx and/or additional vault parameters.
<= br>
Can you think of remaining practical objections to making the= annex standard under the conditions listed above?

Joost
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000272c8a05fe7141c0--