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 100 Dynamic maximum block size by miner vote 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 100 proposed a hard-fork rule that would recalculate Bitcoin’s maximum block size every 2,016 blocks from miner votes recorded in coinbase data. A 75 per cent supermajority could move the limit, with each adjustment constrained to roughly five per cent.
- Why it matters: BIP 100 offered a deterministic miner-vote mechanism for block-size changes, but it remained a hard-fork proposal and closed. Its value today is as a governance and compatibility case study, not a mainnet operating rule.
- Current position: The proposal is Closed and is not part of Bitcoin mainnet consensus; historical deployment language in its text does not override the current status or active validation rules.
BIP 100 Dynamic maximum block size by miner vote in simple English
BIP 100 Dynamic maximum block size by miner vote: A raise used the 1,512th highest vote. A decrease used the 1,512th lowest, corresponding to three quarters of a 2,016-block window.
Simple example
A node operator is checking BIP 100 Dynamic maximum block size by miner vote. Compare independent nodes across several windows and intentionally connect a fixed-limit node when a larger block arrives.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Bitcoin Core:
- Widely used software that validates Bitcoin and can provide wallet, network and operator tools.
- 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.
The governance mechanism
Miners would place a megabyte vote pattern in the coinbase scriptSig. Nodes following BIP 100 would collect one difficulty period of 2,016 votes, sort them and derive the next period’s hard limit. Missing or zero votes counted for the current limit, preventing silence from becoming automatic support for change.
Seventy-five per cent threshold
A raise used the 1,512th highest vote; a decrease used the 1,512th lowest, corresponding to three quarters of a 2,016-block window. The percentile construction limited a minority’s influence but still granted miners a direct parameter-setting role. Hash-power signalling did not prove economic-user agreement.
Five per cent adjustment bound
Even if votes requested a large change, the next hard limit could move only by about a factor of 1.05 up or down per period. The bound damped sudden shifts but made the value stateful across windows. Every validating implementation had to reproduce rounding, vote parsing and boundary selection exactly.
Related resource limits
The proposal scaled signature-hashing operation limits with actual block size rounded to the next megabyte and imposed a one-megabyte maximum serialised transaction size. Raising one resource ceiling without coordinated CPU, memory, bandwidth and propagation analysis could move denial-of-service pressure elsewhere.
Why it was a hard fork
A block above the existing one-megabyte limit would be rejected by fixed-limit nodes and accepted by BIP 100 nodes, partitioning the network. Before such a block, compatible-looking signalling did not eliminate the fork boundary. Rollout required users and businesses to choose new validation software, not merely miners to publish votes.
Closed status and historical claims
The document contains presumed-activation wording tied to implementations and a height, but the repository status is Closed and Bitcoin mainnet did not adopt this rule as its current block-size mechanism. Articles must present both facts and defer to current consensus code rather than an obsolete proposal’s prospective language.
Safe simulation
Implement vote parsing and recalculation on an isolated chain, including absent, malformed, extreme and boundary votes. Compare independent nodes across several windows and intentionally connect a fixed-limit node when a larger block arrives. Never enable the historical fork rules on a production mining failover.
Frequently asked questions
What is the main point of BIP 100 Dynamic maximum block size by miner vote?
BIP 100 Dynamic maximum block size by miner vote: A raise used the 1,512th highest vote.
For BIP 100 Dynamic maximum block size by miner vote, what should a beginner know about the governance mechanism?
Miners would place a megabyte vote pattern in the coinbase scriptSig. Nodes following BIP 100 would collect one difficulty period of 2,016 votes, sort them and derive the next period’s hard limit.
For BIP 100 Dynamic maximum block size by miner vote, what should a beginner know about seventy-five per cent threshold?
A raise used the 1,512th highest vote. A decrease used the 1,512th lowest, corresponding to three quarters of a 2,016-block window.
For BIP 100 Dynamic maximum block size by miner vote, what should a beginner know about five per cent adjustment bound?
Even if votes requested a large change, the next hard limit could move only by about a factor of 1.05 up or down per period.
Conclusion
BIP 100 offered a deterministic miner-vote mechanism for block-size changes, but it remained a hard-fork proposal and closed. Its value today is as a governance and compatibility case study, not a mainnet operating rule.
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.