A Hybrid Mechanism For Adaptively Adjusting Bitcoin's Block Size Limit (BIP10X)

Version0.
1(30August2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
AHybridMechanismforAdaptively
AdjustingBitcoin'sBlockSizeLimit
[BIP10X]
Abstract
ManyproposalshavebeenmadeforthefutureevolutionofBitcoin'sBlockSizeLimit(BSL).Some
suggestsimplyliftingthehardlimittoahighervaluebutkeepingitfixed[3](BIP102),whileothers
proposeahardcodedfixedgrowthrate[2,4](BIP101,BIP103).AgainothersproposeaBSL
adjustment(upordown)exclusivelybasedonminervoting[1](BIP100).Finally,certainproposals
favoranautoadaptation(upordown)basedontheactualsizeoftherecentblocks.
CurrentBitcoinprotocoldoesnotcontainanyofthesefeatures,inparticularitdoesnotcontainany
minervotingmechanism.Nevertheless,aminervotingaboutfutureBlockSizeLimitisdefacto
implicitlydoneatthatmomentwhenanalternativeBitcoinimplementationlikeBIP100orBIP101
[1,2]getsdeployed.Thismeans,aminervotingcanbeimposedanytime,evenifnotforeseenby
thecurrentBitcoinsoftware.
BIP100[1]proposesaminervotingmechanismfortheBlockSizeLimit(BSL)builtintotheBitcoin
protocol.Thisinstitutionalizesablocksizelimitvotingmechanismasanormalandevolutionary
processwithintherulesoftheBitcoinprotocol.Thiscanbeseenasanalternativetothenon
institutionalizeddefactovotingthattakesplacewhendeployingalternativeBitcoinfork
implementationscompetingforaminermajority.AninstitutionalizedvotingonBSLthatisbuiltin
totheprotocolitselfisastrongcounterincentivetodeployingotherhardforkstobeactivatedby
minervoting(ifthesehardforksareaboutblocksizelimit),becauseminerscouldequallywelljust
casttheirvotewithinthemechanismsofthecurrentprotocolitself.Thiswouldcalmdownfuture
discussionsabouthardforksinthecommunityandwouldallowrefocussingonotherimportant
issues,ofwhichtherearemany.
However,BIP100[1]isnotveryconcreteinalldetails(e.g.theexactdefinitionofthevote
majority)andhassomedisadvantagesbysolelyrelyingonminervotesandbyallowingexcessive
annualBSLchangeratesinbothdirections.Ithasbeencriticizedthatminerswouldhavetoomuch
unrestrictedpower.
ThisBIP10Xproposaltakesallideasofalltheaboveproposalsintoconsiderationandaddsnew
ideas,therebyprovidingaconcretenovelsolutionthattriestopromotetheadvantagesandto
eliminatethedrawbacksofeachindividualproposalseensofar.
ThispaperproposesthatBlockSizeLimit(BSL)ispredominantlydeterminedbyminervotes,
howeverrestrictedandpossiblyevenoverruledbyseveralconstraintsandaddons.Minervotingis
onlypossiblewithincertainlimits.Theselimitsaretheevolutionoftheblocksizelimititself(max.
annualchangerate)aswellastheevolutionoftheactualblocksize,suchthate.g.minerscannot
arbitrarilyvoteuptheBlockSizeLimit(BSL)whentheactualblocksizesdonotkeeppace.The
proposalalsoincorporatesaconditiontostretchthegrowthrateconstraintsabitfurtherifareally
hugeminermajorityisinfavorofthis.Moreover,amechanismisincorporatedtocopewith
temporaryhighTXload,toallowapossibilityforshorttermreactiontominimizeuserdis
satisfaction.
Thewholeproposalisconcrete,completeanddetailedonallalgorithm,functionandprotocol
specifications.Carefulselectionofparametersanddefaultconfigurationfilesettingshasbeen
carriedoutandarationaleisgivenforeachdecision.Simulationswereperformed(sourcecode
provided)toensureappropriatebehaviorinagreementwiththeintentionsofthedesign.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[1of37]
Version0.1(30August2015)
Version History
v0.1
30August2015
Firstversion
Themeasureofintelligenceistheabilitytochange.
AlbertEinstein
[2of37]
Acknowledgements
TheauthorexpressivelyacknowledgesallcontributionsthathavebeenmadeonBlockSizeLimit
evolution,beitintheformofBIPs,otherwriteups,orbypostsindifferentforums.
Allopenandpragmaticdiscussionshelpedtogetmoreandmoreinsights,leadingtothisproposal,
whichunderwentmanyiterationsbeforeitsfirstrelease.
ThisBIP10Xproposalwouldnothavebeenpossiblewithouttheearlierworkandthoughtsofother
communitymembersandcanbeseenasanaturalevolutioninthecommunity'sendeavortofind
thebestpossiblesolution.
ThegreatestacknowledgementgoestoeachindividualdeveloperwhocontributedtotheBitcoin
softwaresince2009.Withouttheirefforts,wewouldnotbeinthepositiontoholdthisdiscussion
today.
Foryouracknowledgement
Apersonwhonevermadeamistakenevertriedanythingnew.
AlbertEinstein
[3of37]
Contents
Terms, Abbreviations and Symbols......................................................................................................5
1 Overview of Main Characteristics of BIP10X..................................................................................7
1.1 Introduction Schedule................................................................................................................8
2 Detailed Specification........................................................................................................................9
2.1 Three Phases After BIP10X Deployment..................................................................................9
2.2 Details of the Three Phases........................................................................................................9
Activation Phase..........................................................................................................................9
Grace Period................................................................................................................................9
Operational Phase (Starting with Block M)..............................................................................10
2.3 Version Number Field of BIP10X............................................................................................12
Writing Version Number Field to Block Header.......................................................................12
Reading Version Number Field from Block Header.................................................................14
2.4 Overbooking of Blocks: Block Size > Nominal Block Size Limit..........................................15
Part 1: Update of Overbooked Blocks Ratio OBR....................................................................15
Part 2: Condition When Overbooking is Allowed....................................................................15
Part 3: Counter-Incentive against Overbooking by Burning TX Fees......................................15
Validation Condition of an Overbooked Block.........................................................................16
2.5 Re-Alignment of Long-Term Averaged Values........................................................................17
Re-Alignment of BSL_LongTermAvg......................................................................................17
Re-Alignment of Overbooked Blocks Ratio (OBR).................................................................18
3 New Parameters in Bitcoin.conf......................................................................................................19
4 Rationale..........................................................................................................................................20
5 Simulations......................................................................................................................................26
Appendix............................................................................................................................................31
A.1 Overview of BIP10X's Hardcoded Parameters and Design Choices......................................31
A.2 Comparison of Different Block Size Evolution Proposals.....................................................32
A.3 Simulation Source Code and Simulation Tool........................................................................34
How to Use FreeMat Tool.........................................................................................................34
The Source Code (BSL_change.m).......................................................................................35
References..........................................................................................................................................37
[4of37]
Terms, Abbreviations and Symbols

aABS
ABS
ActivationPhase
BSL
BSL_LongTermAvg
avg.ABSofthelast1008blocks,calculatedattheendofaBSLvotinginterval
ActualBlockSizeofablock
ThetimebeforeBIP10X's75%supermajorityisachieved,i.e.untilblockN1.
BlockSizeLimit
Thisisthelongtermexponentialaverage(62.5weekseff.windowlength)ofthe
BlockSizeLimitBSL_curr.Itgetsupdatedonceevery1008blocks(1week).
BSE
BlockSizeExponent:Anintegerk0inBSEformatrepresentsthenumber
2^(k/8v)andablocksize(limit)of2^(k/8)*1,000,000bytes,i.e.k=0..127
representssizesrangingfrom1MBto60.1GBinincrementsof9.05%.
BSEresolution
grid
Thisisthegridof128distinctnumbersthatBSL_currhastolieon.Dueto
thefactthatBSL_currisexpressedbyanexponentinBSEformat,itcanonly
assumevaluesonagivenlogarithmicBSEresolutiongrid,mappingtotheBSE
exponents0..127.Anytwosuccessivevaluesdifferbyafactor2^(1/8)1.0905.
BSL_curr
CurrentnominalBSLtheBSLapplicableforthecurrentblock.Itremains
unchangedfor1008blocks(=votinginterval).
BTC
bitcoins(currencyunit)
ceil(x)
=xroundeduptonearestfullinteger
Effective
Mathematicalexpressionforthelengthintimethatanexponentialaveraging
windowlength windowneedstoreachbackintimeuntiltheaveragingweighthasdecayed
to36.8%(=1/e)oftheweightatthepresenttime(seealsoforgettingfactor).
floor(x)
=xroundeddowntonearestfullinteger
Forgettingfactor Averagingparameterinrange[0..1)forexponentialtimeaveragingofany
kindofvaluethatchangeswithtime(oreventcount).Thegeneralequationis:
valueAvg(k)=forgettingFactor*valueAvg(k1)+(1forgettingFactor)*valueNew
AvalueofforgettingFactor=0meansthatnoaveragingisdoneatall.
GracePeriod
StartswithBIP10Xsupermajorityachievement(blockN)untiloneblockbefore
startingminingusingBIP10Xrules(i.e.untilblockM1).
M
Blockheightoffirstblockbeingminedacc.toBIP10Xrules,M=N+delta,
withdelta{2016..3023}.Mis504blocksawayfromthenearestdifficulty
adjustment.
MSB
Mostsignificantbit
N
BlockheightoftheblockthatachievesBIP10Xactivationcondition
OBR
OverbookedBlocksRatio[0.0..0.3]:Fractionofrecentoverbookedblocks,based
onlongtermexponentialaveragingwitheffectivewindowlengthof114days.It
getsupdatedonceeveryblock.
OperationalPhase Startswiththefirstblockminedacc.toBIP10xrules(blockM),withBSLvote
includedintheblockheader.
Overbookedblock Thisisablockwithsizegreaterthanthecurrentnominalblocksizelimit
BSL_curr.Itisbyafactorofupto2or4greaterthanBSL_curr.
Overbooking
Themethodofcreatingoverbookedblocks.
rBSE
RelativeBlockSizeExponentformatspecifiesanumberrelativetoBSL_curr.A
miner'svoteisspecifiedinrBSEformatasavaluerelativetoBSL_curr,keeping
theBSEresolutiongrid.
SW
Software
TPS
Transactionspersecond
TX
Bitcointransaction
[5of37]
vBSL_50
The50%ile(=median)voteoftheminers'votesfromthelastvotinginterval.It
isthemainvotethatusuallydeterminesthenewBSL.
vBSL_20i
The20%ilevoteofthelastvotinginterval.BydefinitionitisvBSL_50,butif
vBSL_20iindicatesaBSLincrease,itwillmeetlessstrictconstraintsforlong
termincreasethanvBSL_50.Hence,evenifsmallerthanvBSL_50beforethe
constraints,itcanbegreaterthanvBSL_50aftertheconstraints.Itcantherefore
speedupBSLgrowthifthereissubstantial(80%)minersupport.
vBSL_80d
The80%ilevoteofthelastvotinginterval.BydefinitionitisvBSL_50,butif
vBSL_80dindicatesaBSLdecrease,itwillmeetlessstrictconstraintsforlong
termdecreasethanvBSL_50.HenceBSLdeclinecanspeedupifthereis
substantial(80%)minersupport.
Anexpressionofaminer'spreferredBSL,indicatedintheheader'sversion
numberfieldofablock.Thevoteshaveagranularityof9.05%stepsacc.to
theBSEformat.
Vote
Votinginterval
Anintervalof1008blocks,fromblockM+n*1008toM+n*1008+1007,n0.
[6of37]
1 Overview of Main Characteristics of BIP10X

Formanyitemsofthisspecification,thedetailedrationaleisexplainedinseparatechapter4.Toease
reading,areferencelike[Rat1]pointstotherespectiveiteminthatchapter.
MinervotingmechanismsandmainBIP10Xcharacteristicsaresummarizedasfollows:
Activationwhenachievinga75%supermajority[Rat1]
Duringactivationphase,BIP101minersaretakenintoaccountinareasonableway
23weektransitionalgraceperiodtoallowminersupdatefromlegacyorBIP101toBIP10X.
Adjustmentintervalforblocksizelimit=1008blocks=1week=difficultyadjustment
interval,permanentlyoffsetby504blockstodifficultyadjustmentinterval.[Rat2]
AllvotinginfoandsomefurtherBIP10Xspecificinfoisintheblockheader,makinguseof
largelyunused32bitspaceintheversionnumberfield.[Rat3]
BlockSizeLimitrangeis1MBto61GB,withgranularityinstepincrementsof9.05%
[Rat3]
Aspecialblocksizevoteispossiblewhichsaysvotingforthenextblocksizelimittobe
equaltothecurrentblocksizelimit.
Blocksizelimitdecisionbasedonmedian(50%quantile)[Rat6]ofallvotestoavoid
manipulationbyaminerminorityineitherupordowndirection.
Minervotesdonothavetotalpoweroverblocksizelimitevolutiontheblocksizelimit
adjustmentisconstrainedby:
Actualblocksizeofpreviousweek(ifactualblocksizeistoofaroff,minervotesdon't
matter)
Longtermgrowthrateofblocksizelimitcannotbegreaterthan2xper2years(which
isthefixedrateofBIP101)or0.5xper8years.
Exceptincaseof>80%votingmajority:Thenthegrowthratelimitsarestretchedto
2xper1yearor0.5xper4years.
Theveryfirstblocksizelimitvoteisnotrestrictedbyaboveconstraints,butafreevote
onlyconstrainedbytheabsolutelimits[1MB;4MB].80%majority(i.e.20%quantile)
isusedforthisinitialvoting.[Rat6]
BlockoverbookingincaseoftemporaryhighTXload(upto4xnominalBlockSizeLimit),
butnotpermanently[Rat7].
Twoadditionalconfigurationparametersforbitcoin.confareintroduced.
[7of37]
Moreinformationontherulesforblocksizelimitevolution:
Uponanycircumstances,fromoneweektothenext,blocksizelimitcanneverinor
decreasebymorethanafactorof1.682.Inpractice,weeklychangeratewillbemuchlower
duetootherconstraints.[Rat5]
Uponanycircumstances,theabsolutelimitsfortheblocksizelimitare[1MB;60.1GB].
However,theprotocolhastakenprecautions(areservedbit)foraverysimpleincreaseof
max.blocksizelimitto3939TB,whichcorrespondsto1transactionpersecondperperson
foraworldpopulationof10Billionpeople.Thismakestheprotocolverylongtermfuture
safe.
Ifblocksaremoderatelyoccupiedonaverage,thenminersdecide(median=50%quantileof
1008blocks'1week'svotes)byhowmuchblocksizelimitwillbeincreasedordecreased,
whereasmax.longtermgrowthisstrictlylimitedto
+41%/8%p.a.(=factor2xin2resp.8years).
Onlyincaseofminersmajority>80%(of1008blocks'1week'svotes),longterm
growthratecanbedoubledtoamax/minof
+100%/16%p.a.(=factor2xin1resp.4years).
Ifactualblocksarefilledby>90%onaverage,blocksizelimitwillincreaselongtermby
+41%p.a.,evenif100%ofminersvoteinoppositedirection[Rat4].Ofcourse,avote
majorityof>80%inthesamedirectioncanfurtherincreasethisratetoavg.+100%p.a.
Ifactualblocksarefilledby<20%onaverage,blocksizelimitwilldecreaselongtermby
8%p.a.,evenif100%ofminersvoteinoppositedirection[Rat4].Ofcourse,avote
majorityof>80%inthesamedirectioncanfurtherdecreasethisratetoavg.16%p.a.
Theblocksizelimit(BSL)isanominalvaluethatmustusuallybeobeyed,i.e.theactual
blocksize(ABS)mustnotbeabovethatlimit.However,undercertaincircumstancesthe
actualblocksizeistemporarilyallowedtoexceedthecurrentnominalblocksizelimit
(BSL_curr)byuptoafactorof4[Rat7].Thispreventsthatatemporaryincreaseinnetwork
loadcausesabottleneckinTPScapacitybecauseofthelimitedblocksizelimitadjustment
speed.Toensurethatthisremainsanexception,onlyacertainpercentageofblocksare
allowedtoexceedthenominalblocksizelimitonthelongrun,andthereisafurther
counterincentiveagainstsuchoverbookingbythatminersareobligedtodestroy25%ofthe
excesstxfees(fordetailsseech.2.4).
1.1 Introduction Schedule

ItisproposedtoimplementandtestthisBIP10X,andthentodeployitswiftlytothenetwork.
Inthemeantime,ifthereshouldbeaneedforlargerblocksbeforethishasbeenaccomplished,itis
proposedtodeployahardforkwithasimplefixedincreaseofBlockSizeLimittoe.g.2MBacc.to
BIP102,inordertobuysometimeandavoidharmingtheBitcoinecosystem.
[8of37]
2 Detailed Specification
2.1 Three Phases After BIP10X Deployment
WhenBIP10Xsoftwareisdeployedbyaminer,itoperatesinoneoutof3phases:
ActivationPhase:Thefirstphase.HereBIP10Xminersobservetheminedblockstodetermine
ifasupermajorityfortheBIP10Xprotocolchangeisachieved.
GracePeriod:Oncetheactivationconditionismet,theirrevocabledecisionismadethat
blocksizelimitvotingacc.toBIP10Xwillstartatacertaintime(precisely:certainblock
height)whichliesabout23weeksinthefuture.Untilthen,theBIP10Xminersstillbehave
likelegacyminers.ThistransitionperiodiscalledtheGracePeriod.
OperationalPhase:Finally,atthegiventime,BIP10Xminersstartvoting,thisisthestartof
theOperationalPhase.1week(1008blocks)laterthefirstblocksizelimitadjustmentwill
takeplace.
Theoperationalphaseisdividedintotheinitialandthefinaloperationalphase:
InitialOperationalPhase(first1008blocks):MinersvotefortheinitialBSLthatthe
protocolshouldstartwith,within1and4MB.
FinalOperationalPhase:NormaloperationwithregularBSLadjustmentevery1008
blocks,basedonminervotesandvariousconstraints.
2.2 Details of the Three Phases

Activation Phase
1. Noearlieststartdateisspecified,neitherintermsofdate&time,norintermsofblock
height.Instead,activationphasestartsassoonastheBIP10Xminerstartsup.
2. BlocksminedbyBIP10Xclientsareidentifiedbyanewversionnumber0x2000000B.
3. Theactivationconditionismetif75%oftheprevious1008blocks(1week),i.e.756
blocks,arecountedasBIP10Xcompliant.Theconditionischeckedeverynewblock(sliding
window).[Rat1]
4. 50%oftheblocksminedbyBIP101clients(versionnumber0x20000007)arecountedas
BIP10Xminedblocks(roundeddowntofullinteger),whiletheremainingBIP101blocksare
countedaslegacyblocks.ThismeansthateverysecondBIP101blockhelpstotriggerthe
BIP10Xactivationcondition.Notethattheserulesimplythattheactivationconditioncannot
bemetunlessatleast50%oftheblocksareproperBIP10Xblocks.[Rat1]
5. Whentheactivationconditionismetwiththeappearanceofblock
N,thegraceperiodstarts
(seeFig.21below).
Grace Period
6. Thegraceperiodisbetween2016and3023blockslong,dependingonwhereblockNis
locatedonthe504blockgridthatisalignedwiththe2016difficultyadjustmentgrid,see
Fig.21below.
Duringthisgraceperiod,theBIP10Xminerstillbehaveslikealegacyminer,exceptthatit
sendstheversionnumber0x2000000B.
7. Thegraceperiodisoverwhenpropervotingstartsatblock
M.BlockMistheblockthat
fulfillstwoconditions:Firstitmustlieona1008blockgridwhichisoffsetby504blocksto
the2016blockdifficultyadjustmentgrid.Secondlyitsblockheightmustfulfillthecondition
[9of37]
2016MN3023,
whereblock
Nistheblockwhentheactivationconditionwasmet[Rat2].
BlockMisthefirstblockoftheoperationalphase.
2016 blocks difficulty

adjustment interval
504 blocks
ca. 1 week
504 blocks time grid

BIP10X activation
condition met any
time here
Start voting
Between 2016 and 3023 blocks grace period

(2-3 weeks)
Activation
Phase
Grace Period
BIP10X initial
BSL setting
Special voting
for initial BSL
(blocks
M .. M+1007)
First BIP10X
BSL adjustment
1008 blocks
BSL
voting
interval
Next BIP10X
BSL adjustment
1008 blocks
BSL
voting
interval
Operational Phase
Block N
Block M+1008: The first block that can be >1 MB
Block M
Block M+n*1008, n>1: First block with new BSL after adjustment
Fig.21: HowBIP10Xbecomesactivatedandoperational.
Note:HereblockMoccurs504blocksbeforeadifficultyadjustment.Acc.to
BIP10Xitcouldequallywelloccur504blocksafteradifficultyadjustment
(dependsonwhenactivationconditions[=blockN]isachieved).
Operational Phase (Starting with Block M)

Votingprocedure:
8. The32bitversionnumberintheblockheadernowhastheform0x20VTSS0B.Thisfield
alwayscontainstheminer'sBSLvoteandtheoverbookingindication.AlsothecurrentBSL
(BSL_curr)isusuallyincluded,andsometimestheOverbookedBlocksRatio(OBR)orthe
longtermaverageofBSL_curr(BSL_LongTermAvg)isincluded.
Thedetailsofhowthesedataareencodedtothisversionnumberheaderfieldisspecifiedin
chapter2.3VersionNumberFieldofBIP10X.
9. NotethateveryBIP10Xblockisavote.Notvotingisnotpossible.Votingstrategydepends
onthesettingofparameterblocksizelimitvoteinbitcoin.conf.Itispossibletosetup
theminersuchthatitalwaysvotesforthecurrentBSLtobekept,otthatitvotesforafixed
BSLvalue,orthatitvotesforavaluethatisbyaspecifiedfactorgreaterthantheactual
blocksizeofthecurrent1008blocklongvotinginterval.
10. Legacyminers(aswellasBIP101minersthatbehavelikelegacyminers)canstillparticipate
[10of37]
andcreatevalidblocksuntilblockM+1007.Afterthat,theirblockswillnotbeacceptedby
BIP10Xminersanymore.
VoteevaluationandBlockSizeLimitadjustment.Thefollowingtakesplaceexactlyonceevery1008
blocks,i.e.alwaysafterblockM+n*10081appears,n:
11. First,herearethespecialrulesfornonBIP10Xblocks(thosewithversiondifferentfrom
0x20VTSS0B)duringtheinitialoperationalphaseuntilblockM+1007(seeFig.21):
BlockscontainingBIP101versionnumber(0x20000007)arecountedlikeBIP10Xblocks
thatarevotingfor4MB.Thereasonforthisisthatthevoteinthisinitialphaseshould
notbebiasedtoomuchtowardssmallblocksizes,justbecausesomeBIP101minershave
missedswitchingtoBIP10Xintime.
BlockswithaversionnumberotherthenBIP101orBIP10X,i.e.socalledlegacyblocks,
areignoredforBSLvoting,suchthat100%ofvotesafterthe1008blockinitialvoting
intervalcorrespondtolessthan1008votes.The80%threshold(20%quantile)isthen
accordinglyreferringtothissmallerabsolutenumberofvotes.
12. Whenreadinganotherminer'sblock,onlythetwocenterbytesoftheversionnumber(i.e.
0xVTSS)areofrelevance,sincetheycontainBIP10Xspecificinfoslikethevote.Theother
twobytesareofnorelevancefortheSW'sbehavior(exceptthespecialtreatmentsinthe
initialoperationalphaseacc.topreviousitem).
13. Votesareevaluatedevery1008blocks(1week),alwaysafterablockM+n*10081has
beenmined,withn.[Rat2]
14. Basedonthe1008votes,threequantilesarecalculatedandassignedto64bitdouble
precisionvariables(52bitmantissa),respectively:
vBSL_50:The50%(=floor(0.50*1008)=504)ofsmallestBSLvotesarediscarded,andthe
smallestoftheremainingvotesisassignedtovBSL_50.Thisisthemedianor50%quantileof
all1008validBSLvotes.
vBSL_20i:The20%(=floor(0.20*H)=201)ofsmallestBSLvotesarediscarded,andthe
smallestoftheremainingvotesisassignedtovBSL_20i(20%quantile).
vBSL_80d:The80%(=floor(0.80*H)=806)ofsmallestBSLvotesarediscarded,andthe
smallestoftheremainingvotesisassignedtovBSL_80d(80%quantile).
Note:ThevaluesvBSL_50,vBSL_20iandvBSL_80darealreadylyingontheBSEresolution
grid(comparech.2.3,formatspecificationfor0xSS).
15. Finally,theupdateofBSL_currwillbecalculatedbysuccessivelyapplyingcertainconstraints
(min/maxfunctions)toit.ThenthefinalnominalblocksizelimitBSL_currapplicablefor
thenext1008blocks(M+n*1008toM+(n+1)*10081)willbeknown.
Theconstraintsareappliedinthefollowingorder(i.e.laterconstraintsinthislistmay
overruleearlierones):
(C0)ThisconstraintisONLYcalculatedonce,namelyexactlyafterblockM+1007has
beenmined,i.e.attheendoftheinitialoperationalphase.Thisconstraintsets
BSL_curr=min(BSL_20i,4MB).
TheninitializethelongtermaveragedBSLasfollows:
BSL_LongTermAvg=BSL_curr.
Thefollowing2constraints,(C1)and(C2),aswellastheremainingsteps(F)and(L),
areskipped,butonlyforthissingletime!Forallthefuture,(C0)isneverexecuted
againandinsteadsteps(C1),(C2),(F)and(L)areexecutedinsequence.
(C1)ThevariousquantilesofBSLvotewillbeconstrainedbytheactualblocksizesof
theprevious1008blocks.Forthis,calculatetheaverageActualBlockSize,aABS,ofthe
last1008blocks.Thenapplymin/maxlimitssuchthattheconstrainedvalueliesinthe
interval
[39704/32768*aABS;150244/32768*aABS][1.21*aABS;4.59*aABS]:
[11of37]
ConstrainingvBSL_50:
ForcevBSL_50intotheinterval[39704/32768*aABS;150244/32768*aABS]while
keepingitontheBSEresolutiongrid.
ConstrainingvBSL_20i:
IfvBSL_20iBSL_curr,then
forcevBSL_20iintotheinterval[39704/32768*aABS;150244/32768*aABS]
whilekeepingitontheBSEresolutiongrid.
ConstrainingvBSL_80d:
IfvBSL_80dBSL_curr,then
forcevBSL_80dintotheinterval[39704/32768*aABS;150244/32768*aABS]
whilekeepingitontheBSEresolutiongrid.
(C2)ThelongtermchangerateofBSL_currislimitedto+41%/8%p.a.under
normalvotingconditionsandto+100%/16%p.a.forextremevotingconditions
withmorethan80%consensus:
IfvBSL_50>189/128*BSL_LongTermAvg,thenreducevBSL_50ontheBSE
resolutiongriduntilitbecomes189/128*BSL_LongTermAvg.
EsleifvBSL_50<110/128*BSL_LongTermAvg,thenincreasevBSL_50ontheBSE
IfvBSL_20i>247/128*BSL_LongTermAvg,thenreducevBSL_20iontheBSE
IfvBSL_80d<98/128*BSL_LongTermAvg,thenincreasevBSL_80dontheBSE
(F)Finally,calculatethenewBSLasfollows:
IfvBSL_20i>BSL_curr,thenBSL_curr=max(vBSL_20i,vBSL_50)
ElseifvBSL_80d<BSL_curr,thenBSL_curr=min(vBSL_80d,vBSL_50)
ElseBSL_curr=vBSL_50
(L)Laststep:NowthatthenewblocksizelimitBSL_currisfinallyknown,thelongterm
averagevalueBSL_LongTermAvggetsupdatedasfollows:
BSL_LongTermAvg=32244/32768*BSL_LongTermAvg+524/32768*BSL_curr.
(all64bitdoubleprecisiontypes)
(Note:32244/327680.984;524/327680.016)
Note:Thisfilteringwithforgettingfactor0.984realizesanexponentialaveraging
windowwithaneffectivelengthof62.5weeks.
Note:BSL_LongTermAvgisavalueinunitsofbyteswithfullaccuracy.
2.3 Version Number Field of BIP10X

Writing Version Number Field to Block Header
The32bitversionnumberfieldofblocksminedwithBIP10Xisconstructedasfollows:
(meaningofletters:S=blockSizelimit,V=Vote,T=exTension)
Bytenumber=3210
0x20VTSS0B=00100000vvvvttttssssssss00001011
=0x200xVT0xSS0x0B
[12of37]
Thebitsaredefinedsomewhatdifferentlyforthedifferentphases(compareFig.21):
(1)ActivationPhaseandGracePeriod,forallblocksM1:
0xVT =0x00
0xSS =0x00
(2)InitialOperationalPhase,initialvotinginterval,forallblocksMuptoM+1007:
0xVT =TheinitialvoteinBSEformat,i.e.0xVT=0..16correspondingtovote
=1MB..4MB=2^(0xVT/8)*1MB.
0xSS =0x00
(3)FinalOperationalPhase,forallblocksM+1008:
0xV= BSLvoteinrBSEformatrelativetoBSL_curr,and
overbookingindication,asspecifiedbelow.
(3a)Allblocksexcept(3b)and(3c):
0xT=0x0
0xSS=BSL_currinBSEformat(value0..1271MB..60.1GB),seebelow,i.e.theblock
sizelimitapplicabletothisblock.
(3b)2ndblockofavotinginterval,i.e.blockheightM+n*1008+1,n):
0xTSS=uint12carryingBSL_LongTermAvgasbinaryfractionalnumber,seebelowforthe
formatandseech.2.3forthemeaningofBSL_LongTermAvg.
(3c)Thirdlastblockofavotinginterval,i.e.blockheight=M+n*1008+1005,n):
0xTSS=uint12carryingthevalueofOBRasbinaryfractionalnumber,seebelowforthe
formatandseech.2.4forthemeaningofOBR.
FormatSpecification:
(3a) Formatof0xSS(currentBSL,BSL_curr):
0xSSisuint8,usedrangeis{0..127}(MSB=0[reservedforfutureuse]).
Theblocksizeexponent(BSE)formatusedforspecifyingBSL_currin0xSShasthe
followingformat[Rat3]:
BSL_curr=floor(2^(0xSS/8)*1,000,000)bytes
Examples:
0xSS=0BSL_curr=1,000,000bytes=1MB
0xSS=1BSL_curr=1,090,507bytes
0xSS=25BSL_curr=8,724,061bytes
...
0xSS=127BSL_curr=60,096,776,975bytesGB
Rangeof0xSS:
0..127: Regularvalues.
128..255: Reservedforfutureuse(wouldsupportblocksizesupto3939TB).
Notethatthesevalueshaveagranularityofupincrementsof9.05%(ordownincrements
of8.30%).BSL_currisoneoutofasetof128distinctnumbersthatisreferredtoasthe
BSEresolutiongrid.
[13of37]
(3) Formatof0xV(theminer'sBSLvoteandoverbookingindication):
0xVisinterpretedassignedint4,i.e.range{8..+7}.
TheBSLvoteisexpressedrelativetoBSL_curr(rBSEformat).Thevoteliesonthesame
BSEresolutiongridasBSL_curr[Rat3]:
0xV
{
6..+6}:Overbookingindication=OFF=0(i.e.thisblock'ssizeisBSL_curr)
VoteforBSL=floor(2^((0xSS+0xV)/8)*1,000,000)bytes
Examples:
0xV=1010=6voteforBSLthatisbyfactor2^(6/8)1.6818belowcurrentBSL
...
0xV=0000=0voteforBSLthatissameascurrentBSL
0xV=0001=1voteforBSLthatisbyfactor2^(1/8)1.0905abovecurrentBSL
...
0xV
{
8,7,+7}:Overbookingindication=ON=1(i.e.thisblock'ssizeis>BSL_curr)
Specialmapping(lookuptable)asfollows:
0xV=1000=8voteforBSLthatissameascurrentBSL
BitcoinSWshallsetthevotetothehighestpossiblevaluethatissmallerorequalto
whatisgivenbyblocksizelimitvote(configurationparameterinbitcoin.conf).
Note:See[Rat5]forwhythelimitedvotingrange[BSL_curr/1.6818toBSL_curr*1.6818]is
notactuallyarestriction.
(3b) Formatof0xTSS(=BSL_LongTermAvg,seech.2.3fordetails):
0xTSSisuint12,i.e.range{0..+4095}.
BSL_LongTermAvg=0xTSS/2^11*BSL_curr,range=[0.0..1.99951172]*BSL_curr
(3c) Formatof0xTSS(=OverbookedBlocksRatioOBR,seech.2.4fordetails):
0xTSSisuint12,i.e.range{0..+4095}.
OBR=0xTSS/8192,range[0.0..0.49987793]
Reading Version Number Field from Block Header

[afterBIP10Xactivation,blockheightM]
Bytes0and3arecheckedtoseeifthisisaBIP10Xblock.
Afterthefirstblockwithsize>1MBhasoccurred,legacyminers(incl.BIP101miners)canno
longermineonthischain,socheckingbytes0and3becomessuperfluous.Itisproposedthatonly
bytes1and2arecheckedforblockvalidationfromthatpointonwards,whilebytes0and3are
ignored.Inparticular,thereshallbenocheckofversionnumberinbyte0anymore.
Thisallowsfutureforkstoreusebyte0fortriggeringafuturehardforkactivationuponthe
conditionthatbyte00x0B=00001011.
[14of37]
2.4 Overbooking of Blocks: Block Size > Nominal Block Size Limit
Thenominalblocksizelimit,BSL_curr,isbasicallycalculatedfromweeklyminervotes,constrained
byarangearoundtheactualblocksizeandbyBSL_LongTermAvg,whichisaroughly1yearaverage
(exponentialaveragingwindow)ofBSL_curr.Thisprovidesastableevolutionpathfortheblock
sizelimitBSL_curr.
Asthenamesays,blocksizelimitactuallymeansthatablockshouldnotbegreaterthanthat
limit.
However,therecanbetimesatwhichanunforeseeableloadoftransactionstemporarilyhitsthe
Bitcoinnetwork.Inthiscase,itshallbepossibletoexceedthelimitgivenbyBSL_currtoacertain
extend.Thisiswhattheblocksizeoverbookingfunctionisallabout:
ItshallbepossibletocreateblocksinexcessofBSL_curr,ifthefollowinglimitsarekept:
Theblocksizeshallabsolutelyneverbegreaterthan4*BSL_curr
Theoccurrenceofoverbookedblocks2*BSL_currshouldnotexceedagiventhreshold
Theoccurrenceofoverbookedblocks>2*BSL_currshouldnotexceedanother,stricter,
threshold
Theserequirementsareimplementedbythefollowingalgorithm:
ThisfeatureisdisabledbeforeblockM+1008andgetsenabledwithblockM+1008,i.e.withthe
startofthefinaloperationalphase.
Part 1: Update of Overbooked Blocks Ratio OBR
InitializationbeforeminingofblockM+1008:SetOverbookedBlocksRatioOBR=0.0
IfNewBlockarrives:Checkiftheblock'sOverbookingIndication(=0(no)or1(yes))isset.
Foravalidblockitmustbeset=1ifblocksize>BSL_currandmustotherwisebeset=0.
UpdatethelongtermmetricOBRfortheratioofoverbookedblocks:
OBR=16383/16384*OBR+(1/16384)*OverbookingIndication(NewBlock)
Part 2: Condition When Overbooking is Allowed

IfOBR<0.10thenitisallowedtocreateablockwithsizeupto4*BSL_curr
ElseifOBR<0.30thenitisallowedtocreateablockwithsizeupto2*BSL_curr
Whatthismeansinparticularisexemplifiedintherationalechapter4insection[Rat7].
Part 3: Counter-Incentive against Overbooking by Burning TX Fees

ThecreationofblocksexceedingthenominalBSL(BSL_curr)isfurtherdiscouragedbyimposinga
penalty:Anoverbookedblockmustdestroy25%oftheTXfeesthatareattributedtotransactions
exceedingthenominalBSL,bysendingthemtotheunspendableaddress
1BitcoinEaterAddressDontSendf59kuE(oranotherequivalentaddresst.b.d.)
Moreprecisely,thefractionoftotalTXfeestobedestroyedisgivenbythefactor
factor=max(0;0.25*(ABSBSL_curr)/ABS),
whereABSistheactualblocksizeofthatblock.
Theamountofsatoshistobedestroysis=ceil(total_tx_fees*factor).
ThismeansthatminerswillonlycreateblocksgreaterthanthecurrentnominalBSLiftheyreally
seeanoverallbenefit(e.g.usersatisfactionbitcoinpriceminingprofits).
[15of37]
Validation Condition of an Overbooked Block

LetHdenotetheheightofablock.
LetOBR(H)denotetheOBRascalculatedfromblocksuptoandincludingblockH.
LetABS(H+1)denotetheactualblocksizeofblockH+1.
LetBSL_curr(H+1)denotetheBSLapplicabletoblockH+1.
Rule:ForablockH+1tobevalid,bothconditionsmustbetrue:
(OBR(H)<0.1andABS(H+1)4*BSL_curr(H+1))OR
(OBR(H)<0.3andABS(H+1)2*BSL_curr(H+1))
TXfeesdestroyedtotal_tx_fees*max(0;0.25*(ABS(H+1)BSL_curr(H+1))/ABS(H+1))
Note:Inthisequation,OBRisthevaluecalculatedBEFOREtheblockinquestionwascreated.
Thisruleistofacilitateimplementation:
Anodehasreceivedblocks1toHandcalculatesOBR(H)fromthis.
Ifthenodeisaminer,itshallmakeitsdecisionaboutoverbookingblockH+1independenceof
thisvalueOBR(H).
Ifthenodeisavalidationnode,itshallvalidateblockH+1basedonblocksizeofblockH+1
andOBRascalculateduptoblockH.
[16of37]
2.5 Re-Alignment of Long-Term Averaged Values

TherearetwopointsinBIP10XspecificationwhereLongTermAveragingtakesplace:
(double)BSL_LongTermAvg
(double)OBR(theOverbookedBlocksRatio)
Thesetwovariablesarelongtermaveragesfromanexponentialwindowwithinfinitememory.This
bearsarisk:SinceCPUimplementationsofdoubleprecisionarithmeticmightdifferslightly(notto
mentionCPUbugslikethefamousPentiumFDIVBugfrom1994),thismaycausethelongterm
averagedvaluetodivergeondifferentcomputersintheBitcoinnetwork,andthismayeventually
causeanunexpectedforkoftheblockchain.Itwouldbeunexpected,becausetheinternalstate(in
thesenseoftheexactvalueofthelongtermaveragedvalue)wouldnotbeknownbytheother
nodes.
Hence,itisconsiderednecessary,torealignthesevaluesregularlyamongstallnetworknodes,
suchthatallnodesperiodicallystartoverfromexactlythesamevalue(orstate).
BIP10Xspecifiesaperiodicrealignmentevery1008blocks,here'showthisshallhappen.
Re-Alignment of BSL_LongTermAvg
Accordingtoch.2.3,thelongtermaveragedBSL,BSL_LongTermAvg,iswrittentotheblockheader
onceevery1008blocksinblockM+n*1008+1,n1.Bythis,theminerdoingthistaskiscarrying
outarealignmentasfollows:
Calculationoftheminer:
Calculate
(uint12)tmp=floor(2^11*(double)BSL_LongTermAvg/(double)BSL_curr)
Note:Theratioofthetwo(double)valuesissurelybetween0.76and1.93,hencetmpis
guaranteedtonotsufferanyoverflow).
Write(uint12)tmptothebits0xTSSofthenewblockM+n*1008+1,asofch.2.3.
Behaviorofothernodes:(aftervalidation(below)isok)
Othernodesread(uint12)tmpfromblockheaderbits0xTSSofblockM+n*1008+1andcalculate
(double)BSL_LongTermAvg=(double)((uint12)tmp/2^11*(double)BSL_curr)
andusethisvalueBSL_LongTermAvgfromnowon,overwritingtheirowninternalandslightly
differentvalueBSL_LongTermAvg.
Validation:
ThevalidatingnodereceivingblockM+n*1008+1containingtmp==0xTSScheckswhichvaluefor
(uint12)tmphewouldhavecalculated.
Ifthevaluedeviatesfromthereceivedvaluebynomorethan+/1,theblockisaccepted(the
reasonforadifferenceof+/1couldbedifferentCPUHWimplementationswithroundingeffects).
Otherwiseitisrejected(adifferenceofmorethan+/1cannotbeexplainedbydifferentrounding
effects).
[17of37]
Re-Alignment of Overbooked Blocks Ratio (OBR)

Accordingtoch.2.3,theOverbookedBlocksRatio,OBR,iswrittentotheblockheaderonceevery
1008blocksinblockM+n*1008+1005,n1.Theminerthatisdoingthistaskiscarryingoutare
alignmentasfollows:
Calculationoftheminer:
Calculate
(uint12)tmp=floor((double)OBR*8192),
whereOBRisthevalueafterblockM+n*1008+1004wasfullyprocessed,i.e.
OBR=OBR(H),withH=M+n*1008+1004.
Write(uint12)tmptothebits0xTSSofthenewblockM+n*1008+1005,asofch.2.3.
(!)Note:ThedecisionwhetherornottooverbookthisblockH+1=M+n*1008+1005ismade
basedonOBR(H)afteraboverealignmentprocedure!
Behaviorofothernodes:(aftervalidation(below)isok)
Othernodesread(uint12)tmpfromblockheaderbits0xTSSofblockM+n*1008+1005and
calculate
(double)OBR=(double)((uint12)tmp/8192)
andusethisnewvalueOBRfromnowon,overwritingtheirowninternalandslightlydifferentvalue
OBR.NotethatthishappensbeforetheOverbookingIndicatorofblockM+n*10081005gets
checked.
Validation:
ThevalidatingnodereceivingblockH+1=M+n*1008+1005containingtmp==0xTSSchecks
whichvaluefor(uint12)tmphewouldhavecalculated.
Ifthevaluedeviatesfromthereceivedvaluebynomorethan+/1,theblockisaccepted(the
reasonforadifferenceof+/1couldbedifferentCPUHWimplementationswithroundingeffects).
Otherwiseitisrejected(adifferenceofmorethan+/1cannotbeexplainedbydifferentrounding
effects).
[18of37]
3 New Parameters in Bitcoin.conf

Note:Forrationaleofdefaultparameterchoicereferto[Rat8].
#Miner'sBlockSizeLimitvote(BIP10X):
#
#Specifytheblocksizelimit(BSL)asaspecialparameter:
#blocksizelimitvote=0>keepcurrentBlockSizeLimitunchanged
#
#Specifytheblocksizelimit(BSL)innumberofbytes,possiblevaluese.g.:
#blocksizelimitvote=1000000>means1MBvote(smallestpossiblevalue)
#=8000000>means8MBvote
#=61000000000>means61GBvote
#
#Specifytheblocksizelimit(BSL)asmultiplesofaverage*actual*blocksizeoflast1008bocks:
#blocksizelimitvote=1.2a>1.2xaverageactualblocksizeoflast1008bocks
#blocksizelimitvote=1.7a>1.7xaverageactualblocksizeoflast1008bocksDEFAULT!
#
#Generalremark:Actualvotewillbe<=blocksizelimitvote(upto8.3%smaller)becauseofthe
#protocol'sgranularitygridofpossiblevotingvalues.
blocksizelimitvote=1.7a
#Overbookingstrategyoftheminer(BIP10X):
#Tendencyofminertocreateblocksgreaterthancurrentnominalblocksizelimit(upto4x).
#blockoverbookingtendency=1.0>neverdoanyoverbooking
#=1.5>lowtendencyforoverbooking,nevermorethan1.5xnominalBSL
#=2.0>intermediatetendency,nevermorethanfactor2.0DEFAULT!
#=3.0>intermediatetendencyforoverbooking,nevermorethan3.0x
#=3.5>hightendencyforoverbooking,nevermorethan3.5xnominalBSL
#=4.0>fillblockstothemax.fromthemempool,upto4xnominalBSL.
blockoverbookingtendency=2.0
[19of37]
4 Rationale
[Rat1]
Q.: DuringtheBIP10Xactivationphase,whyis75%theactivationlimit,andwhyareBIP101blocks
countedby50%asiftheywereminedbyBIP10Xminers?
A.: MinersofBIP101blocksarevotingforablocksizeincreaseschedule,similarlytoBIP10X
miners.ThedifferenceisthattheblocksizeincreasescheduleofBIP10Xislessaggressivethan
thatofBIP101,becauseBIP10X'sgrowthratemaxlimitsaresettobeequaltothefixedgrowth
rateofBIP101(excludingBIP10X's80%minermajorityboostedgrowth,whichisonlymeant
tobeasanemergencyexitifdemandandtechnologyincreasesfasterthanexpected).Also,the
initialblocksizeof8MBisatleastbyafactorof2greaterthanthatofBIP10X.
HenceitwouldbenegligenttofullyignorethevotesofBIP101blocksfortheBIP10Xproposal,
becauseincaseofastalematebetweenBIP101andBIP10X(nonereaching75%ontheirown),
BIP10Xcanserveasasmallestcommondenominatorthatisstillbetterthannogrowthatall
fromaBIP101supporter'sviewpoint.Ontheotherhand,aBIP10Xminerisunlikelytoswitchto
themoreaggressiveandpredeterminedfixedBIP101growthschedule.
Itisassumedthatatleast50%oftheBIP101minerswillbewillingtoswitchovertoBIP10X
miningifthesupermajorityofBIP10Xisachieved.
InthiscontextitisimportanttonotethatiftheBIP10X's75%supermajorityconditionis
achieved,itisguaranteedthatthenumberofBIP10Xblocksisatleast50%,withequal50%
onlybeingpossibleiftherearenolegacyblocksatall!
BelowisalistofexamplesofwhatsituationswouldtriggerBIP10X75%supermajority
achievementconditionwiththecornercasesincluded:
NbofBIP10XBlocksNbofBIP101BlocksNbofLegacyBlocksBIP10XPercentage
504(50.0%)504(50.0%)0(0.0%)504+252=756=75.0%of1008
505(50.1%)503(49.9%)0(0.0%)505+251=756=75.0%of1008
506(50.2%)501(49.7%)1(0.1%)506+250=756=75.0%of1008
507(50.3%)499(49.5%)2(0.2%)507+249=756=75.0%of1008
...
632(62.7%)248(24.6%)128(12.5%)632+124=756=75.0%of1008
...
756(75.0%)0(0.0%)252(0.0%)756+0=756=75.0%of1008
TheoperatorsoftheBIP101minershave23weekstimetoswitchovertoBIP10X,whichshould
befullysufficient.
[Rat2]
Q.: Whyare1008blockintervalschosenfortheBlockSizeLimit(BSL)adjustment,andwhyisthere
this504blockoffsettothedifficultyadjustmentblock?
A.: First,1008blockscorrespondstoexactlyoneweek(assumingblocktime=10min),whichisa
gooddesignvaluesinceitislongenoughtoaverageoutperiodicoscillationsintrafficpatterns
thatarelikelytooccurduetoweekdaysandweekends.Probablythisisalsothereasonwhy
Satoshichose2016blocks(2weeks)forthedifficultyadjustment.Ontheotherhand,1weekis
shortenoughtoreactwithsufficientlyfinegranularitytochangesintrafficvolumes.
Secondly,the1008intervalisexactlyhalfofthe2016intervalfordifficultyadjustments.Since
BIP10Xoffsetsthesetwotimegridsagainsteachother,thereisalwaysaroughly3.5day(504
blocks)gapbetweenadifficultyadjustmentandaBSLadjustment.Inparticular,theseevents
willneverconcurinthesameblock.Alsonotethatsomespecialcontentsarewrittentothe
blockheader3blocksbeforeor1blockafteraBSLadjustment.Bykeepingafixed504block
offsetbetweenBSLanddifficultyadjustment,weavoidsanypotentialpeaksintermsofCPU
[20of37]
loadorspecialconditionsthattheSWmayrunintowhendifferentspecialcasesofdifficulty
adjustmentandBSLadjustmentcoincide,therebyreducingthenumberofSWscenariostobe
tested,anddecreasingthelikelihoodofanunexpectedbugoccurringinrealoperationlateron.
Whilethismayseemovercautious,atleastitdoesnotharmtohavethis504blocksoffset.
[Rat3]
Q.: Whyisthevote(andothernewinformationofBIP10X)puttotheblockheader(andthere
insidetheversionnumberfield)?
A.: Itisbelievedthatthecurrent32bitversionnumberismuchmorethanwhatwilleverbe
neededforversionnumberpurposes.Theversionnumberistypicallyonlyneededtoensure
controlledtransitionswhenintroducingforksoftheBitcoinsoftware.Oncetheforkhas
completed,theoldversionnumberisnomoreused.Inprinciple,forfutureforks,onceversion
number255isreached,thenextforkcanbedeployedwithversionnumber0,thatonefollowed
by1,2,3,etc.,i.e.amodulo256cyclicversionnumberingwouldbefullysufficient(andeven
those8bitsaremuchmorethanwhatisneeded).
Thereforethetwomiddlebytesoftheversionnumbercanbeusedforotherpurposes.BIP10X
usesthemforcarryingtheBSLvotinginformationandotherBIP10Xspecificinformation,
withoutharmingBitcoinfunctionalityelsewhereforthenearorfarfuture.
TheideatoincludetheBSLvoteintotheblockheader(heretheversionnumberfield)wasalso
inspiredbyGavinAndresen'scommentinhisBIP101proposal,whencommentingonJeff
Garzik'sBIP100'sproposalwhichincludesthevoteinthecoinbasescriptSig:
It[thecoinbasescriptSigthing]ismorecomplextoimplement,becausethemaximumallowedsize
forablockdependsoninformationcontainedincoinbasetransactionsfrompreviousblocks(which
maynotbeimmediatelyknownifblockcontentsarebeingfetchedoutoforderina'headersfirst'
mode)
WithBIP10X'sapproachtoincludethevote(andothernewinfos)intheheader'sversion
numberfield,thisdisadvantageisavoided.
[Rat3b]
Q.: Whyistheversionnumberchosentobe0x20VTSS0B,andwhyisanexponential(BSE/
rBSE)ratherthanlinearformatusedfortheblocksizelimitvote?
A.: Theleastsignificantbyteischosenas0x0B=00001011forbestcompatibilitywithlegacy
versionnumbers.WhileBIP101setsbitnumber3(yielding0x7),BIP10Xsetsbitnumber4
(yielding0xB).The0x20ofthemostsignificantbyteistakenfromBIP101.
Thetwomiddlebytes(0xVTSS),whichwereformerlyunusedintheBitcoinprotocol,now
containthecurrentBSL,theBSLvoteandotherinformationneededbyBIP10X.Itturnsoutthat
thesefewbitsarefullysufficientandfuturesafeforthistask,becauseblocksizesfrom1MBto
60GB(andbyusingasparebityetreservedinBIP10X,evenupto3939TB)aresupported.
Althoughthissignalingrangeishuge,thestepincrementsareasfineas9.05%forthe
completerangeofblocksizevalues.Thismeanswehaveconstantstepincrementson
logarithmicratherthanlinearscale.Thisismuchbettersuited,becauseaconstantlinearstep
incrementofe.g.1MBmightbeconsideredtoocoarseintheyear2015butmuchtoofinethan
whatisnecessaryatafuturepointintimewhenblocksaree.g.100MBinsize.Sincetheblock
sizeexponentformatofBIP10Xisdefinedforpowersof2,implementationiseasyandfreeof
roundingartifactsonabinarydigitalprocessor.
Hence,theexponential(BSE)formatensuresoptimumgranularityforthecompleterangeof
blocksizeswhileatthesametimereducingthenumberofsignalingbitstoaminimum.
[Rat4]
Q.: Whyistheconstraint(C1)settobesuchthattheBlockSizeLimitshouldbeintheinterval
[1.21;4.585]*average_Actual_Block_Size?
[21of37]
Doesn'tthismeanthattheBSLwillincreaseevenwhenthenetworkisactuallyunderloaded?
Forexample,ifaverageactualblocksizeis9MBandcurrentBSL_curris10MB,thisconstraint
willimposeanincreaseofBSLfrom10MBtoca.1.2*9=10.8MB,eventhoughthecurrent
blocksizelimitissufficient,since10MBcanwellaccommodatethe9MBtrafficload.Sodoesn't
thisincreasetheBSLunnecessarily?
A. No.Withreferenceto[5]wesee:Blocksarenotfilledevenlyinreality,duetotherandomness
oftrafficprocesses,andalsoduetodifferentminerstrategies.Instead,theblockoccupancy
variessubstantially.Someblocksarefull,othersarequiteempty.Theanalysisin[5]showsthat
thenetworkalreadystartstoexhibitnoticeablesymptomsofcongestionwhentheblocksareon
average75%full(2.3TPSvs.max.of3.0TPSintheexampleof[5]).Inthatcase,theblock
confirmationtimesalreadyincreasenoticeable.
FromthiswecanlearnthatabalancedhealthyBitcoinnetworkneedstobedimensionedto
haveamax.capacitythatisabout33%aboveitsaveragetraffic.So,foranaveragetrafficoff
9MBperblock,therecommendedminimumBSLshouldactuallybe1.33*9=12MB.
Constraint(C1)isthereforeevenalittleconservative,becauseitonlyappliesafactorof
ca.1.21andnot1.33.Clearly,reducingtheBSL,likeafactorof1.00wouldsuggest,wouldbe
thewrongwaytogo,sinceanalreadycongestednetworkwouldbecomeevenmorecongested.
Notealsothattheconstraint(C1)isnotthelastconstraintintherow.Therestillis(C2),which
ensuresthatevenunderheaviestload(asitmightbecausede.g.byspammers),thegrowthrate
islimitedtoalongtermvalueof41%peryear(orinextremecase100%forconsistent
>80%votemajority).So,therecannotbea21%BSLincreaseweekafterweek,asitappears
whenonlylookingattheparameter1.21ofconstraint(C1).
Anotherwayofviewingthisparameter1.21is,thatassoonasaverageblockoccupancy
reachesorexceeds90%,theBSLwillberaised,nomatterwhattheminersvote.Because
constraint(C1)says0.90*1.21=1.09,whichwillbemappedtoaBSLadjustmentby+9%.
(Notethatadjustmentstepsare9%duetotheexponentialrepresentationoftheBSL,soablock
occupancyofonly89%,whichyields0.89*1.21=1.08,willnotyettriggeraBSLincrease,
because1.08getsroundeddownto1.00ontheexponentialresolutiongridofblocksizes.)
WhenlookingatFig.41from[5],weseethat90%blockoccupancycorrespondstothevalueof
2.7onthexaxis.Thisisjustbeforethesituationstartsbecomingcritical,sothe90%itisagood
designvaluetohelpavoidingtheworst.
Fig.41: Networkcongestioneffectsindependenceofhowmuchblocksarefilledrelative
tothemaxblocksize.Diagramtakenfromreference[5].
Abouttheothersideoftheinterval,the4.585:ThisissimplydesignedsuchthatBSLwill
decreaseifactualblockoccupancyfallsbelow20%.Again,theexponentialresolutiongridfor
[22of37]
theblocksizelimitisrespected,thesmallestdecreaseincrementofBSLis8.3%(=factor0.917
=1/1.0905),andBSLisonlydecreasedifactual_block_size*4.585isbelow0.917.Since
0.20*4.585=0.917,thisisthecasefor<20%averageblockoccupancy.
Moreover,thevalue4.59alsoservesanotherpurpose:Itavoidsthataminorityofminerscan
preventaBSLincreasebyminingemptyblocksandtherebyreducingtheaverageactualblock
size(aABS).Let'staketheexamplethat50%ofminerscreateemptyblocks,whileanother50%
ofminerscreatereasonablefilledblockof0.8*BSL_curr.Inthatcase,aABS=
(0.5*0+0.5*0.8)*BSL_curr=0.4*BSL_curr.TheBSLvoteispostprocessedtobeforcedtobe
<4.59*0.4*BSL_curr=1.836*BSL_curr,hencea51%votingmajoritycanstillmakesurethat
BSLcanbeincreased.
[Rat5]
Q.: Whyisthemaximuminstantaneous(i.e.weekly)increaseordecreaseofBSLlimitedtoafactor
of1.682(=2^(6/8))bydefinitionoftheBSLvotingbitfieldintheheader,whichonlyranges
from1/1.682*current_BSLto1.682*current_BSL?
A.: Thislimitationisanimplicitconsequenceofotherdesignparameters,namelythelongterm
min/maxchangerateofBSL.Acc.toconstraint(C2),thelongtermBSLcannotchangebymore
thanafactorbetween0.8593750and1.4765625.Thismeans,evenintheextremeandunlikely
casethatthisrangeisfullyusedtotheoneedgeinoneweek,andtotheotheredgeinthenext
week,wecouldnotseeanincreaseofmorethanaafactor1.4765625/0.8593750=1.72.To
realizesuchachange,avotingof2^(7/8))=1.834*current_BSLwouldbenecessaryand
votesoutsidetherange2^(7/8))..2^(+7/8))wouldbeuseless.Thevotingprotocolrestricts
thisrangebyonemorestep,puttingtheeffectivelimittotherange2^(6/8))..2^(+6/8)).In
theextremeunlikelycasethatagreateradaptationstepwouldbedesired,thiswouldjustbe
achievedinthenextvotingintervaloneweeklater.Therestrictiontomax.range2^(6/8))..
2^(+6/8))ismadetokeeponebitavailablefortheOverbookingIndicator.
Notethatwedidnottalkabouttheextreme80%minermajorityvotinghere,whichimpliesa
slightlygreatertheoretical(!)rangeduetoconstraint(C2).Thiswouldyielda(very)theoretical
extremeinstantaneousjumpofBSLbyafactorof1.9296875/0.7656250=2.52,which,ifvoted
for,requiredavotingrange2^(11/8))..2^(+11/8)).However,thiswouldonlypractically
bepossibleif80%ofminersinoneweekvotedforextremelowblocksizes,and80%votedfor
extremehighblocksizestheverynextweek(orviceversa),sopracticallythissituationcanbe
ruledout.Andevenifithappened,thiswouldbenobigdealatall,itwouldjusttakeone
additionalweek(another1008blocksofvoting)toachievethedesiredadjustmentstep,e.g.by
votingforastepincrementof2^(+6/8))intwosuccessiveweeks.
Tosummarize:ThevotingformatthatrestrictstheBSLincrementfromoneweektothenextto
stepsbetween2^((+/6)/8)),i.e.betweenfactors0.594and1.682,isfullysufficientanddoes
notrestrictthevotingrangeinanysignificantandpractically,noteventheoretically,relevant
way.Bythisrestriction,wegetanextrabitavailablethatisusedasOverbookingIndicator.
[Rat6]
Q.: Whyisthe50%quantile(median)choseforthevotingdecision?Andwhyisthe80%majority
criterionchosenfortheinitialvoteabouttheinitialblocksizelimittostartwith?
A.: Thegeneral50%quantile(median)ischosentomakeitimpossibleforanyminerminorityto
manipulatethevotingdecisioninonewayoranother.Iftheprotocolusedthe20%quantile,it
wouldmeanthataminorityof21%couldvotefor1MBblocksforever,andthe1MBvote
wouldbetheeffectivevoteforever.
[Sidenote:Eventhen,theblocksizelimitwouldnotbestuckat1MBforever,becauseofconstraint
(C1),compare[Rat4]:Ifactualblocksizesaresufficientlyhigh,theprotocolwillincreasetheBSL
inanycase,evenif100%ofminersvoteagainstit.ToavoidBSLincrease,minerswouldinthat
casehavetocreatesmallerblocks.]
[23of37]
Iftheprotocolusedthe80%quantile,itwouldmeanthataminorityof21%ofminerscould
enforceanupvoteoftheblocksizelimitforever.
[Sidenote:Eventhen,theblocksizelimitwouldnotgrowindefinitely,becauseofconstraint(C1),
compare[Rat4]:Ifactualblocksizesaresufficientlylow,theprotocolwillnotincreasetheBSLany
further(andmightevendecreaseit),evenif100%ofminersvoteagainstit.ToavoidBSLdecrease,
minerswouldinthatcasehavetocreatelargerblocks.]
Thatiswhythe50%quantileappearstobethemostappropriateandfairestwaytogo.The50%
medianvaluemeans:
Therearenotmorethan50%ofminerswhothinkthatthenewBSListoosmall,
andtherearenotmorethan50%ofminerswhothinkthatthenewBSListoolarge.
Sothisseemstobethemostagreeablesolution.
FortheINITIALvote(first1008blocks1stvotingweekafterBIP10Xactivation)which
determinestheBSLwheretostartwith,ahighermajorityof80%isrequired.Thisensuresthat
theprotocolwillnotstartwithatoolargeBSLthattoomanyminerswoulddisagreewith,to
avoidatoobigdisruption/shock.Heretheideaofawiderconsensusdominates,inawaythatin
caseofdoubt,asmallerblocksizeisgivenpreferenceto(hencethe20%quantileistaken,not
the80%quantile).Thegivensolutionmeans:
For80%oftheminers,theinitialBSLchosenbyBIP10Xisnottoobig.
[Rat6b]
Q.: Whyusingaquantileforthevoteinthefirstplace?Whynote.g.takingtheaverageofallvotes
exceptthetopandbottom20%votes?
A.: Thisappearsfaireronlyatthefirstglance.Infactitwouldbemorepronetomanipulation.For
example,a30%minoritycouldmakeanextremelyhighvote.While20%ofvotesarecutoff,
theremaining10%arestilltakenintoconsiderationintheaveragingprocess,andtherebythe
finalvotewillbecomebiasedtowardstohighvalues.
Inthenextvotinginterval,someminerswouldtendtomaketacticalvotes:Tocountera
tacticalvoterontheoneedgewhovotesforextremelyhighvalues,theothersidemightdecide
tovoteforextremelylowvalues,withtheintendthatthefinalaverageturnsouttobewhatthey
want.
Sosuchaveragingrulewouldopenupthevotingprocesstothefieldofgametheoryand
tacticalvoting,whichiscompletelyunnecessary.Because,thequantileruleavoidstactical
votingfromthestart.IfaminerwantstohaveaBSLofsay10MB,thebesthecandoistovote
for10MB,nomatterwhattheotherminersdo!Ifmostoftheotherminersvotebelow/above
10MB,hecouldnotoffsetthisbyhimselfvotingwithaparticularly[high/low]votelikee.g.
[100MB/1MB].Itwouldnotchangethefinalquantileselected.Onlyavotingrulebasedon
quantileseliminatestacticalvoting,anditisthereforethefairestvotingschemepossible.
[Rat7]
Q.: WhyistheOverbookingfeatureintroducedtoallowblocksbeyondthenominalBSL?
A.: Overbookingismeanttoactonlyasalastresortiftransactionsstackuptoomuch,asitcouldbe
thecaseduringatemporaryspamattack.Inthiscase,blocksizeisallowedtobegreaterthan
thenominalcurrentblocksizelimitdenotedbyBSL_curr.Thisgivessomeamountofelasticity
orflexibilitytothenetwork.Tolimitthenegativeimpactoftoolargeblocks,themaximum
overbookingallowedisafactorof4.Moreover,theprotocolonlyallowsonaverage(ca.150day
average)10%ofblockstobemorethan2timeslargerthanBSL_curr,andonly30%ofblocksto
belargerthanBSL_curr(butsmallerthan2*BSL_curr).
Anotherwayofillustratingthelimitationsisasfollows:
Theeffectivewindowlengthoftheexponentialwindowfordeterminingtheaverage
overbookingblockratio(OBR)is114days(mathematicaltermdescribingatwhattimein
thepasttheexponentialaveragingweightwindowhasdecayedto36.8%(=1/e),when
[24of37]
100%istheweightatthepresenttime).Togetherwiththe10%/30%limitsmentioned
before,thisimpliesforexample:
ExceedingthenominalBSLbyafactor4isallowedonnomorethan11successivedays,
wheneveryblockisoverbookedthisway(or25dayswitheverysecondblockbeingof
regularsize).
ExceedingthenominalBSLbyafactor2isallowedonnomorethan40successivedays,
wheneveryblockisoverbookedthisway(or104dayswitheverysecondblockbeingof
regularsize).
Moreover,acertaincounterincentiveagainstcreatingoverbookedblocksisbuiltintothe
protocol:ItistherulethatacertainfractionofTXfeesmustbedestroyed(spenttoapredefined
unspendableaddress).Thisfractionishigher,themoretheblocksizeexceedsBSL_curr.
Accordingtothisrule,thecompleteTXfeesoftheblockareconsideredtobespreadequally
overtheentireblocksize,andthen25%ofthosefeesthatfallintheareaexceedingBSL_curr
havetobedestroyed.
Withthisruleset,itisconsideredfairtoassumethatundernormalcircumstancesoverbooked
blockswillnotoccur.However,shouldanemergencysituation(veryhighTXload)occur,the
protocolprovidesanemergencyexittoincreasetheblocksizeshortterm(decisioncanbe
madeonaperblockbasis)toavoidtoolongTXdelaysthatmaymakeusersunhappyand
therebyreduceutilityandvalueofBitcoin.
[Rat8]
Q.: Whyistheconfigurationparameterblocksizelimitvoteinbitcoin.confsetto1.7aby
default?
A.: Thisparametermeansthatthedefaultvotingstrategyistovoteforablocksizethatisbya
factor1.7higherthantheactualaverageblocksizeofthelast1008blocks.Thisappearstobe
reasonable,becauseahealthynetworkwithouttoomanynetworkdelaysshouldhaveaBSLthat
iscomfortablyabovetheactualaverageblocksize,asFig.4.1demonstrates.Thefactor1.7
comesdowntoaneffectiveaveragevoteforonlyfactor1.63whenconsideringtheblocksize
resolutiongridimposedbytheexponentialformatoftheBSL(incrementsof9.05%).Afactor
1.63meansthatasituationisaimedforatwhichtheactualblocksizeisca.1/1.63=61%ofthe
BSL.OnFig.4.1thiscorrespondstothevalue1.83ontheabscissa,andhereextrablock
confirmationtimesduetocongestionsareintherangeof..1blocks,whichappearstobea
reasonabledesigntarget.
[Rat9]
Q.: WhyisexponentialaveragingwithforgettingfactorappliedforcalculationoftheaverageBSL
andtheaverageoverbookingratio?Whynotcalculatinganormalaverage(rectangularinstead
ofexponentialweightingwindow)?
A.: Theexponentialaveragingmethodisaverycycleandmemoryefficientmethod,becauseunlike
forarectangularaveragewindowitdoesnotrequiretostoreabignumberofindividualvalues
overwhichtoaverage,anditstillrealizesafloatingaveragingwindow.Moreover,ithasthenice
propertythatyoungervaluesareweightedmorethanoldervalues.Byonesingletuning
parameter,namelytheforgettingfactor,theeffectiveaveraginglengthcanbetunedwithoutany
furthermodificationofthesoftwarecode.Forfacilitatingdimensioning,theeffectivewindow
lengthcanbecalculatedas1/(1forgettingfactor).
Insummary,themethodiseasytoimplementandtoadapt,easytodimension,anditshows
favorablebehavior.
[25of37]
5 Simulations
Withconstraint(C2)oftheBSLcalculation,thelongtermchangerateoftheBSLgetslimited.
Dependingonthevotingconditions,oneoutoftwosetsofmin/maxlimitsapply.Firstwelookat
normalvotingconditionsthisisthesituationwhenthereisNOTa>80%minermajorityvoting
forastronginordecreaseofBSL.
Inthiscase,everytimethatanewBSLiscalculatedfromminers'votesandfromactualblocksizes
(i.e.every1008blocks1week),thenewBSL_currisconstrainedtobebelow
189/128*BSL_LongTermAvg=1.4765625*BSL_LongTermAvg
andabove
AfterBSL_currhasbeendeterminedthisway,longtermaverageisupdatedby
BSL_LongTermAvg=32244/32768*BSL_LongTermAvg+(132244/32768)*BSL_curr.
(32244/327680.984)
The3parameters189/128,110/128and32244/32768determinegrowth/declinerates.
Asimulationhasbeenwritten(sourcecodeinappendix)forFreeMat4.0andhasbeenrunfor
variousextremecasesofmaximumgrowthanddeclinerates.
Theparametersarechosenbydesignsuchthatadoublingevery2yearsandahalvingevery8years
isachievedwheneachBSLupdatepushesagainsttherespectivelimitof(C2).Thisisverifiedby
simulation,asshownbelow.
Thefollowingsimulationsanddiagramsassumewithoutlossofgenerality,thatBIP10Xactivation
(morepreciselyblockM+1008)occursinthebeginningofyear2016.
Note:ThealgorithmassumesthatbeforestartofBIP10X,theBSLwasconstantandidenticaltothe
BSLvaluesetasinitialBSL.ThisisbecauseBSL_LongTermAvgisinitialiedwiththeinitialBSL,as
specifiedinch.2.2.Asaconsequence,thereferencestarttimeoftheadjustmentisimplicitlyback
datedtoapointintimethatliesoneyearbeforeBIP10Xactivation.Therefore,thefirstBSL
doublingoccursalready1yearafterBIP10Xactivation,butthenevery2yearsafterwards.Thiscan
benicelyseeninthe3rdfigureofsimulation(SIM01)(nextpage).
[26of37]
(SIM01)Inthemaximumgrowthcase,itisassumedthatallvotesaresufficientlyhighorthe
blocksthemselvesaresufficientlyoccupied(actually,onlythelatterissufficient),suchthatthe
actuallimitforBSLgrowthisdeterminedbyconstraint(C2).Simulationstartedwithinitial
conditionBSL_curr=1MBandthenmaximizedgrowthrate.Itcanbeseenthatafairlyconstant
growthrateof+41%peryear(+100%per2years)isachievedfromthebeginning.
Zoomedinforthefirst4years,illustratingdoublingevery2years:
[27of37]
(SIM02)Inthemaximumdeclinecase,itisassumedthatminervotesaresufficientlyloworthe
blocksthemselvesaresufficientlyempty(actuallyonlythelatterissufficient),suchthatactuallimit
forBSLdeclineisdeterminedbyconstraint(C2).Simulationstartedwithinitialcondition
BSL_curr=4MB,andthenmaximizeddeclinerate.
Asintendedbydesign,weseeahalvingevery8years(firsttimeatt_ref+8years,witht_refbeing
oneyearbeforeBIP10Xstarts.)
Thefollowingshowstheanalogoussimulationsforthecasethatgrowth/declineisboostedby
>80%minervotes,suchthattheBSLdoubling/halvingratesareroughlyspeedupbyafactorof2.
Now,constraint(C2)islessrestricitivethanbeforeandisrestrictingBSL_currtobebelow
andabove
Theeffectisshowninthefollowingsimulations:
(Inthesimulationscript,wesettheparameterrandom_80percent_boost=1.0)
[28of37]
(SIM03)Simulationsforthegrowthcaseshowadoublinginabitmorethan1year,asintendedby
design.Forexample,after10years(20152025)BSLhasincreasedbyroughlyafactor
2^10=1024,whichcorrespondsto10doublings,i.e.oneperyear,andfurtherdoublingstheyears
after:
Zoomedin:
[29of37]
(SIM04)Simulationsforthedeclinecaseshowahalvingevery4years,asintendedbydesign:
[30of37]
Appendix
A.1 Overview of BIP10X's Hardcoded Parameters and Design Choices
VotinganddirectBlockSizeLimitparameters:
75%=minermajorityforBIP10Xactivation
50%=50%ofBIP101minersarecontributingtotheBIP10Xactivationcondition
80%=majoritydeterminingtheinitialBSL(i.e.20%quantile)
50%=quantile(median)fornormalBSLadjustment
80%=majority(20%quantile)foracceleratedBSLadjustment
1MB=min.valueforinitialBSL
4MB=max.valueforinitialBSL
1,000,000byte=floor(2^(0/8)*1MB)=absoluteminimumBSL
60,096,776,975byte=floor(2^(127/8)*1MB)[60.1GB]=absolutemaximumBSL
3,938,502,375,863,834byte=floor(2^(255/8)*1MB)[3939TB]=absolutemaximum
BSLwhenactivatingayetreservedbit(bysimplehardforkinaverydistantfuture)
2^(1/8)[1.090508]=stepincrementfactorofpossibleBSLvalues
2^(6/8)[1.6818]=greatestinstantaneousBSLadjustmentstepfactor(ineitherdirection)
BlockSizeLimitaveragingandconstraints:
32244/32768[0.984]=Forgetting_factordeterminingaverageBSL,whichisthebasisfor
limitingthelongtermgrowthoftheBSL.Itcorrespondstoaneffectivewindowlengthof
1/(10.984)62.5weeks1.2years
189/128=1.4765625=Parameterlimitingthemax.longtermgrowthofBSLtoca.41%p.a.
(togetherwithaboveforgettingfactor)undernormalvotingconditions
110/128=0.8593750=Parameterlimitingthemax.longtermdeclineofBSLtoca.8%p.a.
(togetherwithaboveforgettingfactor)undernormalvotingconditions
247/128=1.9296875=Parameterlimitingthemax.longtermgrowthofBSLtoca.100%p.a.
(togetherwithaboveforgettingfactor)incaseof>80%minerupvote
98/128=0.7656250=ParameterlimitingthemaxlongtermdeclineofBSLtoca.16%p.a.
(togetherwithaboveforgettingfactor)incaseof>80%minerdownvote
[39704/32768;150244/32768][[1.21;4.59]]=Rangerelativetotheaverageactualblock
sizeofthelastvotingperiod(=1008blocks).TheeffectiveBSLvoteisforcedtoliewithinthis
range.
Overbookingofblocks:
16383/16384=0.99993896484375=Forgettingfactorforcalculatingaverageoverbooked
blocksratio.Itcorrespondstoaneffectivewindowlengthof114days=16.25weeks=1/3
year.
2=max.overbookingfactorforupto30%overbooking
30%=max.ratioofoverbookedblocks
4=max.overbookingfactorforupto10%overbooking
10%=max.ratioofblocksoverbookedbymorethanfactor2
[31of37]
A.2 Comparison of Different Block Size Evolution Proposals

Hereisaconcisecomparisontable,basedon[6]andfurtherextended:
Blocksizelimitevolutionmechanism:
[1]BIP100: minervoting
[2]BIP101: fixedexponentialgrowthschedule
[3]BIP102: constantblocksizelimit
[4]BIP103: fixedexponentialgrowthschedule
[x]BIP10X: minervotingandactualblocksize;plusshorttermadaptationtotemporarypeaks.
BlockSizeLimitgrowth/decline:
[1]BIP100: Byminervoting,x0.5x2.0every12000blocks(3months)
maxgrowthrate:+1982%p.a.(x20.82p.a.)
maxdeclinerate:95.2%p.a.(x0.048p.a.)
[2]BIP101: Fixedgrowthrate:+41.4%p.a.=+100%every2years
[3]BIP102: +/0%p.a.(2MBytestatic)
[4]BIP103: Fixedgrowthrate:+17.7%p.a.=+100%every4.3years(+4.4%every97days)
[x]BIP10X: Dependingonactualblocksizeandminer'svotes(medianofallvotes),
longtermgrowth/declineraterestrictedto
max.+41%p.a./8%p.a.
=+100%in2years/50%in8years.
With80%minersupport,maximumratesgetpushedto
+100%p.a./16%p.a.
Votingabusepossiblebyminerminority:
[1]BIP100: Yes,minerminority(20%)canenforceexcessiveBSLdeclineofca.95%p.a.
[2]BIP101: No(nominervote)
[x]BIP10X: No,aminerminoritymakingexcessivevotesineitherdirectionhasnoeffectatall.
Votingabusepossiblebyminermajority:
[1]BIP100: Yes,mayenforceexcessivegrowth/declinerateofca.+2000%p.a.or95%p.a.
[x]BIP10X: Limited:Minervotecaninfluencegrowth/declinerateonlywithin[16%..+100%]p.a.
Butifactualblocksizedoesnotkeeppacewithminervote,evena100%minervote
cannotchangetheblocksizelimit.
Riskduetolazymineroperatorswhokeepbitcoin.confunmodified:
[1]BIP100: ??Defaultvotingmechanismnotspecified.
[x]BIP10X: No.Defaultparametercausesreasonablevoteforca.1.63timesavg.actualblocksize
BlockSizeLimitatinitiation:
[1]BIP100: 1MB
[2]BIP101: 8MB(dpdt.ontimeofinitiation,0.7%increaseperweek,100%per2years)
[3]BIP102: 2MB
[4]BIP103: 1MB
[x]BIP10X: 14MBdpdt.onminervotein1stvotingweek(takesminimumoftop80%votes)
[32of37]
FinalBlockSizeLimitandwhenisitreached:
[1]BIP100: 32MB canslowdown/stop/reducebyminervote
[2]BIP101: 8192MB 20360106
[3]BIP102:
2MB 20151111
[4]BIP103: 2048MB 20630709
[x]BIP10X: 60.1GB canslowdown/stop/reducebyminervoteorpermanentlysmallblocks
(theoreticallyin2047w/o80%minersupport,or2031with80%miner
support,butwillneverhappenifactualblocksarenotsufficientlyfilled)
ElasticityofblocksizesincaseoftemporaryhighTXload:
[1]BIP100:No(fastestreactiontime=x2increaseevery3months)
[2]BIP101:No(fixedgrowthrate)
[3]BIP102:No(constant2MB)
[4]BIP103:No(fixedgrowthrate)
[x]BIP10X:Yes,immediateupto4xblocksizelimitoverbookingallowedinexceptionalcases,
butassociatedwithacounterincentivetoavoidabuse.[Rat7]
Minervotingusedtoinitiatethehardfork?
[1]BIP100: Yes,supportwith10800outoflast12000blocks(90%)
[2]BIP101: Yes,supportwith750outoflast1000blocks(75%)
[3]BIP102: No
[4]BIP103: No
[x]BIP10X: Yes,supportwith756outoflast1008blocks(75%);BIP101blockscountedby50%
Whendoesthehardforkhappen?
[1]BIP100: 20160111,after90%minersupport
[2]BIP101: 20160111,twoweeksafter75%minersupport
[3]BIP102: 20151111
[4]BIP103: 20170101
[x]BIP10X: today,23weeksafter75%minersupport
[33of37]
A.3 Simulation Source Code and Simulation Tool

How to Use FreeMat Tool
SimulationwasdoneusingFreeMat4.0.FreeMatisfreelyavailableunderGPLv2licenseforall
majoroperatingsystems.Toexecutethissimulationscript,dothefollowingsteps:
CopypastethesourcecodebelowtoanemptytexteditorwindowandsaveasBSL_change.m
oranyotherfilenameendingwith.m(filenamehasonlyletters,numbersandunderscore,
firstcharacterisaletter).
InstallFreeMat4.0orlater.
StartupFreeMat.YouseetheGUIasshowninthescreenshotbelow.
Browse(1)tothedirectorwhereyourfileBSL_change.mislocated.Youcanalsousecd
commandlikeintheconsoleofyouroperatingsystem.
Type(2)editBSL_change.m<ENTER>toopenthefileinanmfileeditorwithsyntax
highlighting.
Modifytheparametersasdesired,intheparametersectionofBSL_change.m.
Type(3)BSL_change<ENTER>toexecutethescriptwhichstartsthesimulation.
[34of37]
The Source Code (BSL_change.m)

%
%SimulationforFreeMatv4.0(MatlabclonewithGPLv2license)
%
%Purpose:FindouthowtheBtcoinBlockSizeLimit(BSL)evolveswiththerulesetofBIP10X,in
%thecornercasethatthegrowthordeclinerateisdeterminedsolelybyconstraint(C2)
%ofBIP10X(thenormallimit,notthestretchedlimitof80%minermajority).
%Incaseofgrowth,thiscorrespondstothecasethat>50%ofminerscontinuallyvote
%forsubstantialBlockSizeLimitincrease,orthattheblocksaresufficientlyfull
%ineachoneweekaverageperiod,suchthatotherfactorsdonotlimitthegrowth.
%Infact,iftheblocksaresufficientlyfull,thiswouldalreadybeenoughtocausethis
%BSLincrease,irrespectiveoftheminervotes.
%Incaseofdecline,thiscorrespondstothecasethat>50%ofminerscontinuallyvote
%forsubstantialBlockSizeLimitdecrease,orthattheblocksaresufficientlyempty
%inaoneweekaverageperiod,suchthatotherfactorsdonotlimitthedecline.
%Infact,iftheblocksaresufficientlyempty,thiswouldalreadybeenoughtocausea
%BSLdecline,irrespectiveoftheminervotes.
%
%Note:Thissimulationassumes52weeks==1yearforsimplicity(theerroris1.25daysor0.34%).
%Thissimulationassumesfurtherthat1week=1008blocks.
%Sincehashrateisexpectedtoincreaselongterm,beitaloneduetotheadvancesin
%technology,realityisexpectedtoshowthat1008blocks<1week.
%Thiscanbeaccountedforbysetting'time_warp_hash_speedup_factor'accordingly.
%
%Asaconsequence,resultsareslightlybiasedinthatactualgrowth/declineratesunderthe
%givencircumstancescanbeexpectedtobeslightlystrongervs.timethanwhatthis
%simulationshows.
%Ontheotherhand,actualgrowthratescannotalwaysbeexpectedtobeatthemaximum
%inreality,andthiseffectshouldoffset(orevenovercompensate)thefirstone.
%
%(C)2015byMichael_S
%
%
closeall;clearall;
%
%%#0)ParameterSettings:
Start_Year=2016+0*1/12;%e.g.2016.5means1stJuly2016
NbYrs=8;%simulateforthisnumberofyears(1008*52blocks==52weeks==1year)
%Ifblocktimesareshorterthan10min,entercorrespondingfactor<1.0here.Orviceversa:
time_warp_hash_speedup_factor=1.0;%[1.0]e.g.0.9means9minavg.blocktime
BSL_init_MB=1;%Initialvalue,e.g.1or4[MByte]
Direction=1;%1=grow,1=decline
%averaging_method='flat';%'flat'or'forgetting_factor'<NOTusedinBIP10X
averaging_method='forgetting_factor';%'flat'or'forgetting_factor'<thisoneforBIP10X!
%forgetting_factoronlyapplicableifaveraging_method=='forgetting_factor':
forgetting_factor=32244/32768;%(~0.984)=eff.windowlength=1/(10.984)=62.5weeks=1.2years
%Parametersfor'flat':(thismethodisnotusedinBIP10Xgivesworseresults)
%incmax_yearAvg=1.24;%NewBSLcanbemax.thismuchhigherthanavgoverlastYr
%decmin_yearAvg=0.90;%samefordecrease
%Parametersfor'forgetting_factor':(thismethodisusedinBIP10X)
incmax_yearAvg=189/128;%=1.4765625;%NewBSLcanbemax.thismuchhigherthanavgoverlastYr
decmin_yearAvg=110/128;%=0.8593750;%samefordecrease
incmax_yearAvg2=247/128;%=1.9296875;%parameterforgrowthspeedup(needs80%votemajority)
decmin_yearAvg2=98/128;%=0.7656250;%parameterfordeclinespeedup(needs80%votemajority)
%RandomEvent1:>80%minervote:Boostedmaximumgrowth/declinerate,stretchedlimitsapply:
random_80percent_boost=0.0;%probabilitythataBSLincreaseisboostedby>80%minervote
%RandomEvent2:
random_one_step_less=0.0;%probabilitythatBSLadjustmentismodifiedasfollows:
%BSLisonestepsmaller(incaseofgrowth)orhigher(incaseofdecline)onthe
%BSEresolutiongridthenwhatitwouldotherwisebe.
%PlotScreenSizemodifyindependenceofyourmonitor'sresolution:
plot_window_width=900;
plot_window_height=360;
%
%%#1)Initializations:
N=round(NbYrs*52/time_warp_hash_speedup_factor);%nbof1008blockperiods(~weeks).
BSL_vector(1:52)=BSL_init_MB;%[inMByte]InitialisetheBSLvalueforthefirst52weeks
BSL_vector=[BSL_vector,nan*ones(1,N)];
%GranularityduetoexponentialrepresentationofBSL,granularity=ca.9.05%steps:
upstep=2^(1/8);%=1.09050773:+9.0508%
downstep=1/2^(1/8);%=0.91700404:8.0300%
%InitializeBSL_LongTermAvgonlyneededifaveraging_method='forgetting_factor':
BSL_LongTermAvg=BSL_init_MB;
%
%%#2)TheSimulation:
ifDirection==1,%GROWTHCase
%TrytoincreaseBSLasmuchaspossible,forthegivenlimits
fork=52+1:52+N,%startwithfirstweekofthe2ndyear
%CalculateaverageBSL
ifstrcmpi(averaging_method,'flat'),%notBIP10X
BSL_LongTermAvg=mean(BSL_vector(k52:k1));
elseifstrcmpi(averaging_method,'forgetting_factor'),%BIP10X!
BSL_LongTermAvg=forgetting_factor*BSL_LongTermAvg+...
(1forgetting_factor)*BSL_vector(k1);
else
disp('ERROR:Invalidvalueforparameter"averaging_method"!')
return;
end
%FindlargestpossibleBSLforweekk:
BSL_try=BSL_vector(k1);%firsttrywithBSLofpreviousweek
ifrand()<random_80percent_boost,
incmax=incmax_yearAvg2;%boostedgrowthby>80%minervote
else
incmax=incmax_yearAvg;%normalcase
end
whileBSL_try*upstep<=BSL_LongTermAvg*incmax,%Trytogoupasmuchaspossible
BSL_try=BSL_try*upstep;
end
BSL_vector(k)=BSL_try;
ifrand()<random_one_step_less,
%Arandomeventcausesthegrowthtobenotquiteasbigasitcouldbe:
BSL_vector(k)=BSL_vector(k)/upstep;
end
end
elseifDirection==1,%DECLINECase
%TrytodecreaseBSLasmuchaspossible,forthegivenlimits
fork=52+1:52+N,%startwithfirstweekofthe2ndyear
%CalculateaverageBSL
ifstrcmpi(averaging_method,'flat'),%notBIP10X
BSL_LongTermAvg=mean(BSL_vector(k52:k1));
elseifstrcmpi(averaging_method,'forgetting_factor'),%BIP10X!
BSL_LongTermAvg=forgetting_factor*BSL_LongTermAvg+...
(1forgetting_factor)*BSL_vector(k1);
else
disp('ERROR:Invalidvalueforparameter"averaging_method"!')
return;
end
%FindsmallestpossibleBSLforweekk:
BSL_try=BSL_vector(k1);%firsttrywithBSLofpreviousweek
ifrand()<random_80percent_boost,
decmin=decmin_yearAvg2;%boosteddeclineby>80%minervote
else
decmin=decmin_yearAvg;%normalcase
end
[35of37]
whileBSL_try*downstep>=BSL_LongTermAvg*decmin,%Trygodownasmuchaspossible
BSL_try=BSL_try*downstep;
end
BSL_vector(k)=BSL_try;
ifrand()<random_one_step_less,
%Arandomeventcausesthedeclinetobenotquiteasbigasitcouldbe:
BSL_vector(k)=BSL_vector(k)/downstep;
end
end
else
disp('ERROR:Invalidvalueforparameter"Direction"!')
return
end
%
%%#3)PostProcessing&Display:
%YeartoyearpercentagechangeofBSL:
%(thisoneislessmeaningfulbecausemore"noisy",Iusetheothermetricfordisplay)
BSL_percent_change_YoY=100*(BSL_vector(53:end)./BSL_vector(1:end52)1);
%YearlyaveragepercentagechangeofBSLsincethestart:(Iusethisfordisplay!)
years_tmp=(51+[1:length(BSL_vector(53:end))])/52;%years,withoutthefirstyearofcourse
factor_tmp=(BSL_vector(53:end)/BSL_vector(1)).^(1./years_tmp);
BSL_percent_change_avg=100*(factor_tmp1);
%Plotting
figure;
plot(Start_Year1+[1:N+52]/52*time_warp_hash_speedup_factor,BSL_vector);
gridon;
a=axis;
axis([Start_Year1Start_Year1+(N+53)/520a(4)]);
xlabel('Year')
ylabel('BlockSizeLimit[MB]')
title(['BlockSizeLimitvs.Time'])
sizefig(plot_window_width,plot_window_height)
if0;%Dont'tplotthisonenotasmeaningfulasthenextplot(ifplotwanted:change0>1)
figure;
plot(Start_Year+[1:N]/52*time_warp_hash_speedup_factor,BSL_percent_change_YoY);
gridon;
a=axis;
axis([Start_Year1Start_Year1+(N+53)/52min(0,a(3))max(0,a(4))]);
xlabel('Year')
ylabel('BSLchangevs.52weeksago[%]')
title(['YeartoYearBlockSizeLimitChangeRate'])
end
figure;
plot(Start_Year+[1:N]/52*time_warp_hash_speedup_factor,BSL_percent_change_avg);
gridon;
a=axis;
axis([Start_Year1Start_Year1+(N+53)/52min(0,a(3))max(0,a(4))]);
xlabel('Year')
ylabel('BSLavg.yearlychange[%]')
title(['YearlyAvg.BlockSizeLimitChangeRateSinceYear',num2str(Start_Year1,'%0.2f')])
[36of37]
References
[1]
BIP100(v0.8.1)byJeffGarzik,http://gtf.org/garzik/bitcoin/BIP100
blocksizechangeproposal.pdf
[2]
BIP101byGavinAndresen,https://github.com/bitcoin/bips/blob/master/bip
0101.mediawiki
[3]
BIP102byJeffGarzik,https://github.com/bitcoin/bips/pull/173/files
[4]
BIP103(?)byPieterWuille,https://gist.github.com/sipa/c65665fc360ca7a176a6
[5]
BitcoinNetworkCapacityAnalysisPart4:SimulatingPracticalCapacity
https://tradeblock.com/blog/bitcoinnetworkcapacityanalysispart4simulatingpractical
capacity
[6]
Asummaryofblocksizehardforkproposals,
https://lists.linuxfoundation.org/pipermail/bitcoindev/2015July/009808.html
[37of37]

A Hybrid Mechanism For Adaptively Adjusting Bitcoin's Block Size Limit (BIP10X)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

A Hybrid Mechanism For Adaptively Adjusting Bitcoin's Block Size Limit (BIP10X)

Загружено:

Авторское право:

Доступные форматы

Version0.

Terms, Abbreviations and Symbols

1 Overview of Main Characteristics of BIP10X

1.1 Introduction Schedule

2.2 Details of the Three Phases

2016 blocks difficulty

504 blocks time grid

Between 2016 and 3023 blocks grace period

Block M+1008: The first block that can be >1 MB

Operational Phase (Starting with Block M)

2.3 Version Number Field of BIP10X

Reading Version Number Field from Block Header

Part 1: Update of Overbooked Blocks Ratio OBR

Part 2: Condition When Overbooking is Allowed

Part 3: Counter-Incentive against Overbooking by Burning TX Fees

Validation Condition of an Overbooked Block

2.5 Re-Alignment of Long-Term Averaged Values

Re-Alignment of Overbooked Blocks Ratio (OBR)

3 New Parameters in Bitcoin.conf

A.2 Comparison of Different Block Size Evolution Proposals

A.3 Simulation Source Code and Simulation Tool

The Source Code (BSL_change.m)

Вам также может понравиться