From 676d78fdd8aac0de9d4397fb43564fe5d29f9abe Mon Sep 17 00:00:00 2001
From: billymcbip <245003547+billymcbip@users.noreply.github.com>
Date: Wed, 19 Nov 2025 17:35:02 +0100
Subject: [PATCH 1/4] Add BIP: Consensus ScriptPubKey Length Limit
---
bip-????.mediawiki | 89 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
create mode 100644 bip-????.mediawiki
diff --git a/bip-????.mediawiki b/bip-????.mediawiki
new file mode 100644
index 0000000000..5b106eb8d5
--- /dev/null
+++ b/bip-????.mediawiki
@@ -0,0 +1,89 @@
+
+ BIP: ?
+ Layer: Consensus (soft fork)
+ Title: Consensus ScriptPubKey Length Limit
+ Author: billymcbip@proton.me
+ Status: Draft
+ Type: Specification
+ License: MIT
+ Version: 1.0.0
+
+
+==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:
+
+ 1 byte OP_RETURN
+ 1 byte OP_PUSHDATA2
+ 2 bytes length
+256 bytes data
+
+
+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.
From 38798f884e334cf544743d8e25c2db612be75d6d Mon Sep 17 00:00:00 2001
From: billymcbip <245003547+billymcbip@users.noreply.github.com>
Date: Thu, 20 Nov 2025 15:35:31 +0100
Subject: [PATCH 2/4] Updated BIP: Consensus ScriptPubKey Length Limit In Most
Blocks
---
bip-????.mediawiki | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/bip-????.mediawiki b/bip-????.mediawiki
index 5b106eb8d5..3957839231 100644
--- a/bip-????.mediawiki
+++ b/bip-????.mediawiki
@@ -1,21 +1,22 @@
BIP: ?
Layer: Consensus (soft fork)
- Title: Consensus ScriptPubKey Length Limit
+ Title: Consensus ScriptPubKey Length Limit In Most Blocks
Author: billymcbip@proton.me
Status: Draft
Type: Specification
License: MIT
+ Discussion: 2025-10-02: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/cgnE52cSAgAJ
Version: 1.0.0
==Abstract==
-Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs).
+Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs) in most (254/255) blocks.
==Specification==
-Transactions in blocks at or above the activation height (''tbd'') cannot include outputs with ScriptPubKeys that are longer than 260 bytes.
+Transactions in blocks at or above the activation height (''tbd'') cannot include outputs with ScriptPubKeys that are longer than 260 bytes unless the block height is a factor of 256 (block_height % 256 == 0).
==Motivation==
@@ -25,6 +26,8 @@ The motivation of this BIP is to reduce the amount of arbitrary data that can be
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.
+Since Bitcoin is money, we must avoid setting any precedent for confiscation, i.e. making previously spendable UTXOs unspendable. Some users may hold pre-signed transactions that create new ScriptPubKeys longer than 260 bytes and no longer control the private keys that signed them. To avoid invalidating these transactions, we allow them to be processed in one out of every 255 blocks (block_height % 256 == 0), i.e. in roughly one block every ~42 hours. BIP34 lets us extract the block height from the coinbase transaction. Of course, this exception also allows any other large OP_RETURN outputs to be included in those blocks, but such transactions are throttled.
+
==Rationale==
'''Why limit OP_RETURN at all? Why not block OP_RETURN completely?'''
@@ -36,14 +39,14 @@ However, OP_RETURN should only be ''marginally'' more attractive for data embedd
'''Why 260 bytes?'''
The length of ScriptPubKeys for all standard outputs is well below 260 bytes:
+* P2PK: up to 67 bytes
+* P2MS: up to 201 bytes (max. 3 keys are standard)
* 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:
1 byte OP_RETURN
@@ -84,6 +87,10 @@ Soft fork, backwards compatible.
This BIP is inspired by parts of the "Reduced Data Temporary Softfork" (https://github.com/bitcoin/bips/pull/2017).
+@moonsettler and @portlandhodl provided direct feedback.
+
+@portlandhodl suggested a 520-byte limit without a block height exception. See: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/cgnE52cSAgAJ
+
==Copyright==
This document is licensed under the MIT License.
From 54883a00ddb8039dd1933a259571e36d948a48b1 Mon Sep 17 00:00:00 2001
From: billymcbip <245003547+billymcbip@users.noreply.github.com>
Date: Thu, 20 Nov 2025 15:51:48 +0100
Subject: [PATCH 3/4] Updated BIP: Consensus ScriptPubKey Length Limit In Most
Blocks
---
bip-????.mediawiki | 1 +
1 file changed, 1 insertion(+)
diff --git a/bip-????.mediawiki b/bip-????.mediawiki
index 3957839231..1ed60dc87c 100644
--- a/bip-????.mediawiki
+++ b/bip-????.mediawiki
@@ -46,6 +46,7 @@ The length of ScriptPubKeys for all standard outputs is well below 260 bytes:
* P2WPKH: 22 bytes
* P2WSH: 34 bytes
* P2TR: 34 bytes
+* WITNESS_UNKNOWN: up to 42 bytes
A 260 byte limit allows 256 bytes of data in OP_RETURN outputs:
From bfee3c5bdc562ce7dcd40f5acfe05003758a5a81 Mon Sep 17 00:00:00 2001
From: billymcbip <245003547+billymcbip@users.noreply.github.com>
Date: Thu, 20 Nov 2025 16:10:03 +0100
Subject: [PATCH 4/4] Updated BIP: Consensus ScriptPubKey Length Limit In Most
Blocks
---
bip-????.mediawiki | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bip-????.mediawiki b/bip-????.mediawiki
index 1ed60dc87c..e99982ba60 100644
--- a/bip-????.mediawiki
+++ b/bip-????.mediawiki
@@ -12,7 +12,7 @@
==Abstract==
-Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs) in most (254/255) blocks.
+Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs) in most (255/256) blocks.
==Specification==
@@ -26,7 +26,7 @@ The motivation of this BIP is to reduce the amount of arbitrary data that can be
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.
-Since Bitcoin is money, we must avoid setting any precedent for confiscation, i.e. making previously spendable UTXOs unspendable. Some users may hold pre-signed transactions that create new ScriptPubKeys longer than 260 bytes and no longer control the private keys that signed them. To avoid invalidating these transactions, we allow them to be processed in one out of every 255 blocks (block_height % 256 == 0), i.e. in roughly one block every ~42 hours. BIP34 lets us extract the block height from the coinbase transaction. Of course, this exception also allows any other large OP_RETURN outputs to be included in those blocks, but such transactions are throttled.
+Since Bitcoin is money, we must avoid setting any precedent for confiscation, i.e. making previously spendable UTXOs unspendable. Some users may hold pre-signed transactions that create new ScriptPubKeys longer than 260 bytes and no longer control the private keys that signed them. To avoid invalidating these transactions, we allow them to be processed in one out of every 256 blocks (block_height % 256 == 0), i.e. in roughly one block every ~42 hours. BIP34 lets us extract the block height from the coinbase transaction. Of course, this exception also allows any other large OP_RETURN outputs to be included in those blocks, but such transactions are throttled.
==Rationale==