Академический Документы
Профессиональный Документы
Культура Документы
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)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Version History
v0.1 30August2015
v0.2 5September2015
Firstversion
Additionalsimulationsadded,sourcecodeupdated,morerationales,
cleanupsoftypos,minoreditorialchanges
Themeasureofintelligenceistheabilitytochange.
AlbertEinstein
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[2of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Acknowledgements
TheauthorexpressivelyacknowledgesallcontributionsthathavebeenmadeonBlockSizeLimit
evolution,beitintheformofBIPs,otherwriteups,orbypostsindifferentforums.
Allopenandpragmaticdiscussionshelpedtogetmoreandmoreinsights,leadingtothisproposal,
whichunderwentmanyiterationsbeforeitsfirstrelease.
ThisBIP10Xproposalwouldnothavebeenpossiblewithouttheearlierworkandinspirationsfrom
othercommunitymembersandcanbeseenasanaturalevolutioninthecommunity'sendeavorto
findthebestpossiblesolution.
ThegreatestacknowledgementgoestoeachindividualdeveloperwhocontributedtotheBitcoin
softwaresince2009.Withouttheirefforts,wewouldnotbeinthepositiontoholdthisdiscussion
today.
Foryouracknowledgement
Apersonwhonevermadeamistakenevertriedanythingnew.
AlbertEinstein
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[3of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[4of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[5of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[6of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[7of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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).
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[8of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
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).
7. Thegraceperiodisoverwhenpropervotingstartsatblock
M.BlockMistheblockthat
fulfillstwoconditions:Firstitmustlieona1008blockgridwhichisoffsetby504blocksto
the2016blockdifficultyadjustmentgrid.Secondlyitsblockheightmustfulfillthecondition
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[9of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
2016MN3023,
whereblock
Nistheblockwhentheactivationconditionwasmet[Rat2].
BlockMisthefirstblockoftheoperationalphase.
504 blocks
ca. 1 week
Start voting
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
Block M+n*1008, n>1: First block with new BSL after adjustment
Fig.21: HowBIP10Xbecomesactivatedandoperational.
Note:HereblockMoccurs504blocksbeforeadifficultyadjustment.Acc.to
BIP10Xitcouldequallywelloccur504blocksafteradifficultyadjustment
(dependsonwhenactivationconditions[=blockN]isachieved).
[10of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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]:
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[11of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
resolutiongriduntilitbecomes110/128*BSL_LongTermAvg.
IfvBSL_20i>247/128*BSL_LongTermAvg,thenreducevBSL_20iontheBSE
resolutiongriduntilitbecomes247/128*BSL_LongTermAvg.
IfvBSL_80d<98/128*BSL_LongTermAvg,thenincreasevBSL_80dontheBSE
resolutiongriduntilitbecomes98/128*BSL_LongTermAvg.
(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.
Bytenumber=3210
0x20VTSS0B=00100000vvvvttttssssssss00001011
=0x200xVT0xSS0x0B
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[12of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[13of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(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=0110=6voteforBSLthatisbyfactor2^(6/8)1.6818abovecurrentBSL
0xV
{
8,7,+7}:Overbookingindication=ON=1(i.e.thisblock'ssizeis>BSL_curr)
Specialmapping(lookuptable)asfollows:
0xV=1000=8voteforBSLthatissameascurrentBSL
0xV=1001=7voteforBSLthatisbyfactor2^(3/8)1.2968abovecurrentBSL
0xV=0111=7voteforBSLthatisbyfactor2^(6/8)1.6818abovecurrentBSL
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]
[14of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
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))
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[15of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Theamountofsatoshistobedestroyedis=ceil(total_tx_fees*factor).
ThismeansthatminerswillonlycreateblocksgreaterthanthecurrentnominalBSLiftheyreally
seeanoverallbenefit(e.g.usersatisfactionbitcoinpriceminingprofits).
(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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[16of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(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).
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[17of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[18of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[19of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[20of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[21of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
[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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[22of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[23of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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:
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[24of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[25of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
[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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[26of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
110/128*BSL_LongTermAvg=0.8593750*BSL_LongTermAvg
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).
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[27of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(SIM01)Inthemaximumgrowthcase,itisassumedthatallvotesaresufficientlyhighorthe
blocksthemselvesaresufficientlyoccupied(actually,onlythelatterissufficient),suchthatthe
actuallimitforBSLgrowthisdeterminedbyconstraint(C2).Simulationstartedwithinitial
conditionBSL_curr=1MBandthenmaximizedgrowthrate.Itcanbeseenthatafairlyconstant
growthrateof+41%peryear(+100%per2years)isachievedfromthebeginning.
Zoomedinforthefirst4years,illustratingdoublingevery2years:
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[28of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(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
247/128*BSL_LongTermAvg=1.9296875*BSL_LongTermAvg
andabove
98/128*BSL_LongTermAvg=0.7656250*BSL_LongTermAvg
Theeffectisshowninthefollowingsimulations:
(Inthesimulationscript,wesettheparameterrandom_80percent_boost=1.0)
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[29of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(SIM03)Simulationsforthegrowthcaseshowadoublinginabitmorethan1year,asintendedby
design.Forexample,after10years(20152025)BSLhasincreasedbyroughlyafactor
2^10=1024,whichcorrespondsto10doublings,i.e.oneperyear,andfurtherdoublingstheyears
after:
Zoomedin:
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[30of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(SIM04)Simulationsforthedeclinecaseshowahalvingevery4years,asintendedbydesign:
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[31of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[32of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[33of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[34of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[35of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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.
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[36of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[37of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
(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'])
sizefig(plot_window_width,plot_window_height)
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')])
sizefig(plot_window_width,plot_window_height)
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[38of39]
Version0.2(5September2015)
byMichael_S(bitcointalk.org)
OpenPGPKeyID=0xCC7E7C99
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
Support,Respect,Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD
[39of39]