Pull-req to remove the arbitrary limits on OP_Return outputs

https://github.com/bitcoin/bitcoin/pull/28130

Sjors Provoost suggested that I email this mailing list as notice of my intent to get a pull-req merged that would remove the arbitrary 80-byte, 1 output / tx, standardness restrictions on OP_Return outputs. His rationale was that removing these standardness restrictions could potentially open up additional transaction pinning(1) vectors. Since this is a potential problem with any relaxation of standardness rules, I don't consider this to be an important concern. But consider this email your notice.

At least some miners appear to be mining non-bitcoin-core-standard transactions. So with respect to the hash power of those miners these pinning vectors may in fact exist already.

# References

1) https://bitcoinops.org/en/topics/transaction-pinning/

Hi Peter,

Re: https://github.com/bitcoin/bitcoin/pull/28130

I have a few questions about your proposal and its impact on full node operators:

1. With your proposed policy change removing the OP_RETURN output count and data size limits, 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 e.g. the envelope technique inscriptions use? Robin Linus suggested on your PR there may be a case that "effectively results in a discount for small inscriptions".[1] It would be good to have confirmation on this and specific details about the range of inscription sizes that would receive the discount if this is true. (Robin himself is of course also welcome to answer this question; I have cc'd him directly on this email as an invitation to respond.)

2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes? While researching this question I found PR #2791 from Pieter Wuille, which implemented pruning of provably-unspendable outputs, which I assume includes OP_RETURN outputs.[3] After looking around some more and not finding definitive answers, I have a few new questions about this:
  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?
  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?

Regards,

John Light

[1] https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1664950834

[2] https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain

[3] https://github.com/bitcoin/bitcoin/pull/2791

Good morning John Light,

> 2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes?

As I understand it, `OP_RETURN` outputs are already pruned, in the sense that they are never put in the UTXO database in the first place. Indeed, as I understand it, "pruning" in this context is about removing (or not inserting at all, in the case of `OP_RETURN`) from the UTXO database. UTXO database is best to keep small to reduce lookups of UTXOs being spent, as that impacts speed of validation.

Archival nodes still retain the raw `OP_RETURN` data as part of the raw block data, as it is necessary to prove that those transactions are (1) valid transactions and (2) part of (i.e. in the Merkle tree of) a valid block on the block header chain. Block-pruning nodes also still retain this data, as they can at least serve recent blocks with the same requirement of proving that transactions containing `OP_RETURN` are valid transactions in a valid block on the block header chain.

If you want to prove that a block is valid, you need to present even `OP_RETURN` data, as you need to be able to show the actual transaction containing it, so that the verifier can see that the transaction is correctly formatted and its txid matches the supposed location in the Merkle tree. Block relay requires that the node relaying a block prove that that block is indeed valid, thus you need to retain the `OP_RETURN` data. Thus, in this context "pruning" refers to not keeping `OP_RETURN` TXOs in the UTXO database.

Regards, ZmnSCPxj

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