path: root/06/7225e1d3bb726d118139d4058b3f06674f973d

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 49C64C0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 18 Jun 2023 20:41:06 +0000 (UTC)
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-988a2715b8cso68241966b.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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>
 <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>
In-Reply-To: <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Sun, 18 Jun 2023 16:40:53 -0400
Message-ID: <CAB3F3DvyC33UZkioW_JV7U9qc4+VKFEMt51T6XuUmoX5x+BRsw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d4c45005fe6d6fef"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: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 <antoine.riard@gmail.=
com>
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 <joost.jager@gmail.c=
om>
>> 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 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

<div dir=3D"ltr"><div>Hi Antoine,</div><div><br></div>&gt; 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<div><br></div><div>huh?</div><div><br></div=
><div>Going to need a citation for this.=C2=A0</div><div><br></div><div>Peo=
ple should really not be building protocols that are meant to go into produ=
ction on top of undeveloped upgrade hooks,</div><div>and we should not be e=
ncumbered by these premature choices if so. Maybe I&#39;m misunderstanding,=
 which is why a citation</div><div>would be handy.</div><div><br></div><div=
>Best,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Sun, Jun 18, 2023 at 4:32=E2=80=AFPM Antoine =
Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.co=
m</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr">Hi all,<div><br></div><div>&gt; * Opt-in annex (every inp=
ut must commit to an annex even if its is empty) -&gt; make sure existing m=
ulti-party protocols remain unaffected</div><br><div>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 ?</div><div=
><br></div><div>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.</div><div><br=
></div><div>&gt; * Limit maximum size of the value to 256 bytes -&gt; prote=
ct opt-in users</div><div><br></div><div>There is another approach where th=
e maximum size/weight of the witness/transaction is introduced as a TLV rec=
ord itself:</div><div><a href=3D"https://github.com/bitcoin-inquisition/bit=
coin/pull/28" target=3D"_blank">https://github.com/bitcoin-inquisition/bitc=
oin/pull/28</a></div><div><br></div><div>Note this branch also implements t=
he &quot;only allow tlv record 0&quot; with the TLV format from bips=C2=A0#=
1381.</div><div><br></div><div>Best,</div><div>Antoine</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 16=
 juin 2023 =C3=A0=C2=A014:31, Greg Sanders via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Joost,<div><br></=
div><div>I haven&#39;t thought a ton about the specific TLV format, but tha=
t seems like a reasonable place to start as it shouldn&#39;t unduly</div><d=
iv>impact current users, and is pretty simple from an accounting perspectiv=
e.</div><div>It also can be further relaxed in the future if we so decide b=
y using max tx size policy &quot;hints&quot; in an annex field.</div><div><=
br></div><div>I&#39;ll let others chime in at this point!</div><div><br></d=
iv><div>Cheers,</div><div>Greg</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_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>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);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, Jun 15, 2023 at=
 12:39=E2=80=AFPM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gmail.com" =
target=3D"_blank">gsanders87@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>&gt; Would it t=
hen still be necessary to restrict the annex to a maximum size?<br></div><d=
iv><br></div><div>I think it&#39;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 :) )</=
div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>* Opt-in annex (every input must co=
mmit to an annex even if its is empty) -&gt; make sure existing multi-party=
 protocols remain unaffected</div><div>* Tlv format as defined in=C2=A0<a h=
ref=3D"https://github.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><di=
v>* Limit maximum size of the value to 256 bytes -&gt; protect opt-in users=
</div><div><br></div><div>Unfortunately the limit of 126 bytes in=C2=A0<a h=
ref=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/22" target=3D"_b=
lank">https://github.com/bitcoin-inquisition/bitcoin/pull/22</a> isn&#39;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&#39;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.</div><div><br></div><div>Can you think of remaining practical objection=
s to making the annex standard under the conditions listed above?</div><div=
><br></div><div>Joost</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
</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>
</blockquote></div>

--000000000000d4c45005fe6d6fef--