MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
 <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com>
 <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
In-Reply-To: <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 4 Jul 2023 21:18:23 +0100
Message-ID: <CALZpt+GZd8kv4Nq-ANR26GPeT_6+0U8zRnsQM1_OLOuhxD7QFg@mail.gmail.com>
To: Joost Jager <joost.jager@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d28d8305ffaefc8e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

Hi Joost,

> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.

From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex standard.

There is the observation that other critical elements of vault's
application state could be backed up in this way (e.g pubkeys and amounts
of the destination output) to rebuild from scratch a pre-signed withdrawal.
The unstructured data could be even marked by an application-level "tag" or
"signaling" to identify all the backup annexes composing your vault
application state.

Of course, such backing up of more critical elements comes with its own
drawbacks in terms of confidentiality, as you would leak your vault policy
on-chain, so they would need to be ciphered first, I think.

It sounds to me another economically rational set of use-cases can be to
simplify protocols using the chain as a publication space for collectibles.
Using the annex as a publication space enables a clear chain of collectible
ownership thanks to the key signing the annex, which is not permissible
with op_return outputs today.

Best,
Antoine


Le mar. 20 juin 2023 =C3=A0 13:30, Joost Jager <joost.jager@gmail.com> a =
=C3=A9crit :

> Hi all,
>
> On Sat, Jun 10, 2023 at 9:43=E2=80=AFAM Joost Jager <joost.jager@gmail.co=
m> wrote:
>
>> However, the primary advantage I see in the annex is that its data isn't
>> included in the calculation of the txid or a potential parent commit
>> transaction's txid (for inscriptions). I've explained this at [1]. This
>> feature makes the annex a powerful tool for applications that would idea=
lly
>> use covenants.
>>
>> The most critical application in this category, for me, involves
>> time-locked vaults. Given the positive reception to proposals such as
>> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probab=
ly
>> a bit further out, but pre-signed transactions signed using an ephemeral
>> key can fill the gap and improve the safeguarding of Bitcoin in the shor=
t
>> term.
>>
>> Backing up the ephemeral signatures of the pre-signed transactions on th=
e
>> blockchain itself is an excellent way to ensure that the vault can alway=
s
>> be 'opened'. However, without the annex, this is not as safe as it could
>> be. Due to the described circular reference problem, the vault creation =
and
>> signature backup can't be executed in one atomic operation. For example,
>> you can store the backup in a child commit/reveal transaction set, but t=
he
>> vault itself can be confirmed independently and the backup may never
>> confirm. If you create a vault and lose the ephemeral signatures, the fu=
nds
>> will be lost.
>>
>> This use case for the annex has been labeled 'speculative' elsewhere. To
>> me, every use case appears speculative at this point because the annex
>> isn't available. However, if you believe that time-locked vaults are
>> important for Bitcoin and also acknowledge that soft forks, such as the =
one
>> required for OP_VAULT, aren't easy to implement, I'd argue that the
>> intermediate solution described above is very relevant.
>>
>
> To support this use case of the taproot annex, I've create a simple demo
> application here: https://github.com/joostjager/annex-covenants
>
> This demo shows how a coin can be spent to a special address from which i=
t
> can - at a later stage - only move to a pre-defined final destination. It
> makes use of the annex to store the ephemeral signature for the presigned
> transaction so that the coin cannot get lost. This is assuming that nodes
> do not prune witness data en masse and also that the destination address
> itself is known.
>
> The application may not be the most practically useful, but more advanced
> covenants such as time-locked vaults can be implemented similarly.
>
> Hopefully this further raises awareness of the on-chain ephemeral
> signature backup functionality that the annex uniquely enables.
>
> Joost
>

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

<div dir=3D"ltr">Hi Joost,<div><br></div><div>&gt; Hopefully this further r=
aises awareness of the on-chain ephemeral signature backup functionality th=
at the annex uniquely enables.</div><div><br></div><div>From my perspective=
, if vault applications can be made more robust by on-chain backing up of e=
phemeral signatures, this can be rational to make the annex standard.</div>=
<div><br></div><div>There is the observation that other critical elements=
=C2=A0of vault&#39;s application state could be backed up in this way (e.g =
pubkeys and amounts of the=C2=A0destination output) to rebuild from scratch=
 a pre-signed withdrawal. The unstructured data could be even marked by an =
application-level &quot;tag&quot; or &quot;signaling&quot; to identify all =
the backup annexes composing your vault application state.</div><div><br></=
div><div>Of course, such backing up of more critical elements comes with it=
s own drawbacks in terms of confidentiality, as you=C2=A0would leak your va=
ult policy on-chain, so they would need to be ciphered first, I think.</div=
><div><br></div><div>It sounds to me another economically rational set of u=
se-cases can be to simplify protocols using the chain as a publication spac=
e for collectibles. Using the annex as a publication space enables a clear =
chain of collectible ownership thanks to the key signing the annex, which i=
s not permissible with op_return outputs today.</div><div><br></div><div>Be=
st,</div><div>Antoine</div><div><br></div><font color=3D"#888888"></font></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 20 juin 2023 =C3=A0=C2=A013:30, Joost Jager &lt;<a href=3D"mailt=
o:joost.jager@gmail.com">joost.jager@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,</div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 10, 2023=
 at 9:43=E2=80=AFAM Joost Jager &lt;<a href=3D"mailto:joost.jager@gmail.com=
" target=3D"_blank">joost.jager@gmail.com</a>&gt; wrote:</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_quote">However, the primary advant=
age I see in the annex is that its data isn&#39;t included in the calculati=
on of the txid or a potential parent commit transaction&#39;s txid (for ins=
criptions). I&#39;ve explained this at [1]. This feature makes the annex a =
powerful tool for applications that would ideally use covenants.<br><br>The=
 most critical application in this category, for me, involves time-locked v=
aults. Given the positive reception to proposals such as OP_VAULT [2], I do=
n&#39;t think I&#39;m alone in this belief. OP_VAULT is probably a bit furt=
her out, but pre-signed transactions signed using an ephemeral key can fill=
 the gap and improve the safeguarding of Bitcoin in the short term.<br><br>=
Backing up the ephemeral signatures of the pre-signed transactions on the b=
lockchain itself is an excellent way to ensure that the vault can always be=
 &#39;opened&#39;. However, without the annex, this is not as safe as it co=
uld be. Due to the described circular reference problem, the vault creation=
 and signature backup can&#39;t be executed in one atomic operation. For ex=
ample, you can store the backup in a child commit/reveal transaction set, b=
ut the vault itself can be confirmed independently and the backup may never=
 confirm. If you create a vault and lose the ephemeral signatures, the fund=
s will be lost.<br><br>This use case for the annex has been labeled &#39;sp=
eculative&#39; elsewhere. To me, every use case appears speculative at this=
 point because the annex isn&#39;t available. However, if you believe that =
time-locked vaults are important for Bitcoin and also acknowledge that soft=
 forks, such as the one required for OP_VAULT, aren&#39;t easy to implement=
, I&#39;d argue that the intermediate solution described above is very rele=
vant.</div></div></blockquote><div><br></div><div>To support this use case =
of the taproot annex, I&#39;ve create a simple demo application here:=C2=A0=
<a href=3D"https://github.com/joostjager/annex-covenants" target=3D"_blank"=
>https://github.com/joostjager/annex-covenants</a></div><div><br></div><div=
>This demo shows how a coin can be spent to a special address from which it=
 can - at a later stage - only move to a pre-defined final destination. It =
makes use of the annex to store the ephemeral signature for the presigned t=
ransaction so that the coin cannot get lost. This is assuming that nodes do=
 not prune witness data en masse and also that the destination address itse=
lf is known.</div><div><br></div><div>The application may not be the most p=
ractically useful, but more advanced covenants such as time-locked vaults c=
an be implemented similarly.</div><div><br></div><div>Hopefully this furthe=
r raises awareness of the on-chain ephemeral signature backup functionality=
 that the annex uniquely enables.</div><div><br></div><div>Joost</div></div=
></div>
</blockquote></div>

--000000000000d28d8305ffaefc8e--