MIME-Version: 1.0
References: <CAJBJmV-L4FusaMNV=_7L39QFDKnPKK_Z1QE6YU-wp2ZLjc=RrQ@mail.gmail.com>
 <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
In-Reply-To: <29ff546a6007cec1a0f85b91541f8e4d@dtrt.org>
From: Joost Jager <joost.jager@gmail.com>
Date: Sat, 3 Jun 2023 09:49:36 +0200
Message-ID: <CAJBJmV9JYYOSJXbzhrGTrv3jf_qGoLRbq9COgbBmuinpNAOhDg@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000005cc11b05fd34ebfd"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Precedence: list

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

Hi David,

On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David A. Harding <dave@dtrt.org> wro=
te:

> Out of curiosity, what features and benefits are available today?  I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT.  I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>

Indeed, there's a minor efficiency gain in the reveal transaction witness,
but I think the real advantage is that it eliminates the need to publish
and pay for the commit transaction in the first place. Any spend of a
taproot UTXO can be supplemented with arbitrary data in just a single
transaction.


> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?


The removal of the need for a commitment transaction also enables the
inclusion of data within a single transaction that relies on its own
transaction identifier (txid). This is possible because the txid
calculation does not incorporate the annex, where the data would be housed.
This feature can be beneficial in scenarios that require the emulation of
covenants through the use of presigned transactions involving an ephemeral
signer.

For instance, one can establish a time-locked vault using 2-of-2 multisig
presigned transactions in which one of the signers is ephemeral [1]. After
signing, the private key is discarded, leaving only the signature. To
ensure the signature is never lost, it can be stored as a backup in the
annex of the transaction that the presigned transaction spends. Such an
operation would not be possible with a commit/reveal inscription.

[1] https://github.com/LedgerHQ/app-bitcoin-new/issues/153

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

<div dir=3D"ltr"><div>Hi David,</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Sat, Jun 3, 2023 at 3:08=E2=80=AFAM David=
 A. Harding &lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wrot=
e:</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">
Out of curiosity, what features and benefits are available today?=C2=A0 I <=
br>
know Greg Sanders wants to use annex data with LN-Symmetry[1], but <br>
that&#39;s dependent on a soft fork of SIGHASH_ANYPREVOUT.=C2=A0 I also hea=
rd you <br>
mention that it could allow putting arbitrary data into a witness <br>
without having to commit to that data beforehand, but that would only <br>
increase the efficiency of witness stuffing like ordinal inscriptions by <b=
r>
only 0.4% (~2 bytes saved per 520 bytes pushed) and it&#39;d still be <br>
required to create an output in order to spend it.<br></blockquote><div><br=
></div><div>Indeed, there&#39;s a minor efficiency gain in the reveal trans=
action witness, but I think the real advantage is that it eliminates the ne=
ed to publish and pay for the commit transaction in the first place. Any sp=
end of a taproot UTXO can be supplemented with arbitrary data in just a sin=
gle transaction.<br></div><div>=C2=A0</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">
Is there some other way to use the annex today that would be beneficial <br=
>
to users of Bitcoin?</blockquote><div><br></div><div>The removal of the nee=
d for a commitment transaction also enables the inclusion of data within a =
single transaction that relies on its own transaction identifier (txid). Th=
is is possible because the txid calculation does not incorporate the annex,=
 where the data would be housed. This feature can be beneficial in scenario=
s that require the emulation of covenants through the use of presigned tran=
sactions involving an ephemeral signer.<br><br>For instance, one can establ=
ish a time-locked vault using 2-of-2 multisig presigned transactions in whi=
ch one of the signers is ephemeral=C2=A0[1]. After signing, the private key=
 is discarded, leaving only the signature. To ensure the signature is never=
 lost, it can be stored as a backup in the annex of the transaction that th=
e presigned transaction spends. Such an operation would not be possible wit=
h a commit/reveal inscription.<br></div><div><br></div><div>[1]=C2=A0<a hre=
f=3D"https://github.com/LedgerHQ/app-bitcoin-new/issues/153">https://github=
.com/LedgerHQ/app-bitcoin-new/issues/153</a></div></div></div>

--0000000000005cc11b05fd34ebfd--