Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.31
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 104 Block75 in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 104 proposed Block75, a hard-fork rule that would recalculate maximum block size every 2,016 blocks in response to average use, targeting blocks that were 75% full. It sought predictable automatic capacity adjustment modelled loosely on difficulty retargeting.
- Why it matters: BIP 104 was a closed attempt to automate capacity through block fullness. Its feedback-control questions remain instructive, but the Block75 formula and hard-fork rules are not deployed Bitcoin consensus.
- Current position: The BIP is Closed and was never deployed; its formula is not part of Bitcoin consensus or mining policy.
BIP 104 Block75 in simple English
BIP 104 Block75: No current wallet, miner or node should calculate validity from Block75. Experimental forks must use isolated networks and unmistakable chain identifiers.
Simple example
A node operator is checking BIP 104 Block75. The maximum size would move according to current maximum multiplied by the difference between observed average capacity and the 75% target.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Proposed feedback rule
The maximum size would move according to current maximum multiplied by the difference between observed average capacity and the 75% target. Full periods would raise the limit and lightly used periods would lower it. Exact numeric representation, rounding and bounds would be consensus-critical.
Why it required a hard fork
Blocks above the existing limit are invalid to unmodified nodes. Increasing that limit cannot be enforced as a compatible restriction, so economically relevant validators would need coordinated new rules. Miner signalling or implementation availability alone could not make the new blocks acceptable.
Demand is not difficulty
Hashrate responds to proof-of-work incentives, whereas observed block fullness reflects fee demand, miner selection, spam, policy and the current cap. Treating fullness as a clean resource signal creates feedback and manipulation questions. A stable difficulty analogy does not prove a stable capacity controller.
Oscillation and boundary behaviour
A two-week averaging window delays response and can overshoot after abrupt demand changes. Empty or full adversarial blocks may influence the next cap. Simulation needs rounding, minimum and maximum limits, consecutive-period behaviour and reorganisations crossing the adjustment boundary.
Miner and user incentives
Miners choose which transactions enter blocks and may have incentives around fees, propagation and future limits. Users react to available capacity and fee expectations. A controller whose input is strategic behaviour needs game-theoretic and network-propagation analysis, not just arithmetic examples.
Closed status
No current wallet, miner or node should calculate validity from Block75. Experimental forks must use isolated networks and unmistakable chain identifiers. A block accepted by prototype software is not evidence of Bitcoin consensus compatibility.
Research lessons
The proposal usefully exposes design questions for adaptive limits: objective inputs, manipulation cost, control lag, bounded change, initial conditions, reorganisation semantics and upgrade coordination. Those questions should be evaluated against deployed block weight and fee-market behaviour without implying adoption. Build a version-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is the main point of BIP 104 Block75?
BIP 104 Block75: No current wallet, miner or node should calculate validity from Block75. Experimental forks must use isolated networks and unmistakable chain identifiers.
For BIP 104 Block75, what should a beginner know about proposed feedback rule?
The maximum size would move according to current maximum multiplied by the difference between observed average capacity and the 75% target.
For BIP 104 Block75, why it required a hard fork?
Blocks above the existing limit are invalid to unmodified nodes. Increasing that limit cannot be enforced as a compatible restriction, so economically relevant validators would need coordinated new rules.
For BIP 104 Block75, what should a beginner know about demand is not difficulty?
Hashrate responds to proof-of-work incentives, whereas observed block fullness reflects fee demand, miner selection, spam, policy and the current cap.
Conclusion
BIP 104 was a closed attempt to automate capacity through block fullness. Its feedback-control questions remain instructive, but the Block75 formula and hard-fork rules are not deployed Bitcoin consensus.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.