You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -65,8 +63,9 @@ Bitcoin should "do one thing, and do it well". By rejecting data storage, this B
65
63
66
64
'''Why limit scriptPubKeys to 34 bytes?'''
67
65
68
-
scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes.
69
-
They generally cannot be pruned.
66
+
scriptPubKeys must be stored indefinitely in storage that is as fast as possible.
67
+
Fast storage (usually RAM) is much more costly per byte than slower, non-volatile storage, so as the UTXO set size increases, this increases the burden on noderunners, harming decentralization.
68
+
scriptPubKeys generally cannot be pruned.
70
69
They are also a direct cost to the sender rather than the receiver.
71
70
For these reasons, modern usage is all 34 bytes or smaller in practice; actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash.
72
71
Furthermore, large scriptPubKeys, in addition to being a data embedding vector, can be abused to create malicious transactions and blocks ("poison blocks") that take a long time to validate.
@@ -75,7 +74,7 @@ Large scriptPubKeys, thus carrying a large abuse potential and no benefit, are i
75
74
'''What about OP_RETURN? Why not get rid of it entirely?'''
76
75
77
76
OP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set.
78
-
Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and no legitimate uses have ever been found.
77
+
Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and with the possible exception of commitment schemes that use OP_RETURN in coinbase transaction outputs (notably Segwit), using OP_RETURN is not the optimal solution to any known use case.
79
78
With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated.
80
79
However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.
We propose deployment via a modified version of BIP9 with an unconditional `max_activation_height`, ~9 months from the start of the signaling period (nStartTime=1764547200 or ~December 1, 2025).
300
+
This deployment uses a modified version of BIP9 with the following parameters:
302
301
303
-
This sets max_activation_height to block 965664, which is ~2026-09-01.
* '''active_duration''': 52416 blocks (~1 year after activation)
309
+
* '''threshold''': 1109/2016 (55%)
304
310
305
-
The expiry will be 52416 blocks (~1 year) after activation.
311
+
===Deviations from BIP9===
306
312
307
-
The deployment will be named `reduced_data` and miner signaling will use bit 4.
313
+
This deployment deviates from standard BIP9 in five ways:
308
314
309
-
The activation threshold will be 55% (1109 out of 2016 blocks in a single difficulty-adjustment period).
315
+
'''Reduced threshold (55% instead of 95%)''': The standard BIP9 threshold of 95% is designed for permanent consensus changes where near-universal miner readiness is desirable. Since rejecting data storage is a matter of urgency, and since this softfork is temporary and expires after one year, a lower threshold is ideal.
316
+
317
+
'''No timeout, using max_activation_height instead''': Standard BIP9 uses a time-based timeout that transitions to FAILED if the threshold is not reached. This deployment sets timeout to NO_TIMEOUT and instead uses a BIP8-like, height-based max_activation_height. The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664.
318
+
319
+
'''Mandatory signaling period''': Similar to BIP8, this deployment enforces mandatory signaling during the retarget period immediately before mandatory lock-in (blocks 961632 to 963647; lock-in happens no later than block 963648). During this window, blocks that do not signal bit 4 are rejected as invalid. Mandatory signaling ends once the deployment reaches the LOCKED_IN state.
320
+
321
+
'''Expiry via active_duration''': Standard BIP9 deployments are permanent once ACTIVE. This proposal includes an active_duration of 52416 blocks (~1 year), making the deployment temporary rather than permanent. The state machine remains in ACTIVE, but consensus rule enforcement is conditional: rules are only enforced for blocks with height < activation_height + active_duration. After 52416 blocks, the rules cease to be enforced and UTXOs are once again unrestricted.
322
+
323
+
'''State transitions''': The state machine follows this progression:
324
+
# DEFINED: Initial state until starttime
325
+
# STARTED: After starttime; miners may signal with bit 4
326
+
# LOCKED_IN: Entered when either (a) threshold is reached, or (b) height reaches 963648 (whichever comes first)
327
+
# ACTIVE: Entered one retarget period after LOCKED_IN; rules enforced for active_duration blocks
328
+
329
+
The FAILED state is never reached because timeout is disabled. ACTIVE is the final state; there are no transitions after it. Miner signaling after expiry has no effect because the deployment is no longer in the STARTED state, and miner signaling only governs the STARTED → LOCKED_IN transition. After active_duration blocks, the deployment remains in the ACTIVE state but rules are no longer enforced. There is no separate EXPIRED state in the state machine.
0 commit comments