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>
In-Reply-To: <CAB3F3DtLzemnNqj6skRcK22qGYVwuo5YCPhUXQDCUcEe3yKr7Q@mail.gmail.com>
From: Joost Jager <joost.jager@gmail.com>
Date: Fri, 16 Jun 2023 13:26:34 +0200
Message-ID: <CAJBJmV_vPW1vBSfTeDOU_FecHk1sX2=uGUFYS9enC=hwvLpVQA@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003a020905fe3d7797"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

--0000000000003a020905fe3d7797
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 siz=
e?
>
> 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 sufficient
> 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. Then y=
ou
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

>

--0000000000003a020905fe3d7797
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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">gsanders87@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>&gt; Would it then still be necessary to restrict the a=
nnex 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 also be used for other=
 anti-pinning efforts(though clearly not sufficient by itself for the many =
many pinning vectors we have :) )</div></div></blockquote><div><br></div><d=
iv>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:</div><div><br></div><div>=
* Opt-in annex (every input must commit 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 href=3D"https://github.com/bitcoin/bips/p=
ull/1381">https://github.com/bitcoin/bips/pull/1381</a> -&gt; future extens=
ibility<br>* Only allow tlv record 0 - unstructured data -&gt; future exten=
sibility</div><div>* Limit maximum size of the value to 256 bytes -&gt; pro=
tect opt-in users</div><div><br></div><div>Unfortunately the limit of 126 b=
ytes in=C2=A0<a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull=
/22">https://github.com/bitcoin-inquisition/bitcoin/pull/22</a> isn&#39;t s=
ufficient for these types of vaults. If there are two presigned txes (unvau=
lt 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 k=
ey can&#39;t be reconstructed from the schnorr signature. The remaining byt=
es could be used for a third presigned tx and/or additional vault parameter=
s.</div><div><br></div><div>Can you think of remaining practical objections=
 to making the annex standard under the conditions listed above?</div><div>=
<br></div><div>Joost</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 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
</blockquote></div>
</blockquote></div></div>

--0000000000003a020905fe3d7797--