Version0.

2(4September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

AHybridMechanismforAdaptively
AdjustingBitcoin'sBlockSizeLimit
[BIP10X]
ShortOverview
[Version 0.1 / 2 Sept 2015 Version 0.2 / 4 Sept 2015]

Abstract
This BIP proposes replacing the fixed one megabyte block size limit with a dynamically controlled
block size limit that may increase or slowly decrease in 1 week intervals, depending on different
criteria and constrains. These are:

Miner votes in 1-week intervals

Actual occupancy of blocks in the same 1-week voting intervals

Long-term change of the block size limit

Short-term load peaks

This document only gives a brief overview with no implementation details.

More details with concrete implementation guidelines, formulas, illustrative figures, simulation
code, simulation results, and with more detailed rationale on all design choices, can be found here:

Announcement on bitcointalk.org (last up-to-date version will be linked from here):

https://bitcointalk.org/index.php?topic=1166970.0

Motivation
Withincreasedadoption,transactionvolumeonBitcoinnetworkisboundtogrow.Iftheone
megabyteBlockSizeLimitisnotchangedtoaflexibleonewhichadaptstochangingnetwork
demandandtechnologicalprogress,BitcoinadoptionwillslowdownandtheBitcoinexperiment
mayeventuallyfail.Followinggraphshowsthechangeinaverageblocksizesinceinception:

https://blockchain.info/charts/avg-block-size?
timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&ad
dress=
The intention of this BIP is to permanently incorporate miner voting into the protocol instead of
doing de-facto voting within a protocol that does not actually support voting, by introducing hardforks into the network and let miner majority decide upon acceptance (=de-facto voting).
Integrating voting into the protocol should appease the minds and make future adaptations of the
BlockSizeLimit within the protocol the norm, based on market demands and technological
evolution. It should give planning security to all stakeholders, while developers can re-focus on
other important improvements. Constraints and growth rate limits shall further improve planning
1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[1of5]

Version0.2(4September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

security by avoiding sudden swings of the BlockSizeLimit in the first place.

So, unlike with BIP100, no overarching control is given to miner votes. Instead, actual block
occupancy is taken into consideration by providing a tolerance interval that saturates votes which
would otherwise be too far off. Another fixed tolerance span is defined for the long-term growth
rate of the BlockSizeLimit to avoid too arbitrary variations. However, unlike BIP101, the protocol
does allow adaptation to long-term evolution of markets and technologies, which cannot be
predicted from today into all future. This BIP therefore solves the most criticized points of the two
most popular proposals, BIP100 and BIP101, and shows a path that takes into account concerns
widely expressed by the community and felt by the author himself against BIP100 and BIP101.
Thanks to the way how this BIP is carefully constructed, it is not a rotten compromise but a fully
independent solution that combines the good ideas of BIP100 and BIP101 while eliminating their
main drawbacks.
Finally, the motivation of this BIP is also to have means for elastic reaction to temporary shortterm demands for traffic increase in the Bitcoin network while avoiding mis-use by sufficient
counter-incentive.

Specification
This BIP proposes a combination of several carefully designed features:

Part 0: Miner Voting for Initial BlockSizeLimit to Start with

Minervotesdeterminetheinitialblocksizelimitwith80%majorityatthestartofprotocol
activation.Thisinitialvoteisconstrainedto1..4Mbytes.Note:Regularvoteoneweeklatercan
alreadyincreasethisinitialvaluefurtherby41%(50%majority),orevendoubleitwithin2weeks
(80%majority),seePart3below.

Part 1: Miner Voting Regularly Every Week

Minersvoteevery1008blocks(=oneweek=halfofadifficultyadjustmentinterval).Forsimplicity,
minerscanbeconfiguredbytheoperatorstovoteforafixedamount,forafixedfactorrelativeto
averageactualblocksize,ortovotefornochangerelativetotheweekbefore.
Theeffectivevoteisthemedian(50%quantile)ofall1008minervotes.
Special:An80%majority(20%or80%quantilerespectively)hasthepowertoboostthelong
termgrowth(ordecline)ratebyaspeedupfactorof2(seePart3below).

Part 2: Average Actual Block Size During the Voting Period

Theprotocolcheckstheminervotesagainsttheactualblocksizeduringthesamevotinginterval.If
thediscrepancyistoolarge,theprotocoloverrulesthevotesbyforcingthemintoacarefully
designedtoleranceinterval(definedbytwoconstantfactors)aroundtheaverageactualblocksize.

Part 3: Long-Term Constraints on BlockSizeLimit's Evolution

Theminervote(i.e.thepossiblycorrectedvoteacc.toPart2)isfurtherconstrainedtoavoida
toofastgrowthordecline.Forthis,thepastlongtermaverageblocksizelimit(roughly12year
average,determinedbysimpleexponentialwindowaveragingwith62.5weekseff.window
length)istakenintoaccount,andthenewBlockSizeLimitisforcedtorespectthemin/maxgrowth
1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[2of5]

Version0.2(4September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

ratesof+41%p.a/8%p.a.(i.e.factorx2each2years,factorx0.5each8years).
Incaseof80%votemajority,morerelaxedconstraintsareappliedtothelongtermevolution:In
thiscasethelimitsare+100%p.a/16%p.a.(i.e.factorx2each1years,factorx0.5each4years).

Part 4: Absolute Limits on the BlockSizeLimit

TheTOTALlimitsonBlockSizeLimitaresettobebetween1MBand60.1GB.Thevalueof60.1GB
istheresultoftheconcreteimplementationproposalofthevotingformatandisnotexpectedtobe
metanytimesoon.Notethatonebitisreservedinthevotingformat.Whenreleasingthissparebit,
max.BlockSizeLimitwillverysimplyriseto3939TB(=morethan1TPSpereach(!)personon
earth,assuming>10Billionpeople).

Part 5: Elasticity by Overbooking

Inexceptionalcasesoftemporaryhightrafficload,blocksareallowedtoexceedthenominal
BlockSizeLimitbyuptoafactorof4.Theoccurrenceofsuchoverbookedblocksislimitedto30%
andevenstrictertoonly10%forblocksmorethan2timesaboveBlockSizeLimit(exponentially
averagedoverroughly35months).
Counterincentive:Minershavetoburn(spendtounspendableaddress)25%ofTXfeesattributed
totransactionsinexcessoftheBlockSizeLimit(detailedformulaavailableinthefullspec).

Part 6: Signaling in the Block Header's Version Number Field

VotesandsomeotherinformationneededforthisBIPareincludedinunusedpartsoftheblock
header's32bitversionnumberfield.Alldetailsavailableinthefullspec.

Rationale
Rationale Part 0: Miner Voting for Initial BlockSizeLimit to Start with
InsteadoffixingthestartBlockSizeLimitupfront,itismoreconsistentwiththeoverallideatoleave
thisdecisionstotheminers.Limitsof1to4MBaresettoavoidmisuse.The80%requirementis
chosentorespecttheneedsofmoreconservativeminersforthisinitialirrevocabledecision.

Rationale Part 1: Miner Voting Regularly Every Week

Trafficusageisexpectedtovarywithpatternsofweeklyperiodicity(workingdays,weekends).
Hencea1week(1008blocks)votingintervalischosen.Probablyforthesamereason,Satoshihas
chosen2weeks(2016blocks)asthedifficultyadjustmentinterval.
Quantilevoteevaluationinsteadofaveragingofvotesischosentoavoidthepossibility(or
need)fortacticalvoting,whichwouldreducefairnessandbringundesiredelementsofgamble
intothevotingprocess.Threshold=50%ischosenbecausethisistheBlockSizeLimitthatisnottoo
largefor50%ofvotersandnottoosmallfor50%ofvoters,hencemostfair.80%majorityfor
stretchingthelimitsoflongtermgrowth(ordecline)beyondthenormallimitsischosentokeepa
dooropenforfasterevolution,ifneeded,whilemakingabusedifficult.

1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[3of5]

Version0.2(4September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

Rationale Part 2: Average Actual Block Size During the Voting Period
Thisconstraintisproposedbecauseminervotesshouldnotstandagainstreality.Thisisareality
check,soifminersproducealmostemptyblocksandatthesametimevoteforanincrease,orif
minersproducealmostfullblocksbutvoteforadecrease,thisisconsideredinconsistentbythe
protocol.Inthiscase,theactualblocksizetakesprecedenceovertheminersvote.
Notethatinasensethesearealsominervotes,becauseitisuptotheminerstodecidehowmucha
blockgetsfilled.

Rationale Part 3: Long-Term Constraints on BlockSizeLimit's Evolution

Themaxgrowthratelimitof41%p.a.istakenfromtheoptimisticgrowthrateassumptionof
BIP101.The100%p.a.boostedlimit(for80%minermajority)istakenasaprecaution,should
eventhatnotbeenough.The8%declineratelimitischosenbecauseitopensupthegeneral
possibilitytodecreaseBlockSizeLimitforwhateverreason.However,timesoflowtrafficshouldnot
prematurelycauseatooquickdeclinethatmakesitdifficulttolatercomebacktotheoriginal
value,hencethedeclinerateislimitedmuchstricterthanthegrowthrate(factor2isonlyachieved
in8insteadof2years).The16%declineratefor80%minermajorityrealizesthesamefactor2
speedup(relativeto50%majority)asforthegrowthratecase.
Thisisthestrongestconstraint,itpotentiallyoverrulesthepreviousminers'decisions,thereby
avoidingminerabuseandallowinglongtermplanningsecuritynosuddensurprisesarepossible,
becauseBlockSizeLimitcanonlyevolveatlimitedpaceandinsmallsteps.Thisisofadvantagefor
minersandotherstakeholdersandtherebybeneficialfortheBitcoinecosystemasawhole.

Rationale Part 4: Absolute Limits on the BlockSizeLimit

Theselimitsaretheresultofthebitaccurateprotocolspecification,andassuchtheyprovideahuge
signalingrangethatshouldbefutureprooftilleternity,whilestillrequiringonlyfewbitsand
providingasufficientlyfinegranularityforthevotes.

Rationale Part 5: Elasticity by Overbooking

Thismechanismintroducesacertaindegreeofelasticitytoavoidbeinghelplessincaseahuge
amountoftransactionvolumeisunexpectedlyhittingtheBitcoinnetwork.
Themaxoverbookingfactor(x4),thelimitonblocksallowedtobeoverbooked(10%,30%)and
thecounterincentive(proofofburnof25%ofexcessTXfees)areintroducedtoavoidabuseand
toreallymakesurethatthenominalBlockSizeLimitisobeyedunderallnormalcircumstances.
Thedecisiontoburnthesebitcoinsinsteadofmakingthemavailabletolaterminersbyarollover
pool(assuggestedbyMeniRosenfeld)ispuresimplicity:Itisassumedthatthisisanexceptional
mechanism(andlessandlessneededthemoreBitcoinmaturesinthefuturewhenblockrewards
half),sothereisnotmuchbenefitinmakingtheprotocolchangeoverlycomplicatedhere,justto
avoidreducingtheoverallminerrewardsbyburningsomeTXfees.

Rationale Part 6: Signaling in the Block Header's Version Number Field

Thesignalingformatisfullyspecifiedinbitexactmanner,itissimpleandyetveryefficientinusage
ofbitspaceintheblockheader.
ThereasonforputtingallinformationofthisBIP(particularlythevotes)intotheheaderisgivenby
GavinAndreseninhisBIP101proposal'scommentonBIP100:
[...][HavingBIP100'svoteinthecoinbasescriptSig]ismorecomplextoimplement[thanBIP101's
1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[4of5]

Version0.2(4September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

solutiontoonlyhaveamodificationintheheader],because[withBIP100]themaximumallowedsize
forablockdependsoninformationcontainedincoinbasetransactionsfrompreviousblocks(whichmay
notbeimmediatelyknownifblockcontentsarebeingfetchedoutoforderina'headersfirst'mode)
WiththisBIP'sapproachtoincludethevote(andothernewinfos)intheheader'sversionnumber
field,thisdisadvantageisavoided.
Theversionnumberfielditselfhas32bits,whichismuchmorethanwhatisactuallyneeded.
Hence,2unusedbytesofthisfieldcanbeusedforthisBIP'spurposeswithoutanynegativeside
effects.

Compatibility
ThisisahardforkingchangetotheBitcoinprotocol.Anybodyrunningcodethatfullyvalidates
blocksmustupgradebeforetheactivationtimetobeabletoworkontheminermajority'slongest
chain.
SPVwalletsarenotaffectedandrequirenochangeorupdate.

Deployment
SWcompliantwiththisBIPcanbedeployedanytime.Assoonasa75%supermajorityisachieved
(samepercentageasproposedinBIP101),consensusisreachedandthechangesofthisprotocol
willactivateaftera23weekgraceperiod,leavingotherminerssufficienttimeforupgradingtothe
newprotocolversion.

Other Solutions Considered

BIP100(v0.8.1)byJeffGarzik,http://gtf.org/garzik/bitcoin/BIP100
blocksizechangeproposal.pdf

BIP101byGavinAndresen,https://github.com/bitcoin/bips/blob/master/bip0101.mediawiki

BIP102byJeffGarzik,https://github.com/bitcoin/bips/pull/173/files

BIP103(?)byPieterWuille,https://gist.github.com/sipa/c65665fc360ca7a176a6

BIP1xxDynamicallyControlledBitcoinBlockSizeMaxCapbyUpalChakraborty
https://github.com/UpalChakraborty/bips/blob/master/BIPDynamicMaxBlockSize.mediawiki

ElasticblockcapwithrolloverpenaltiesbyMeniRosenfeldhttps://bitcointalk.org/index.php?
topic=1078521.0

Further References:

BitcoinNetworkCapacityAnalysisPart4:SimulatingPracticalCapacity
https://tradeblock.com/blog/bitcoinnetworkcapacityanalysispart4simulatingpractical
capacity

Asummaryofblocksizehardforkproposals,
https://lists.linuxfoundation.org/pipermail/bitcoindev/2015July/009808.html

1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[5of5]