From: Joost Jager <joost.jager@gmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Sat, 10 Jun 2023 09:43:52 +0200 [thread overview]
Message-ID: <CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+FyVQpMAf-gPmUgh6ORqa2K59iKZKsa3Qm2Fw_U+GHC3Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4315 bytes --]
Hi Antoine,
On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard <antoine.riard@gmail•com>
wrote:
> From a taproot annex design perspective, I think this could be very
> valuable if you have a list of unstructured data use-cases you're thinking
> about ?
>
The annex's list of unstructured data use-cases includes existing data
storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,
timestamps, and any other data already stored on the chain. These
applications would immediately benefit from the annex's improved space
efficiency.
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 ideally
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 probably
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 short
term.
Backing up the ephemeral signatures of the pre-signed transactions on the
blockchain itself is an excellent way to ensure that the vault can always
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 the
vault itself can be confirmed independently and the backup may never
confirm. If you create a vault and lose the ephemeral signatures, the funds
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.
> As raised on the BIP proposal, those unstructured data use-cases could use
> annex tags with the benefit to combine multiple "types" of unstructured
> data in a single annex payload. As you're raising smaller bits of
> unstructured data might not afford the overhead though my answer with this
> observation would be to move this traffic towards some L2 systems ? In my
> mind, the default of adding a version byte for the usage of unstructured
> data comes with the downside of having future consensus enabled use-cases
> encumbering by the extended witness economic cost.
>
When it comes to the trade-offs associated with various encodings, I fully
acknowledge their existence. The primary motivation behind my proposal to
adopt a simple approach to the Taproot annex is to avoid a potentially long
standardization process. While I am not entirely familiar with the
decision-making process of Bitcoin Core, my experience with other projects
suggests that simpler changes often encounter less resistance and can be
implemented more swiftly. Perhaps I am being overly cautious here, though.
> About the annex payload extension attack described by Greg. If my
> understanding of this transaction-relay jamming griefing issue is correct,
> we can have an annex tag in the future where the signer is committing to
> the total weight of the transaction, or even the max per-input annex size ?
> This should prevent a coinjoin or aggregated commitment transaction
> counterparty to inflate its annex space to downgrade the overall
> transaction feerate, I guess. And I think this could benefit unstructured
> data use-cases too.
>
Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?
Joost
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html
[2] https://github.com/bitcoin/bips/pull/1421
[3] https://github.com/bitcoin/bitcoin/pull/24007
[-- Attachment #2: Type: text/html, Size: 5336 bytes --]
next prev parent reply other threads:[~2023-06-10 7:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 15:00 Joost Jager
2023-06-03 1:08 ` David A. Harding
2023-06-03 1:14 ` Greg Sanders
2023-06-03 9:14 ` Joost Jager
2023-06-03 15:50 ` Peter Todd
2023-06-15 9:36 ` Joost Jager
2023-06-15 10:39 ` Greg Sanders
2023-06-16 11:26 ` Joost Jager
2023-06-16 13:30 ` Greg Sanders
2023-06-18 20:32 ` Antoine Riard
2023-06-18 20:40 ` Greg Sanders
2023-06-19 1:14 ` Antoine Riard
2023-06-20 12:50 ` Joost Jager
2023-06-03 7:49 ` Joost Jager
2023-06-03 8:06 ` Joost Jager
2023-06-03 12:05 ` Greg Sanders
2023-06-03 12:35 ` Joost Jager
2023-06-03 12:43 ` Greg Sanders
2023-06-03 12:55 ` Joost Jager
2023-06-08 9:16 ` Joost Jager
2023-06-10 0:23 ` Antoine Riard
2023-06-10 7:43 ` Joost Jager [this message]
2023-06-10 22:09 ` David A. Harding
2023-06-11 19:25 ` Joost Jager
2023-06-12 3:16 ` Antoine Riard
2023-06-13 8:51 ` David A. Harding
2023-06-13 10:38 ` Joost Jager
2023-06-12 13:03 ` Greg Sanders
2023-06-20 12:30 ` Joost Jager
2023-07-04 20:18 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJBJmV9SGXaf90X4oyTx7o+DG4-P58gUyiCGz+K08XZAOFBf2g@mail.gmail.com \
--to=joost.jager@gmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox