path: root/c5/3e4f26d49bff466ed8bfe1fc749a09a4f0ccc0

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0BC7EC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Jun 2023 20:32:25 +0000 (UTC)
Received: by mail-io1-xd2b.google.com with SMTP id
 ca18e2360f4ac-76c64da0e46so140331439f.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
 <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
 <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com>
 <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
 <CAJBJmV_vPW1vBSfTeDOU_FecHk1sX2=uGUFYS9enC=hwvLpVQA@mail.gmail.com>
 <CAB3F3DszC3ZDDYrN_jzoU+hZ021TfmCRoVTZWCpzOmH4F_anwg@mail.gmail.com>
In-Reply-To: <CAB3F3DszC3ZDDYrN_jzoU+hZ021TfmCRoVTZWCpzOmH4F_anwg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 18 Jun 2023 21:32:12 +0100
Message-ID: <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <joost.jager@gmail.co=
m> wrote:
>
>> Hi Greg,
>>
>> On Thu, Jun 15, 2023 at 12:39=E2=80=AFPM Greg Sanders <gsanders87@gmail.=
com>
>> 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

<div dir=3D"ltr">Hi all,<div><br></div><div>&gt; * Opt-in annex (every inpu=
t must commit to an annex even if its is empty) -&gt; make sure existing mu=
lti-party protocols remain unaffected</div><br class=3D"gmail-Apple-interch=
ange-newline"><div>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 ?</div><div><br></div><div>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.</div><div><br></div><div>&gt; * Limit maximum s=
ize of the value to 256 bytes -&gt; protect opt-in users</div><div><br></di=
v><div>There is another approach where the maximum size/weight of the witne=
ss/transaction is introduced as a TLV record itself:</div><div><a href=3D"h=
ttps://github.com/bitcoin-inquisition/bitcoin/pull/28">https://github.com/b=
itcoin-inquisition/bitcoin/pull/28</a></div><div><br></div><div>Note this b=
ranch also implements the &quot;only allow tlv record 0&quot; with the TLV =
format from bips=C2=A0#1381.</div><div><br></div><div>Best,</div><div>Antoi=
ne</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">Le=C2=A0ven. 16 juin 2023 =C3=A0=C2=A014:31, Greg Sanders via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-=
left:1ex"><div dir=3D"ltr">Hi Joost,<div><br></div><div>I haven&#39;t thoug=
ht a ton about the specific TLV format, but that seems like a reasonable pl=
ace to start as it shouldn&#39;t unduly</div><div>impact current users, and=
 is pretty simple from an accounting perspective.</div><div>It also can be =
further relaxed in the future if we so decide by using max tx size policy &=
quot;hints&quot; in an annex field.</div><div><br></div><div>I&#39;ll let o=
thers chime in at this point!</div><div><br></div><div>Cheers,</div><div>Gr=
eg</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Fri, Jun 16, 2023 at 7:27=E2=80=AFAM Joost Jager &lt;<a href=3D"=
mailto:joost.jager@gmail.com" target=3D"_blank">joost.jager@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Greg,</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, J=
un 15, 2023 at 12:39=E2=80=AFPM Greg Sanders &lt;<a href=3D"mailto:gsanders=
87@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div>&gt; Would it then still be necess=
ary to restrict the annex to a maximum size?<br></div><div><br></div><div>I=
 think it&#39;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 :) )</div></div></blockqu=
ote><div><br></div><div>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:</div=
><div><br></div><div>* Opt-in annex (every input must commit to an annex ev=
en if its is empty) -&gt; make sure existing multi-party protocols remain u=
naffected</div><div>* Tlv format as defined in=C2=A0<a href=3D"https://gith=
ub.com/bitcoin/bips/pull/1381" target=3D"_blank">https://github.com/bitcoin=
/bips/pull/1381</a> -&gt; future extensibility<br>* Only allow tlv record 0=
 - unstructured data -&gt; future extensibility</div><div>* Limit maximum s=
ize of the value to 256 bytes -&gt; protect opt-in users</div><div><br></di=
v><div>Unfortunately the limit of 126 bytes in=C2=A0<a href=3D"https://gith=
ub.com/bitcoin-inquisition/bitcoin/pull/22" target=3D"_blank">https://githu=
b.com/bitcoin-inquisition/bitcoin/pull/22</a> isn&#39;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&#39;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><div><br><=
/div><div>Can you think of remaining practical objections to making the ann=
ex standard under the conditions listed above?</div><div><br></div><div>Joo=
st</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex"><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d2511805fe6d50c7--