F2Pool and MARA are mining Taproot Annexes
What it is and why it matters...
Good afternoon subscribers! Last week, Peter Todd reported that F2Pool is now mining annex-containing transactions, which now brings the total number of known pools mining them to two, including MARA. Here’s a tl;dr on what an annex is and why it’s worth paying attention to. Got questions? Tag us in a tweet or post on Nostr, and we’ll get to answering it 🙂
What is an annex?
An annex on a house is an additional room for extra space or storage or another dining room. The taproot upgrade that went live in 2021 included an “annex” space, which is kind of like a data “attic” on a bitcoin transaction. Currently transactions that include annexes aren’t allowed to be relayed across the network, but if you include one in a block it’s valid.
Where is the annex in taproot?
It’s extra data in the witness stack. You put it at the end of the stack on a taproot spend. It’s unstructured data and practically unlimited in size. It’s only available for script path spends.
From BIP341:
The annex (or the lack thereof) is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation.
What’s the annex for?
The annex’s use cases are unspecified which is to say there’s no rules or expectations of what to use it for. It’s basically a big data blob. The Taproot spec authors left it unspecified, but they also made including an annex non-standard. This means you can mine a transaction with an annex in a witness stack, but you can’t relay it across the normal mempool gossip network. This is where the F2Pool news comes in — you can send your annex transaction to them directly, and it’ll get included in a block.
The annex data is included in the signature for a taproot spend, so they have data security guarantees (no one can edit your annex data).
Who’s this useful for?
Anyone who wants witness discount “unlimited” data storage on bitcoin. Op-returns have a smaller stack limit (even when removing the 80-byte “datacarrier” limit, the maximum allowed for a bare script is 10k bytes[1]) and pay full price per byte. Annex data is a v1 taproot script. There is no limit on the size of v1 taproot witness scripts; instead you can’t exceed the blocksize limit of 4MB. Annex data is witness data, so it pays 25% of the fees the same data in an op-return or bare script would.
Another nice thing about using annexes for data is that it directly commits data into the chain, without needing to do the commit and reveal two-transactions step that the Ordinals Inscription protocol uses. It’s very similar to OP-RETURNs except it’s lower cost, allows for data up to the blocksize limit, and currently is not allowed to be relayed.
Should I use the Annex?
It is considered risky to add an annex to your transaction, as future softforks may add meaning to the data blobs in the annex, which may result in your funds being unspendable.
There’s a warning to this effect in the specification BIP341:
The annex is a reserved space for future extensions, such as indicating the validation costs of computationally expensive new opcodes in a way that is recognizable without knowing the scriptPubKey of the output being spent. Until the meaning of this field is defined by another softfork, users SHOULD NOT include
annexin transactions, or it may lead to PERMANENT FUND LOSS.
I want to send a transaction with an annex. How can I do this?
Use Libre Relay, Peter Todd’s bitcoin-core client with less restrictive relay rules. As rot13maxi notes, however, you’ll need to set the first byte in the annex to 0x00. You can find the most recent Libre Relay code here.
Specific details about the annex can be found the Taproot BIP341: