Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0BC7EC0029 for ; Sun, 18 Jun 2023 20:32:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C632D81EAD for ; Sun, 18 Jun 2023 20:32:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C632D81EAD 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=EaReN/xH 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 qsamkNxtMCAI for ; Sun, 18 Jun 2023 20:32:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 975E781EA5 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 975E781EA5 for ; Sun, 18 Jun 2023 20:32:25 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-76c64da0e46so140331439f.0 for ; Sun, 18 Jun 2023 13:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687120344; x=1689712344; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Vo3oUM8E2bmQXkpANd//18siaqtkGu5MvqZsvt7jHes=; b=EaReN/xHT9xBTEAmu0SwJgZHv4WVYKynnlCZEdVtRshwYq7gg+EFX1sYH3qONUUrtT 7MpqPZJW3thgAsW6RGihwtc8QriqnSr0wlQbINR9XsalS3ZiQUqgWouudamak+inaQPn UdWBsL/u7SitlmS+/uT36ZItwYDU6uXj/oCpqsninvoCh8Hl1m/mYQGHbh8xSUdn/dkC nyC78hyBVFph9OLziz4dc94xBFZBFLl6L7sZf0FdEY9acF87t+rzxlekwD0HBbdepbhl O2tDC2Dtpm+ycCXehBWJ6itxpm//Er63DUz4ptA2C9ts3FRUQdKrM77abCFdl0PEZJd0 IYow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687120344; x=1689712344; 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=Vo3oUM8E2bmQXkpANd//18siaqtkGu5MvqZsvt7jHes=; b=LF0/1kxNRu3LCrv9cWe3pGtikQ8MLcS2PLRW9fsvRqOU6IFUbsPX7CuQsPvbCtY9Dg SgUBNrWwrUf9PrefmRgqxWpyBB9CnlHeegzRalXK17nzgPB3gkLuAmVMkMAF/b6H7vxA xfQuXLj3lNhCxWsEOzp9UZYwzJHrXS4R4oiOKbt0kh2mHXGN4xK8mjzkrnI5SOFyRqRd g3KKQY9vdsfAVtSMO7Wf9hO6+KGr7mkYU9+PE7FwvYbsO5acSQRCotYap/vzyIWg6v4N nsld+GnHSFFC5sCA8Oe+9FoKURyMabLgBUikNHFYoXqiE/8y5slQtcIbNnhLzWgBUmet 42dg== X-Gm-Message-State: AC+VfDzzbJT+1UgqPUD6AdmbTUggHYPg8rjU6l9rFbKHar0sPiXbnZMU foTYFmlu0xcolcATvcEGLGjVEs0xEd46+UGoMXkmU0fqLx8= X-Google-Smtp-Source: ACHHUZ73OZqvRE2uxT5j+hZ6E7rhB+bHzuBFR4j5YExoPosqzW1ujEIGcRi+Upu/mgoK6JvEwCAOjxSlm5a3x02HtAc= X-Received: by 2002:a05:6602:19:b0:774:7a6d:8753 with SMTP id b25-20020a056602001900b007747a6d8753mr7706477ioa.9.1687120344403; Sun, 18 Jun 2023 13:32:24 -0700 (PDT) MIME-Version: 1.0 References: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org> In-Reply-To: From: Antoine Riard Date: Sun, 18 Jun 2023 21:32:12 +0100 Message-ID: To: Greg Sanders , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000d2511805fe6d50c7" X-Mailman-Approved-At: Sun, 18 Jun 2023 20:46:14 +0000 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:32:27 -0000 --000000000000d2511805fe6d50c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 and 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 lik= e > 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 can >>> also be used for other anti-pinning efforts(though clearly not sufficie= nt >>> 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. The= n 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 b= e >> 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 > --000000000000d2511805fe6d50c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

> * Opt-in annex (every inpu= t must commit to an annex even if its is empty) -> make sure existing mu= lti-party protocols remain unaffected

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

If I understand co= rrectly, this would require modifying current Taproot support on the Lightn= ing-side, where all P2TR spends must add an annex and commit to it in the B= IP341 signature digest. This would be quite a mandatory upgrade for Lightni= ng nodes, as failure to do so would break propagations of their `option_tap= root` channel transactions.

> * Limit maximum s= ize of the value to 256 bytes -> protect opt-in users

There is another approach where the maximum size/weight of the witne= ss/transaction is introduced as a TLV record itself:

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

Best,
Antoi= ne

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

I haven't thoug= ht a ton about the specific TLV format, but that seems like a reasonable pl= ace 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 &= quot;hints" in an annex field.

I'll let o= thers chime in at this point!

Cheers,
Gr= eg

On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager <joost.jager@gmail.com&g= t; wrote:
Hi Greg,
On Thu, J= un 15, 2023 at 12:39=E2=80=AFPM Greg Sanders <gsanders87@gmail.com> wrote:
> Would it then still be necess= ary to restrict the annex to a maximum size?

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

Thinking about the most restrictive policy that wou= ld still enable annex-vaults (which I believe has great potential for impro= ving bitcoin custody) and is in line with work already done, I get to:

* Opt-in annex (every input must commit to an annex ev= en if its is empty) -> make sure existing multi-party protocols remain u= naffected
* 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 s= ize of the value to 256 bytes -> protect opt-in users

Unfortunately the limit of 126 bytes in=C2=A0https://githu= b.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient for thes= e 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 wan= t to store 32 bytes for the ephemeral key itself as the key can't be re= constructed from the schnorr signature. The remaining bytes could be used f= or a third presigned tx and/or additional vault parameters.

<= /div>
Can you think of remaining practical objections to making the ann= ex standard under the conditions listed above?

Joo= st
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000d2511805fe6d50c7--