Subject: Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs

From: Murch <[email-masked]>
Date: Wed, 9 Aug 2023 15:06:49 +0200

Hi John,

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space

Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:

An OP_RETURN output has an overhead of 10 bytes: 8 bytes for the amount, and a byte each for output script length and OP_RETURN.

An inscription envelope requires a P2TR output and a P2TR scriptpath input as overhead. A P2TR output weighs 43 vB, a cursory glance suggests that the prevalent inscription input seems to be a depth 0 P2TR scriptpath spend where the leaf script consumes a signature via a CHECKSIG to be followed by the payload envelope. Compared to a P2TR keypath spend this adds something like 8 WU for the leaf script and envelope as well as 34 WU for the controlblock. A keypath spend takes 230 WU, so the total overhead of an inscription lands somewhere around 111 vB (the additional ‘ord’ label and meta header with encoding information are considered part of the payload here). After that, the payload gets a discount of 75%.

Solving

111 + 0.25*payload_size = 10 + payload_size

we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.

Further, tooling for OP_RETURNs should be more broadly available than software that creates inscriptions, so it seems to me that dropping this limit would make it cheaper to publish certain data payload sizes to the blockchain, and also make publication of larger payloads significantly more accessible. Anyway, it’s not obvious to me why we should relax restrictions on publication mechanisms just because it’s already happening in a different manner (that also only uses blockspace but doesn’t add to the UTXO set). At that point this proposal neither seems to be a trivial mempool policy change, nor a clear or significant improvement. Especially it’s not clear to me, why we should encourage further data publication on the blockchain.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

Are there any tools available that a full node operator could use to prune this data from their nodes?

Yes. Running your Bitcoin Core node in prune mode will discard nulldata outputs when it discards the block.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

i) Is the unspendable output pruning implemented in PR #2791 on by default or is this a flag that needs to be enabled by full node operators? If it's a flag, what is the flag called and how can it be enabled? If it's on by default, how can it be disabled?

No other special pruning methods beyond pruning of blockchain data have been implemented in Bitcoin Core. Nor am I aware of any that have significant benefits over just pruning blockchain data.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

ii) If a full node operator does prune OP_RETURN outputs, does that in any way impair their ability to help a new node do IBD to validate the blockchain? And would that answer be any different if we were talking about pruning Taproot witness space (i.e. "envelopes" or "inscriptions") instead of OP_RETURN outputs?

A transaction from which inscription data or OP_RETURN data has been removed is incomplete and cannot be validated. If a node operator were to discard either data, they would not be able to serve complete blocks and therefore would no longer be able to assist in IBD.

Given that the proposal is obviously controversial, and the social media attention this and a few related pull requests have gotten is already causing brigading, I don’t think it’s going to be a priority for me to further engage with this proposal.
Cheers,
Murch