Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-03 🗒️ Summary of this message: Taproot's annex ...
📅 Original date posted:2023-06-03
🗒️ Summary of this message: Taproot's annex feature eliminates the need for a commit transaction, allowing for the inclusion of data within a single transaction, benefiting scenarios that require the emulation of covenants.
📝 Original message:
Hi David,
On Sat, Jun 3, 2023 at 3:08 AM David A. Harding <dave at dtrt.org> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/76c769ae/attachment.html>;
🗒️ Summary of this message: Taproot's annex feature eliminates the need for a commit transaction, allowing for the inclusion of data within a single transaction, benefiting scenarios that require the emulation of covenants.
📝 Original message:
Hi David,
On Sat, Jun 3, 2023 at 3:08 AM David A. Harding <dave at dtrt.org> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/76c769ae/attachment.html>;