Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 49C64C0029 for ; Sun, 18 Jun 2023 20:41:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2FCF141496 for ; Sun, 18 Jun 2023 20:41:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2FCF141496 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=nsiVLR+Y X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6V3IuN98ESK for ; Sun, 18 Jun 2023 20:41:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1B638413D0 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1B638413D0 for ; Sun, 18 Jun 2023 20:41:06 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-988a2715b8cso68241966b.0 for ; Sun, 18 Jun 2023 13:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687120865; x=1689712865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7o7xWZ4j9jX/R5VIzunXkHz39PgvH99uW3LMAj9nY9w=; b=nsiVLR+Y2W5dYbS2JAVdmmZFEWiXpI03Vjf8AwnFMTZcPinGkx05Is1ljtf2qD1DcG MZAo6z3t5Zn/k3lYsGTJ65aqOHB3Mkw5JgqCkCdl41bnKd45DL0sRbbUxQCElsk1hqWG iPHMWycou3UrDf5HgDJAzqOMgDe6UcaucVEr1vUh3/6M1ChSZRE1VWx0ueDTbxo9BitF E9D4EaB/O/+bcIFQBbuNygm11PK3k6dZU4MdPKeRLVmzYQRGB4jWfROKDM/6vUg8V5tq 4NYfhTveKF1KVqIFTE9pqmArBg9fGgmdkKLblaSzK038E/LIayhM0Us6FOofb755n9YV 4pQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687120865; x=1689712865; 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=7o7xWZ4j9jX/R5VIzunXkHz39PgvH99uW3LMAj9nY9w=; b=c19HSfhJ3smHRebwL+LoDcTJs5sEuwqPZ/Vkhkg8W82YybByAm8PtqwgZml4IBXChJ yB+yCJxSf6SLLh6wFtWezxVYiIRhYrFecjk1ZxBN74BLdKlcOiCJtZbXGMgcmQRDKL9a buZIUIQvRBLgRQlbdeQ4m1wQRHGwzqvA8IRWpalipDm5+pKqvprHEryhnW8wuxvLTKix rPcCVLmpdS7DFZK+kYCf2eGdanGnpAABFYGu6iRE2xfjenYSYMeLrvkHQ47Wk0j8MCTq CVEI6LOLQlb8ICBnq2X51G/RB0b5unXCETXc4nNR2Cz83cjrNDflqRkJ64QdYGB5cVnf kcoQ== X-Gm-Message-State: AC+VfDz7IOlA7BRqU6C/XDbRcsLacWJHeYF/27iVflBCet+/+A6CtMse KrGB+zNJduAC2VDvlg2SoVSyYAOvCA4QbOCq2pQ= X-Google-Smtp-Source: ACHHUZ6rWzg56nFIte6K2cLiLCKsA7MadgvjCrGGayaXn07civ+oU5U75oB2Wx6qHxrbsXJb9WnHqbMbcHbZWmnPjTk= X-Received: by 2002:a17:907:8686:b0:987:d0c3:e300 with SMTP id qa6-20020a170907868600b00987d0c3e300mr3659381ejc.26.1687120864656; Sun, 18 Jun 2023 13:41:04 -0700 (PDT) MIME-Version: 1.0 References: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org> In-Reply-To: From: Greg Sanders Date: Sun, 18 Jun 2023 16:40:53 -0400 Message-ID: To: Antoine Riard Content-Type: multipart/alternative; boundary="000000000000d4c45005fe6d6fef" 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: Sun, 18 Jun 2023 20:41:09 -0000 --000000000000d4c45005fe6d6fef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 and 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 yo= u > mean rejecting a transaction where the minimal annex with its 0x50 tag 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 an= d > 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 perspectiv= e. >> It also can be further relaxed in the future if we so decide by using ma= x >> 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 can >>>> also be used for other anti-pinning efforts(though clearly not suffici= ent >>>> 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 bitcoin >>> 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. Th= en you >>> also want to store 32 bytes for the ephemeral key itself as the key can= 't >>> be reconstructed from the schnorr signature. The remaining 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 >> > --000000000000d4c45005fe6d6fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Antoine,

> If I understand = correctly, this would require modifying current Taproot support on the Ligh= tning-side, where all P2TR spends must add an annex and commit to it in the= BIP341 signature digest.=C2=A0

huh?

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

Peo= ple should really not be building protocols that are meant to go into produ= ction on top of undeveloped upgrade hooks,
and we should not be e= ncumbered 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 <antoine.riard@gmail.co= m> wrote:
Hi all,

> * Opt-in annex (every inp= ut must commit to an annex even if its is empty) -> make sure existing m= ulti-party protocols remain unaffected

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

If I understand correctly, this would require modifying cur= rent Taproot support on the Lightning-side, where all P2TR spends must add = an annex and commit to it in the BIP341 signature digest. This would be qui= te 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 -> prote= ct opt-in users

There is another approach where th= e maximum size/weight of the witness/transaction is introduced as a TLV rec= ord itself:

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

Best,
Antoine

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

I haven't thought a ton about the specific TLV format, but tha= t seems like a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspectiv= e.
It also can be further relaxed in the future if we so decide b= y using max tx size policy "hints" in an annex field.
<= br>
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 Thu, Jun 15, 2023 at= 12:39=E2=80=AFPM Greg Sanders <gsanders87@gmail.com> wrote:
> Would it t= hen 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 can also be used for other anti-pinning efforts(though clearl= y not sufficient by itself for the many many pinning vectors we have :) )

Thinking about the most restrict= ive policy that would still enable annex-vaults (which I believe has great = potential for improving bitcoin custody) and is in line with work already d= one, I get to:

* Opt-in annex (every input must co= mmit to an annex even if its is empty) -> make sure existing multi-party= protocols remain unaffected
* Tlv format as defined in=C2=A0https:/= /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=C2=A0https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't = sufficient for these types of vaults. If there are two presigned txes (unva= ult and emergency), 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 be reconstructed from the schnorr signature. The remaining by= tes could be used for a third presigned tx and/or additional vault paramete= rs.

Can you think of remaining practical objection= s 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
--000000000000d4c45005fe6d6fef--