Version0.

1(2September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

AHybridMechanismforAdaptively
AdjustingBitcoin'sBlockSizeLimit
[BIP10X]
ShortOverview
[Version 0.1 - 2 September 2015]

Abstract
This BIP proposes replacing the fixed one megabyte block size limit with a dynamically controlled
block size limit that may increase or 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 voting intervals

Long-term change of the block size limit

Short term load peaks

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

More details with concrete implementation guidelines, formulas, illustrative figures, simulation
code, simulation results, and with a more detailed rationale, 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

PDF file at scribd.com (version 0.1 from 30 August):

https://www.scribd.com/doc/277054298/A-Hybrid-Mechanism-for-Adaptively-AdjustingBitcoin-s-Block-Size-Limit-BIP10X

PDF file for download with Proof of Existence (version 0.1 from 30 August):
https://www.dropbox.com/s/vlo0q5h0mxfb5np/ProofOfExistence_BIP10X_BIP10Y_v01_201
5-08-30_EnvelopeContainer.zip?dl=0

Motivation
Withincreasedadoption,transactionvolumeonBitcoinnetworkisboundtogrow.Iftheone
megabyteBlockSizeLimitisnotchangedtoaflexibleonewhichchangeswithchangingnetwork
demand,BitcoinadoptionwillhamperandBitcoin'sgrowthmayslowdown.Followinggraph
showsthechangeinaverageblocksizesinceinception:

https://blockchain.info/charts/avg-block-size?
timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&ad
dress=
1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[1of5]

Version0.1(2September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

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
hard-forks 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 the norm, based on market demands and technological evolutions. 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 security by
ruling out sudden swings of the BlockSizeLimit from the start.
So, no overarching control is given to miner votes. Actual block occupancy is taken into
consideration, and after all, fixed long-term (roughly one-to-two year) change rates of the
BlockSizeLimit are avoiding too arbitrary variations.
Finally, the motivation of this BIP is to also have means for elastic reaction to short-term
temporary demands for traffic increase on the Bitcoin network while avoiding mis-use.

Specification
This BIP proposes a combination of several features:

Part 0: Miner Voting for Initial BlockSizeLimit to Start with

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

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

Theprotocolcheckstheminervotesagainsttheactualblocksizeoccupancyduringthesamevoting
interval.Ifthediscrepancyistoolarge,theprotocoloverrulesthevotesbyforcingthemintoa
carefullydesignedtoleranceinterval(definedbytwofixedfactors)aroundtheaverageactualblock
size.

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

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

[2of5]

Version0.1(2September2015)

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

Inexceptionalcasesoftemporaryhighload,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,whichwouldreducefairnessandbringelementsofgambleintothe
votingprocess,whichisundesired.Threshold=50%ischosenbecausethisistheBlockSizeLimit
thatisnottoobigfor50%ofvotersandnottoosmallfor50%ofvoters,hencemostfair.80%
majorityforstretchingthelimitsoflongtermgrowth(ordecline)beyondthenormallimitsis
chosentokeepadooropenforfasterevolution,ifneeded,whilemakingabusedifficult.

1MichaS16UMKFgNjanKrtfD51HpBkqPAwD

[3of5]

Version0.1(2September2015)

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%delineratelimitischosenbecauseitopensupthegeneral
possibilitytodecreaseBlockSizeLimitforwhateverreason.However,timesoflowtrafficshouldnot
prematurelycauseatooquickdeclinethatmakesitdifficulttolatercomebacktotheoriginal
value,hencethedeclinerateislimitedmuchstricterthanthegrowthrate(factor2isachievedin
only8yearsinsteadof2years).The16%declineratefor80%minermajorityrealizesthesame
factor2speedupasforthegrowthratecase.
Thisisthestrongestconstraint,itpotentiallyoverrulesthepreviousminers'decisions,thereby
avoidingminerabuseandallowinglongtermplanningsecuritynosuddensurprisespossible,
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.1(2September2015)

byMichael_S(bitcointalk.org)

OpenPGPKeyID=0xCC7E7C99

solutiontoonlyhaveamodificationintheheader],becausethemaximumallowedsizeforablock
dependsoninformationcontainedincoinbasetransactionsfrompreviousblocks(whichmaynotbe
immediatelyknownifblockcontentsarebeingfetchedoutoforderina'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
(samevalueasproposedinBIP101),consensusisreachedandthechangesofthisprotocolwill
activateaftera23weekgraceperiodthatleavesotherminerssufficienttimetoupgradetothenew
protocolversion.

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]