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

Version0.
2(5September2015)
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[7].
CurrentBitcoinprotocoldoesnotcontainanyofthesefeatures,inparticularitdoesnotcontainany
minervotingmechanism.Nevertheless,aminervotingaboutfutureBlockSizeLimitisdefacto
implicitlydoneatthatmomentwhenanalternativeBitcoinimplementationlikeBIP100orBIP101
[1,2]getsdeployed.Thismeans,aminervotingcanbeimposedanytime,evenifnotforeseenby
thecurrentBitcoinsoftware.
BIP100[1]proposesaminervotingmechanismfortheBlockSizeLimit(BSL)builtintotheBitcoin
protocol.Thisinstitutionalizesablocksizelimitvotingmechanismasanormalprocesswithinthe
rulesoftheBitcoinprotocol.Thiscanbeseenasanalternativetothenoninstitutionalizedde
factovotingthattakesplacewhendeployingalternativeBitcoinforkimplementationscompetingfor
aminermajority.AninstitutionalizedvotingonBSLthatisbuiltintotheprotocolitselfisastrong
counterincentivetodeployingotherhardforkstobeactivatedbyminervoting(ifthesehardforks
areaboutblocksizelimit),becauseminerscouldequallywelljustcasttheirvotewithinthe
mechanismsofthecurrentprotocolitself.Thiswouldcalmdownfuturediscussionsabouthardforks
inthecommunityandwouldallowrefocussingonotherimportantissues,ofwhichtherearemany.
However,BIP100[1]isnotveryconcreteinalldetails(e.g.uncleardefinitionofvotemajority,
possiblya20%minoritycanquicklyforceBSLdown)andhasdisadvantagesbysolelyrelyingon
minervotesandbyallowingexcessiveannualBSLchangeratesinbothdirections.Ithasbeen
criticizedthatminers(andpossiblyminerminorities)wouldhavetoomuchunconstrainedpower.
Ontheotherhand,BIP101[2],thesecondofthemostpopularproposals,hasafixedgrowthrate
thatmakesanassumptiononfutureevolutionofBitcointrafficandbandwidthtechnologyover
decades,whichcannothardlybepredicted,andisthereforecriticizedastooinflexible.
ThisBIP10Xproposaltakesallideasofalltheaboveproposalsintoconsiderationandaddsnew
ideas,therebyprovidinganovelsolutionthatpromotestheadvantagesandeliminatesthemain
drawbacksofeachindividualproposalseensofar,particularlyBIP100andBIP101.Itprovides
flexibility,fairness,adaptabilityandplanningsecurity.
Here,BlockSizeLimit(BSL)isusuallydeterminedbyminervotes,butrestrictedandoverruledby
constraints.Minervotingisonlypossiblewithincertainlimits.Theselimitsarethelongterm
changerateoftheblocksizelimititselfaswellastheactualblocksize,suchthate.g.minerscannot
arbitrarilyvoteuptheBlockSizeLimit(BSL)whentheaverageactualblocksizefallsbehind.The
proposalalsoincorporatesaconditiontoboostBSLchangeratebyrelaxingconstraintswhen
supportedbyahugeminersupermajority.Moreover,anothermechanismcopeswithtemporary
highnetworkload,toallowapossibilityforshorttermreactionstominimizeuserdissatisfaction.
Thisthoroughlythoughttroughproposalisconcrete,completeanddetailedonallalgorithm,
functionandprotocolspecificationaspects.Carefulselectionofparametersanddefault
configurationfilesettingshasbeencarriedoutandarationaleisgivenforeachdecision.
Simulationswereperformed(sourcecodeprovided)toensureappropriatebehaviorinagreement
withtheintentionsofthedesign.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[1of39]
Version0.2(5September2015)
Version History
v0.1 30August2015
v0.2 5September2015
Firstversion
Additionalsimulationsadded,sourcecodeupdated,morerationales,
cleanupsoftypos,minoreditorialchanges
Themeasureofintelligenceistheabilitytochange.
AlbertEinstein
[2of39]
Acknowledgements
TheauthorexpressivelyacknowledgesallcontributionsthathavebeenmadeonBlockSizeLimit
evolution,beitintheformofBIPs,otherwriteups,orbypostsindifferentforums.
Allopenandpragmaticdiscussionshelpedtogetmoreandmoreinsights,leadingtothisproposal,
whichunderwentmanyiterationsbeforeitsfirstrelease.
ThisBIP10Xproposalwouldnothavebeenpossiblewithouttheearlierworkandinspirationsfrom
othercommunitymembersandcanbeseenasanaturalevolutioninthecommunity'sendeavorto
findthebestpossiblesolution.
ThegreatestacknowledgementgoestoeachindividualdeveloperwhocontributedtotheBitcoin
softwaresince2009.Withouttheirefforts,wewouldnotbeinthepositiontoholdthisdiscussion
today.
Foryouracknowledgement
Apersonwhonevermadeamistakenevertriedanythingnew.
AlbertEinstein
[3of39]
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 (Starting with Block N).........................................................................................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......................................................................................................................................27
Appendix............................................................................................................................................33
A.1 Overview of BIP10X's Hardcoded Parameters and Design Choices......................................33
A.2 Comparison of Different Block Size Evolution Proposals.....................................................34
A.3 Simulation Source Code and Simulation Tool........................................................................36
How to Use FreeMat Tool.........................................................................................................36
The Source Code (BSL_change.m).......................................................................................37
References..........................................................................................................................................39
[4of39]
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)of
theBlockSizeLimitBSL_curr.Itgetsupdatedonceevery1008blocks(1week).
BSE
BlockSizeExponent:Anintegerk0inBSEformatrepresentsthenumber
2^(k/8)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,
basedonlongtermexponentialaveragingwitheffectivewindowlengthof
114days.Itgetsupdatedeveryblock.
OperationalPhase Startswiththefirstblockminedacc.toBIP10Xrules(blockM),withBSLvote
includedintheblockheader.
Overbookedblock Thisisablockwithsizegreaterthanthecurrentnominalblocksizelimit
BSL_curr.Itisbyafactorofupto4greaterthanBSL_curr.
Overbooking
Themethodofcreatingoverbookedblocks.
rBSE
RelativeBlockSizeExponentformatspecifiesanumberrelativetoBSL_curr.A
miner'svoteisspecifiedinrBSEformatasavaluerelativetoBSL_curr,keeping
theBSEresolutiongrid.
SW
Software
TPS
Transactionspersecond
[5of39]
TX
vBSL_50
Bitcointransaction
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%stepincrements
acc.totheBSEformat.
Vote
Votinginterval
Anintervalof1008blocks,fromblockM+n*1008toM+n*1008+1007,n0.
[6of39]
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]
BlockSizeLimitrangeis1MBto60.1GB,withgranularityinstepincrementsof9.05%
[Rat3]
Aspecialblocksizevotecanbeconfiguredwhichsaysvotingforthenextblocksizelimitto
beequaltothecurrentblocksizelimit.
Aspecialblocksizevotecanbeconfiguredwhichsaysvotingforthenextblocksizelimitto
beequaltosomeFactortimestheactualblocksize.
Blocksizelimitdecisionbasedonmedian(50%quantile)[Rat6]ofallvotestoavoid
manipulationbyaminerminorityinupordowndirectionandtopreventtacticalvoting.
Minervotesdonothavetotalpoweroverblocksizelimitevolutiontheblocksizelimit
adjustmentisconstrainedby:
Actualblocksizeofpreviousweek(ifactualblocksizeistoofaroff,minervotefigures
getsaturatedaccordingly)
Longtermgrowthrateofblocksizelimitcannotbegreaterthan2xper2years(which
isthefixedrateofBIP101)or0.5xper8years.
Exceptincaseof>80%votingmajority:Thenthegrowthratelimitsarestretchedto
2xper1yearor0.5xper4years.
Theveryfirstblocksizelimitvotes(thoseofthefirst1008blocks)arenotrestrictedby
aboveconstraints,butarefreevotesonlyconstrainedbytheabsolutelimits
[1MB;4MB].80%majority(i.e.20%quantile)isusedforthisinitialvoting.[Rat6]
BlockoverbookingincaseoftemporaryhighTXload(upto4xnominalBlockSizeLimit),
butnotpermanentlyandwithcounterincentives[Rat7].
Twoadditionalconfigurationparametersforbitcoin.conf.
[7of39]
Moreinformationontherulesforblocksizelimitevolution:
Uponanycircumstances,fromoneweektothenext,blocksizelimitcanneverinor
decreasebymorethanafactorof1.682.Inpractice,weeklychangeratewillbemuchlower
duetootherconstraints.[Rat5]
Uponanycircumstances,theabsolutelimitsfortheblocksizelimitare[1MB;60.1GB].
However,theprotocolhastakenprecautions(areservedbit)foraverysimpleincreaseof
max.blocksizelimitto3939TB,whichcorrespondsto>1transactionpersecondper
personforaworldpopulationof10Billionpeople.Thismakestheprotocolverylongterm
futuresafe.
Ifblocksaremoderatelyoccupiedonaverage,thenminersdecide(median=50%quantileof
1008blocks'1week'svotes)byhowmuchblocksizelimitwillbeincreasedordecreased,
whereasmax.longtermgrowthisstrictlylimitedto
+41%/8%p.a.(=factor2xin2resp.8years).
Onlyincaseofminermajority>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%inthesamedirectioncanfurtherincreasegrowthratetoavg.+100%p.a.
Ifactualblocksarefilledby<20%onaverage,blocksizelimitwilldecreaselongtermby
8%p.a.,evenif100%ofminersvoteinoppositedirection[Rat4].Ofcourse,avote
majorityof>80%inthesamedirectioncanfurtherincreasedeclineratetoavg.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.
[8of39]
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.[Rat1]
4. 50%oftheblocksminedbyBIP101clients(versionnumber0x20000007)arecountedas
BIP10Xminedblocks(roundeddowntofullinteger),whiletheremainingBIP101blocksare
countedaslegacyblocks.ThismeansthateverysecondBIP101blockhelpstotriggerthe
BIP10Xactivationcondition.Notethattheserulesimplythattheactivationconditioncannot
bemetunlessatleast50%oftheblocksareproperBIP10Xblocks.[Rat1]
5. Whentheactivationconditionismetwiththeappearanceofblock
N,thegraceperiodstarts
(seeFig.21below).
Grace Period (Starting with Block N)

6. Thegraceperiodisbetween2016and3023blockslong,dependingonwhereblockNis
locatedonthe504blockgridthatisalignedwiththe2016difficultyadjustmentgrid,see
Fig.21below.
Duringthisgraceperiod,theBIP10Xminerstillbehaveslikealegacyminer,exceptthatit
sendstheversionnumber0x2000000B.
7. Thegraceperiodisoverwhenpropervotingstartsatblock
M.BlockMistheblockthat
fulfillstwoconditions:Firstitmustlieona1008blockgridwhichisoffsetby504blocksto
the2016blockdifficultyadjustmentgrid.Secondlyitsblockheightmustfulfillthecondition
[9of39]
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,orthatitvotesforafixed
BSLvalue,orthatitvotesforavaluethatisbyaspecifiedfactorgreaterthantheaverage
actualblocksizeoftheprevious1008blocklongvotinginterval.
10. Legacyminers(aswellasBIP101minersthatbehavelikelegacyminers)canstillparticipate
[10of39]
andcreatevalidblocksuntilblockM+1007.Afterthat,theirblockswillnotbeacceptedby
BIP10Xminersanymorebecauseofthedifferentversionnumberandmissingvotes.
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
intervalcorrespondstolessthan1008votes.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*1008)=201)ofsmallestBSLvotesarediscarded,andthe
smallestoftheremainingvotesisassignedtovBSL_20i(20%quantile).
vBSL_80d:The80%(=floor(0.80*1008)=806)ofsmallestBSLvotesarediscarded,andthe
smallestoftheremainingvotesisassignedtovBSL_80d(80%quantile).
Note:ThevaluesvBSL_50,vBSL_20iandvBSL_80darealreadylyingontheBSEresolution
grid(comparech.2.3,formatspecificationfor0xSS).
15. Finally,theupdateofBSL_currwillbecalculatedbysuccessivelyapplyingcertainconstraints
(min/maxfunctions).ThenthefinalnominalblocksizelimitBSL_currapplicableforthe
next1008blocks(M+n*1008toM+n*1008+1007)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,calculateaverageActualBlockSize,aABS,ofthelast
1008blocks.Thenapplymin/maxlimitstoforcethevalueintotheinterval
[39704/32768*aABS;150244/32768*aABS][1.21*aABS;4.59*aABS]:
[11of39]
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.Thisisachievedbyfollowingalgorithm:
IfvBSL_50>189/128*BSL_LongTermAvg,thenreducevBSL_50ontheBSE
resolutiongriduntilitbecomes189/128*BSL_LongTermAvg.
ElseifvBSL_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/3276810.984=0.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
[12of39]
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.
[13of39]
(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,nonBIP10Xblocksarerejected.
Afterthefirstblockwithsize>1MBhasoccurred,legacyminers(incl.BIP101miners)cannolonger
mineonthischain,socheckingbytes0and3becomessuperfluous.Itisproposedthatonlybytes1
and2arecheckedforblockvalidationfromthatpointonwards,whilebytes0and3areignored.In
particular,thereshallbenocheckofversionnumberinbyte0anymore.
Thisallowsfutureforkstoreusebyte0fortriggeringafuturehardforkactivationuponthe
conditionthatbyte00x0B=00001011.
[14of39]
2.4 Overbooking of Blocks: Block Size > Nominal Block Size Limit
Thenominalblocksizelimit,BSL_curr,isbasicallycalculatedfromweeklyminervotes,constrained
byarangearoundtheaverageactualblocksizeofthesamevotingintervalandby
BSL_LongTermAvg,whichisaroughly1.2yearaverage(exponentialaveragingwindow)of
BSL_curr.ThisprovidesastableevolutionpathfortheblocksizelimitBSL_curr.
Asthenamesays,blocksizelimitactuallymeansthatablockshouldnotbegreaterthanthat
limit.
However,therecanbetimesatwhichanunforeseeableloadoftransactionstemporarilyhitsthe
Bitcoinnetwork.Inthiscase,itshallbepossibletoexceedthelimitgivenbyBSL_currtoacertain
extend.Thisiswhattheblocksizeoverbookingfeatureisabout:
ItshallbepossibletocreateblocksinexcessofBSL_curr,ifthefollowinglimitsarekept:
Theblocksizeshallabsolutelyneverbegreaterthan4*BSL_curr
Theoccurrenceofoverbookedblocks2*BSL_currshouldnotexceeda30%threshold
Theoccurrenceofoverbookedblocks>2*BSL_currshouldnotexceedthestricter10%
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(off)or1(on))isset.
Foravalidblockitmustbeset=1ifblocksize>BSL_currandmustotherwisebeset=0.
UpdatethelongtermmetricOBRfortheratioofoverbookedblocks:
OBR=16383/16384*OBR+(1/16384)*OverbookingIndication(NewBlock)
Moreprecisely,ifHistheblockheightofthenewblock,then:
OBR(H)=16383/16384*OBR(H1)+(1/16384)*OverbookingIndication(block(H))
Part 2: Condition When Overbooking is Allowed

IfOBR(H)<0.10thenitisallowedtocreateablockH+1withsizeupto4*BSL_curr
ElseifOBR(H)<0.30thenitisallowedtocreateablockH+1withsizeupto2*BSL_curr
Whatthismeansinparticularisexemplifiedintherationalechapter4insection[Rat7].
Part 3: Counter-Incentive against Overbooking by Burning TX Fees

ThecreationofblocksexceedingthenominalBSL(BSL_curr)isfurtherdiscouragedbyimposinga
penalty:Anoverbookedblockmustdestroy25%oftheTXfeesthatareattributedtotransactions
exceedingthenominalBSL(BSL_curr)bysendingthemtotheunspendableaddress
1BitcoinEaterAddressDontSendf59kuE(oranotherequivalentaddresst.b.d.)
Moreprecisely,thefractionoftotalTXfeestobedestroyedisgivenbythefactor
factor=max(0;0.25*(ABSBSL_curr)/ABS),
whereABSistheactualblocksizeofthatblock.
[15of39]
Theamountofsatoshistobedestroyedis=ceil(total_tx_fees*factor).
ThismeansthatminerswillonlycreateblocksgreaterthanthecurrentnominalBSLiftheyreally
seeanoverallbenefit(e.g.usersatisfactionbitcoinpriceminingprofits).
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.
[16of39]
2.5 Re-Alignment of Long-Term Averaged Values

TherearetwopointsinBIP10XspecificationwhereLongTermAveragingtakesplace:
(double)BSL_LongTermAvg
(double)OBR(theOverbookedBlocksRatio)
Thesetwovariablesarelongtermaveragesfromanexponentialwindowwithinfinitememory.This
bearsarisk:SinceCPUimplementationsofdoubleprecisionarithmeticmightdifferslightly(notto
mentionCPUbugslikethefamousPentiumFDIVBugfrom1994),thismaycausethelongterm
averagedvaluestodivergeondifferentcomputersintheBitcoinnetwork,andthismayeventually
causeanunexpectedforkoftheblockchain.Itwouldbeunexpected,becausetheinternalstate(in
thesenseoftheexactvalueofthelongtermaveragedvaluebeinginterpretedasastatevariable)
wouldnotbeknownbytheothernodes.
Hence,itisconsiderednecessary,torealignthesevaluesregularlyamongstallnetworknodes,
suchthatallnodesperiodicallystartoverfromexactlythesamevalue(suchthattheyhaveexactly
thesameinternalstate).
BIP10Xspecifiesaperiodicrealignmentevery1008blocks,here'showexactlythisshallhappen.
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(applicablethefirsttimeinblock
M+n*1008+2),overwritingtheirowninternalandslightlydifferentvalueBSL_LongTermAvg.
Validation:
ThevalidatingnodereceivingblockM+n*1008+1containingtmp==0xTSScheckswhichvaluefor
(uint12)tmphewouldhavecalculated.
Ifthevaluedeviatesfromthereceivedvaluebynomorethan+/1,theblockisaccepted(the
reasonforadifferenceof+/1couldbedifferentCPUHWimplementationswithroundingeffects).
Otherwiseitisrejected(adifferenceofmorethan+/1cannotbeexplainedbydifferentrounding
effects).
[17of39]
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)beforeaboverealignmentprocedure!
Behaviorofothernodes:(aftervalidation(below)isok)
Othernodesread(uint12)tmpfromblockheaderbits0xTSSofblockH+1=M+n*1008+1005and
calculate
(double)OBR=(double)((uint12)tmp/8192)
andusethisnewvalueOBRfromnowon,overwritingtheirowninternalandslightlydifferentvalue
OBR.NotethatthishappensbeforetheOverbookingIndicatorofblockH+1=M+n*1008+1005
getschecked.TherealignedOBRvalue,OBR(H+1),isfirsttimeusedforblockH+2=
M+n*1008+1006todecidewhetherthisblockH+2isallowedtobeoverbooked.
Validation:
ThevalidatingnodereceivingblockH+1=M+n*1008+1005containingtmp==0xTSSchecks
whichvaluefor(uint12)tmphewouldhavecalculated.
Ifthevaluedeviatesfromthereceivedvaluebynomorethan+/1,theblockisaccepted(the
reasonforadifferenceof+/1couldbedifferentCPUHWimplementationswithroundingeffects).
Otherwiseitisrejected(adifferenceofmorethan+/1cannotbeexplainedbydifferentrounding
effects).
[18of39]
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'sexponentialgranularityresolutiongridofpossiblevotingvalues.
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
[19of39]
4 Rationale
[Rat1]
Q.: DuringtheBIP10Xactivationphase,whyis75%theactivationlimit,andwhyareBIP101
blockscountedby50%asiftheywereminedbyBIP10Xminers?
A.: MinersofBIP101blocksarevotingforablocksizeincreaseschedule,similarlytoBIP10X
miners.ThedifferenceisthattheblocksizeincreasescheduleofBIP10Xislessaggressivethan
thatofBIP101,becauseBIP10X'sgrowthratemaxlimitsaresettobeequaltothefixedgrowth
rateofBIP101(excludingBIP10X's80%minermajorityboostedgrowth,whichisonlymeant
tobeasanemergencyexitifdemandandtechnologyincreasesfasterthanexpected).Also,the
initialblocksizelimitof8MBisatleastbyafactorof2greaterthanthatofBIP10X.
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,andwhyis
therethis504blockoffsettothedifficultyadjustmentblock?
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,weavoidsanypotentialspecialconditionsthatthe
[20of39]
SWmayrunintowhendifferentspecialcasesofdifficultyadjustmentandBSLadjustment
coincide,therebyreducingthenumberofSWscenariostobetested,anddecreasingthe
likelihoodofanunexpectedbugoccurringinrealoperationlateron.Whilethismayseemover
cautious,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:
[...][HavingBIP100'svoteinthecoinbasescriptSig]ismorecomplextoimplement[thanBIP101's
solutiontoonlyhaveamodificationintheheader],because[withBIP100]themaximumallowed
sizeforablockdependsoninformationcontainedincoinbasetransactionsfrompreviousblocks
(whichmaynotbeimmediatelyknownifblockcontentsarebeingfetchedoutoforderina'headers
first'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
[21of39]
[1.21;4.585]*average_Actual_Block_Size?
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%isagood
designvaluetohelpavoidingtheworst.
Fig.41: Networkcongestioneffectsindependenceofhowmuchblocksarefilledrelative
tothemaxblocksize.Diagramtakenfromreference[5].
Abouttheothersideoftheinterval,the4.585:ThisissimplydesignedsuchthatBSLwill
[22of39]
decreaseifactualblockoccupancyfallsbelow20%.Again,theexponentialresolutiongridfor
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%
ofminerscreatereasonablyfilledblocksofsize=0.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)increaseordecreaseofBSLlimitedtoa
factorof1.682(=2^(6/8))bydefinitionoftheBSLvotingbitfieldintheheader,whichonly
rangesfrom1/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
[23of39]
casehavetocreatesmallerblocks.]
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.takingtheaverageofall
votesexceptthetopandbottom20%votes?
A.: Thisappearsfaireronlyatthefirstglance.Infactitwouldbemorepronetomanipulation.For
example,a30%minoritycouldmakeanextremelyhighvote.While20%ofvotesarecutoff,
theremaining10%arestilltakenintoconsiderationintheaveragingprocess,andtherebythe
finalvotewillbecomebiasedtowardstoohighvalues.
Inthenextvotinginterval,someminerswouldtendtomaketacticalvotes:Tocountera
tacticalvoterontheoneedgeshowingextremelyhighvalues,theothersidemightdecideto
voteforextremelylowvalues,withtheintentthatthefinalaverageturnsouttobewhatthey
actuallywant.
Sosuchaveragingrulewouldopenupthevotingprocesstothefieldofgametheoryand
tacticalvoting,whichiscompletelyunnecessary.Because,thequantileruleavoidstactical
votingfromthestart.IfaminerwantstohaveaBSLofsay10MB,thebesthecandoistovote
for10MB,nomatterwhattheotherminersdo!Ifmostoftheotherminersvotebelow/above
10MB,hecouldnotoffsetthisbyhimselfvotingwithaparticularly[high/low]votelikee.g.
[100MB/1MB].Itwouldnotchangethefinalquantileselected.Onlyavotingrulebasedon
quantileseliminatestacticalvoting,anditisthereforethefairest,safestandmosttransparent
votingschemepossible.
[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.
Anotherwayofillustratingthelimitationsisasfollows:
[24of39]
Theeffectivewindowlengthoftheexponentialwindowfordeterminingtheaverage
overbookingblockratio(OBR)is114days(mathematicaltermdescribingatwhattimein
thepasttheexponentialaveragingweightwindowhasdecayedto36.8%(=1/e),when
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.
[Rat7b]
Q.: WhyisthecounterincentiveforoverbookingblocksrealizedbyburningTXfees,andnotby
rollingthosefeesovertofutureblocks,asproposedbyMeniRosenfeld[8]?
A.: Therearetworeasons:First,theoverbookingofblocksismeanttobealastresortfeaturethat
isnotusedextensively.Hence,thereisanywaynotalotofTXfeestobelostbytheminer
communityoverall,soitisanoverkilltoimplementarathercomplicatedandnewrollover
mechanismjusttosavetheminerscommunitysomefees.
Secondly,thereisanotherargumentagainstarollovermechanismifwelookatthe
(counter)incentivesituationforthecollectiveminercommunityasawhole:Withrollover
mechanism,allTXfeeswouldeventuallygotothecollectiveminers.Ifallminersfollowedthe
sameoverbookingpolicy,theywouldonaveragejustlooseasmanyTXfeesintheirownblocks
duetooverbookingaswhattheywouldgetbackasrolloverfromotherminers.So,collectively,
thecounterincentiveagainstoverbookingwoulddisappear.
[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.
[25of39]
[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).
Moreover,anexponentialaveragingwindowimplementedthiswayisalwaysaslidingwindow
andthereforeavoidsartifactsoccurringforstepwiseaveraging.
Insummary,themethodiseasytoimplementandtoadapt,easytodimension,anditshows
favorablebehavior.
[Rat9b]
Q.: Andwhyistheexponentialaveragingmethodnotappliedtoactualblocksizeinconstraint
(C1)then,whyistheaverageactualblocksize(aABS)calculatedassimpleaverage(finite
rectangularweightwindow)overthelast1008blocks?
A.: Because(C1)wantstomakesurethattheexplicitminervotesarenotincontradictiontohow
muchtheblocksareactuallyfilled(thelattercouldbeconsideredimplicitvotes).Forthisto
makesense,bothhavetorelatetothesametimeinterval,i.e.tothe1008blocksvotinginterval.
[26of39]
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)
Thethreeparameters189/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_LongTermAvgisinitializedwiththeinitialBSL_curr,
asspecifiedinch.2.2.Asaconsequence,thereferencestarttimeoftheadjustmentisimplicitly
backdatedtoapointintimethatliesoneyearbeforeBIP10Xactivation.Therefore,thefirstBSL
doublingoccursalready1yearafterBIP10Xactivation,butthenevery2yearsafterwards.Thiscan
benicelyseeninthe3rdfigureofsimulation(SIM01)(nextpage).
[27of39]
(SIM01)Inthemaximumgrowthcase,itisassumedthatallvotesaresufficientlyhighorthe
blocksthemselvesaresufficientlyoccupied(actually,onlythelatterissufficient),suchthatthe
actuallimitforBSLgrowthisdeterminedbyconstraint(C2).Simulationstartedwithinitial
conditionBSL_curr=1MBandthenmaximizedgrowthrate.Itcanbeseenthatafairlyconstant
growthrateof+41%peryear(+100%per2years)isachievedfromthebeginning.
Zoomedinforthefirst4years,illustratingdoublingevery2years:
[28of39]
(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)
[29of39]
(SIM03)Simulationsforthegrowthcaseshowadoublinginabitmorethan1year,asintendedby
design.Forexample,after10years(20152025)BSLhasincreasedbyroughlyafactor
2^10=1024,whichcorrespondsto10doublings,i.e.oneperyear,andfurtherdoublingstheyears
after:
Zoomedin:
[30of39]
(SIM04)Simulationsforthedeclinecaseshowahalvingevery4years,asintendedbydesign:
[31of39]
Thefollowingshowsthesituationthatacertainpercentageofblocksgetsthe80%voteboost.For
thesakeofillustration,itisassumedthattheboostoccursinregularintervals,e.g.every3 rdweekin
casethat33.3%ofblocksgetthe80%majorityupvote:
Thefirstofthefollowingtwofiguresillustratesthesituationforthe10%case:Forevery10 thblock,
therelaxedgrowthconstraintsthatareapplicabletothe80%upvoteareapplied,hencetheblock
sizelimitshowspeaks.Forthenineblocksafterwardsthenormalandtighterconstraintsapply,
hencetheblocksizelimitgoesbackdownagain,normallytowhereitwasbeforethepeak.
Notethattheconstraintisappliedrelativetothelongtermaverageblocksizelimit(ca.12year
average),soasinglepeakfromtheboostonlycontributesbyasmallfractiontothelongterm
averageanddoesnotaffectthelongtermgrowthratealot.
However,ifthepeakshappenmoreoften,theywilleventuallyhaveanenduringeffectonlong
termgrowthrate,asisillustratedbythesecondfigurebelow.
Thelastfigureaboveillustratesthesituationincasethatthepercentageofblocksexperiencinga
boostoftheblocksizelimitdueto80%majorityvoteisequalto[0%,10%,20%,33%,50%,
67%,80%,90%,100%]respectively.
[32of39]
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%and80%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)
1008blocksinitialvotinginterval
1008blocksnormalvotinginterval
2016..3023blocksgraceperiodlength
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
25%=fractionofexcessTXfeestobeburnedforoverbookedblocks.
[33of39]
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)
[34of39]
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
[35of39]
A.3 Simulation Source Code and Simulation Tool

How to Use FreeMat Tool
SimulationsweredoneusingFreeMat4.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.
[36of39]
The Source Code (BSL_change.m)

%
%SimulationforFreeMatv4.0(MatlabclonewithGPLv2license)
%
%Purpose:FindouthowtheBtcoinBlockSizeLimit(BSL)evolveswiththerulesetofBIP10X,in
%thecornercasethatthegrowthordeclinerateisdeterminedbyconstraint(C2)
%ofBIP10X(eitherthenormallimit,orthestretchedlimitof80%minermajority).
%Incaseofgrowth,thiscorrespondstothecasethat>50%(>80%)ofminerscontinually
%voteforsubstantialBlockSizeLimitincrease,orthattheblocksaresufficientlyfull
%ineachoneweekaverageperiod,suchthatotherfactorsdonotlimitthegrowth.
%Infact,iftheblocksaresufficientlyfull,thiswouldalreadybeenoughtocausethis
%"50%votelike"BSLincrease,irrespectiveoftheactualminervotes.
%Incaseofdecline,thiscorrespondstothecasethat>50%(>80%)ofminerscontinually
%voteforsubstantialBlockSizeLimitdecrease,orthattheblocksaresufficiently
%emptyinaoneweekaverageperiod,suchthatotherfactorsdonotlimitthedecline.
%Infact,iftheblocksaresufficientlyempty,thiswouldalreadybeenoughtocausea
%"50%votelike"BSLdecline,irrespectiveoftheactualminervotes.
%
%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=5;%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;%Initialvalueoftheblocksizelimit,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:
probability_80percent_boost=0.0;%probabilitythataBSLincreaseisboostedby>80%minervote
%Followingpatternisfollowedcyclically,onestepperweek.Ifvalue<>0,boostconditionismet:
pattern_80percent_boost=[00000000000000000000];
%RandomEvent2:Stayonestepawayfrommaxgrowth/declinevalue:
probability_one_step_less=0.0;%probabilitythatBSLadjustmentismodifiedasfollows:
%BSLisonestepsmaller(incaseofgrowth)orhigher(incaseofdecline)ontheBSEresolution
%gridthanwhatitwouldotherwisebe.
%Followingpatternisruncyclically,1stepp.wk.Ifvalue<>0,condition"onestepless"ismet:
pattern_one_step_less=[00000000000000000000];
%PlotScreenSizemodifyindependenceofyourmonitor'sresolution:
plot_window_width=900;
plot_window_height=360;
%
%%#1)Initializations:
BSE=max(0,min(127,floor(8*log(BSL_init_MB+eps)/log(2))));%blocksizeexponent,0..127
N=round(NbYrs*52/time_warp_hash_speedup_factor);%nbof1008blockperiods(~weeks).
BSL_vector(1:52)=2^(BSE/8)*1e6;%[inMByte]InitialisetheBSLvalueforthefirst52weeks
BSL_vector=[BSL_vector,nan*ones(1,N)];
%InitializeBSL_LongTermAvgonlyneededifaveraging_method='forgetting_factor':
BSL_LongTermAvg=BSL_init_MB*1e6;
%
%%#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
%Determinewhichlongtermchangeconstraintapplies:
ifrand()<probability_80percent_boost,
incmax=incmax_yearAvg2;%boostedgrowthby>80%minervote
else
incmax=incmax_yearAvg;%normalcase
end
ifpattern_80percent_boost(1+mod(k52,length(pattern_80percent_boost))),
incmax=incmax_yearAvg2;%boostedgrowthby>80%minervote
end
BSE_last=BSE;
%CalculatenextBSLforweekk,assumingminervoteandactualblocksizeswereprogressive:
if(floor(2^(BSE/8)*1e6))>BSL_LongTermAvg*incmax,%iscurrentBSL>currentconstaint?
BSE=floor(8*log((BSL_LongTermAvg)/1e6)/log(2));
end
%Trytogoupasmuchaspossible,butdon'tgomorethan6stepsupfromlasttime:
while((floor(2^((BSE+1)/8)*1e6))<=BSL_LongTermAvg*incmax)&&(BSE+1<=BSE_last+6),
BSE=BSE+1;
end
if(rand()<probability_one_step_less)...
||pattern_one_step_less(1+mod(k52,length(pattern_one_step_less))),
%Arandomeventcausesthegrowthtobenotquiteasbigasitcouldbe:
BSE=BSE1;
end
BSL_vector(k)=floor(2^(BSE/8)*1e6);
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+...
[37of39]
(1forgetting_factor)*BSL_vector(k1);
else
disp('ERROR:Invalidvalueforparameter"averaging_method"!')
return;
end
%Determinewhichlongtermchangeconstraintapplies:
ifrand()<probability_80percent_boost,
decmin=decmin_yearAvg2;%boosteddeclineby>80%minervote
else
decmin=decmin_yearAvg;%normalcase
end
ifpattern_80percent_boost(1+mod(k52,length(pattern_80percent_boost))),
decmin=decmin_yearAvg2;%boosteddeclineby>80%minervote
end
BSE_last=BSE;
%CalculatenextBSLforweekk,assumingminervoteandactualblocksizeswerelow:
if(floor(2^(BSE/8)*1e6))<BSL_LongTermAvg*decmin,%iscurrentBSL<currentconstaint?
BSE=floor(8*log((BSL_LongTermAvg)/1e6)/log(2))+1;
end
%Trytogodownasmuchaspossible,butdon'tgomorethan6stepsdownfromlasttime:
while((floor(2^((BSE1)/8)*1e6))>=BSL_LongTermAvg*decmin)&&(BSE1>=BSE_last6),
BSE=BSE1;
end
if(rand()<probability_one_step_less)...
||pattern_one_step_less(1+mod(k52,length(pattern_one_step_less))),
%Arandomeventcausesthegrowthtobenotquiteasbigasitcouldbe:
BSE=BSE+1;
end
BSL_vector(k)=floor(2^(BSE/8)*1e6);
%keyboard
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/1e6);
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')])
[38of39]
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
[7]
BIP1xxDynamicallyControlledBitcoinBlockSizeMaxCapbyUpalChakraborty
https://github.com/UpalChakraborty/bips/blob/master/BIP
DynamicMaxBlockSize.mediawiki
[8]
ElasticblockcapwithrolloverpenaltiesbyMeniRosenfeld
https://bitcointalk.org/index.php?topic=1078521.0
[39of39]

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

Uploaded by

Copyright:

Available Formats

You might also like

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

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Version0.

Terms, Abbreviations and Symbols

1 Overview of Main Characteristics of BIP10X

1.1 Introduction Schedule

2.2 Details of the Three Phases

Grace Period (Starting with Block N)

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)

You might also like