BIP draft: Consensus ScriptPubKey Length Limit

bip-????.mediawiki

@@ -0,0 +1,89 @@
+<pre>
+  BIP: ?
+  Layer: Consensus (soft fork)
+  Title: Consensus ScriptPubKey Length Limit
+  Author: billymcbip@proton.me
+  Status: Draft
+  Type: Specification
+  License: MIT
+  Version: 1.0.0
+</pre>
+
+==Abstract==
+
+Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs).
+
+==Specification==
+
+Transactions in blocks at or above the activation height (''tbd'') cannot include outputs with ScriptPubKeys that are longer than 260 bytes.
+
+==Motivation==
+
+Bitcoin is money. Transactions embedding arbitrary data compete with financial transactions for block space, and many node operators clearly do not want to process, relay or store arbitrary data.
+
+The motivation of this BIP is to reduce the amount of arbitrary data that can be embedded in transactions and in the UTXO set.
+
+A system with N independent bits of freedom can carry at most N bits of information. Limiting the length of ScriptPubKeys reduces independent bits of freedom within a block. More non-arbitrary bytes would have to wrap arbitrary bytes embedded in ScriptPubKeys.
+
+==Rationale==
+
+'''Why limit OP_RETURN at all? Why not block OP_RETURN completely?'''
+
+It is impossible to completely prevent arbitrary data in blocks. Therefore, it makes sense to continue offering a less harmful way to embed data, i.e. OP_RETURN.
+
+However, OP_RETURN should only be ''marginally'' more attractive for data embedding than methods leading to arbitrary data in the UTXO set.
+
+'''Why 260 bytes?'''
+
+The length of ScriptPubKeys for all standard outputs is well below 260 bytes:
+* P2PKH: 25 bytes
+* P2SH: 23 bytes
+* P2WPKH: 22 bytes
+* P2WSH: 34 bytes
+* P2TR: 34 bytes
+
+Even x-of-3 bare multisig scriptPubKeys are smaller than 260 bytes.
+
+A 260 byte limit allows 256 bytes of data in OP_RETURN outputs:
+<pre>
+  1  byte  OP_RETURN
+  1  byte  OP_PUSHDATA2
+  2 bytes  length
+256 bytes  data
+</pre>
+
+Any limit is somewhat arbitrary, but 256 is a multiple of 32, i.e. 8 SHA-256 hashes could be embedded.
+
+'''Why not limit non-OP_RETURN outputs to 34 bytes?'''
+
+Firstly, simplicity: A simple length check is easier to implement, no need to discriminate between OP_RETURN outputs and other outputs.
+
+Secondly, unknown unknowns: We may need longer scriptPubKeys in the future.
+
+'''Why change consensus rather than mempool policy?'''
+
+If we accept large OP_RETURN outputs in consensus but not in mempool policy, more transactions will be submitted directly to mining pools. This creates centralization pressure (see https://bitcoincore.org/en/2025/06/06/relay-statement/).
+
+'''Why does this BIP not include other measures to limit data embedding?'''
+
+The idea of this BIP is to allows the community to discuss the merits of a ScriptPubKey size limit in isolation. Limiting ScriptPubKey size can be an atomic change, it does not have to be implemented in conjunction with other, more complex anti-spam measures that constrain ''which'' UTXOs can be spent (rather than ''how'' UTXOs can be spent).
+
+==Backwards Compatibility==
+
+Soft fork, backwards compatible.
+
+==Reference Implementation==
+
+''tbd''
+
+==Deployment==
+
+''tbd''
+
+==Credits==
+
+This BIP is inspired by parts of the "Reduced Data Temporary Softfork" (https://github.com/bitcoin/bips/pull/2017).
+
+==Copyright==
+
+This document is licensed under the MIT License.