A Hybrid Mechanism for Adaptively Adjusting Bitcoin's Block Size Limit [BIP10X]

Version 0.2 (5 September 2015) by Michael_S (bitcointalk.org) OpenPGP KeyID=0xCC7E7C99

A Hybrid Mechanism for AdaptivelyAdjusting Bitcoin's Block Size Limit

[BIP10X]

AbstractMany proposals have been made for the future evolution of Bitcoin's Block Size Limit (BSL). Some suggest simply lifting the hard limit to a higher value but keeping it fixed [3] (BIP102), while otherspropose a hardcoded fixed growth rate [2, 4] (BIP101, BIP103). Again others propose a BSL adjustment (up or down) exclusively based on miner voting [1] (BIP100). Finally, certain proposals favor an autoadaptation (up or down) based on the actual size of the recent blocks [7].Current Bitcoin protocol does not contain any of these features, in particular it does not contain anyminer voting mechanism. Nevertheless, a miner voting about future Block Size Limit is defacto implicitly done at that moment when an alternative Bitcoin implementation like BIP100 or BIP101 [1, 2] gets deployed. This means, a miner voting can be imposed any time, even if not foreseen by the current Bitcoin software.BIP100 [1] proposes a miner voting mechanism for the Block Size Limit (BSL) builtinto the Bitcoin protocol. This “institutionalizes” a block size limit voting mechanism as a normal process within the rules of the Bitcoin protocol. This can be seen as an alternative to the “noninstitutionalized” defacto voting that takes place when deploying alternative Bitcoin fork implementations competing for a miner majority. An institutionalized voting on BSL that is builtin to the protocol itself is a strong counterincentive to deploying other hard forks to be activated by miner voting (if these hardforks are about block size limit), because miners could equally well just cast their vote within the mechanisms of the current protocol itself. This would calm down future discussions about hardforks in the community and would allow refocussing on other important issues, of which there are many.However, BIP100 [1] is not very concrete in all details (e.g. unclear definition of vote majority, possibly a 20% minority can quickly force BSL down) and has disadvantages by solely relying on miner votes and by allowing excessive annual BSL change rates in both directions. It has been criticized that miners (and possibly miner minorities) would have too much unconstrained power. On the other hand, BIP101 [2], the second of the m ost popular proposals, has a fixed growth rate that makes an assumption on future evolution of Bitcoin traffic and bandwidth technology over decades, which cannot hardly be predicted, and is therefore criticized as too inflexible.This BIP10X proposal takes all ideas of all the above proposals into consideration and adds new ideas, thereby providing a novel solution that promotes the advantages and eliminates the main drawbacks of each individual proposal seen so far, particularly BIP100 and BIP101. It provides flexibility, fairness, adaptability and planning security.Here, Block Size Limit (BSL) is usually determined by miner votes, but restricted and overruled by constraints. Miner voting is only possible within certain limits. These limits are the longterm change rate of the block size limit itself as well as the actual block size, such that e.g. miners cannot arbitrarily “vote up” the Block Size Limit (BSL) when the average actual block size falls behind. The proposal also incorporates a condition to boost BSL change rate by relaxing constraints when supported by a huge miner supermajority. Moreover, another mechanism copes with temporary high network load, to allow a possibility for shortterm reactions to minimize user dissatisfaction.This thoroughly thought trough proposal is concrete, complete and detailed on all algorithm, function and protocol specification aspects. Careful selection of parameters and default configuration file settings has been carried out and a rationale is given for each decision. Simulations were performed (source code provided) to ensure appropriate behavior in agreement with the intentions of the design.

Support, Respect, Appreciation: 1MichaS16UMKFgNjanKrtfD51HpBkqPAwD [1 of 39]


Version Historyv0.1 30 August 2015 First versionv0.2 5 September 2015 Additional simulations added, source code updated, more rationales,

cleanups of typos, minor editorial changes

“The measure of intelligence is the ability to change.”– Albert Einstein –



AcknowledgementsThe author expressively acknowledges all contributions that have been made on Block Size Limit evolution, be it in the form of BIPs, other writeups, or by posts in different forums.All open and pragmatic discussions helped to get more and more insights, leading to this proposal, which underwent many iterations before its first release.This BIP10X proposal would not have been possible without the earlier work and inspirations from other community members and can be seen as a natural evolution in the community's endeavor to find the best possible solution.

The greatest acknowledgement goes to each individual developer who contributed to the Bitcoin software since 2009. Without their efforts, we would not be in the position to hold this discussion today.

For your acknowledgement

“A person who never made a mistake never tried anything new.”– Albert Einstein –



Contents

Terms, Abbreviations and Symbols......................................................................................................5

1 Overview of Main Characteristics of BIP10X..................................................................................71.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



Terms, Abbreviations and Symbols

aABS avg. ABS of the last 1008 blocks, calculated at the end of a BSL voting intervalABS Actual Block Size of a blockActivation Phase The time before BIP10X's 75% supermajority is achieved, i.e. until block N1.BSL Block Size LimitBSL_LongTermAvg This is the longterm exponential average (62.5 weeks “eff. window length”) of

the Block Size Limit BSL_curr. It gets updated once every 1008 blocks (1 week).

BSE Block Size Exponent: An integer k 0 in BSE format represents the number2^(k/8) and a block size (limit) of 2^(k/8)*1,000,000 bytes, i.e. k=0..127represents sizes ranging from 1 MB to 60.1 GB in increments of 9.05%.

“BSE resolution This is the grid of 128 distinct numbers that BSL_curr has to lie on. Due togrid” the fact that BSL_curr is expressed by an exponent in BSE format, it can only

assume values on a given logarithmic “BSE resolution grid”, mapping to the BSEexponents 0..127.Any two successive values differ by a factor 2^(1/8) 1.0905.

BSL_curr Current nominal BSL – the BSL applicable for the current block. It remainsunchanged for 1008 blocks (=voting interval).

BTC bitcoins (currency unit)ceil(x) = x rounded up to nearest full integer“Effective Mathematical expression for the length in time that an exponential averagingwindow length” window needs to reach back in time until the averaging weight has decayed

to 36.8% (=1/e) of the weight at the present time (see also “forgetting factor”).floor(x) = x rounded down to nearest full integerForgetting factor Averaging parameter in range [0..1) for exponential time averaging of any

kind of value that changes with time (or event count). The general equation is:valueAvg(k) = forgettingFactor*valueAvg(k1) + (1forgettingFactor)*valueNewA value of forgettingFactor=0 means that no averaging is done at all.

Grace Period Starts with BIP10X supermajority achievement (block N) until one block beforestarting mining using BIP10X rules (i.e. until block M1).

M Block height of first block being mined acc. to BIP10X rules, M = N + delta,with delta {2016..3023}. M is 504 blocks away from the nearest difficultyadjustment.

MSB Most significant bitN Block height of the block that achieves BIP10X activation conditionOBR Overbooked Blocks Ratio [0.0..0.3]: Fraction of recent overbooked blocks,

based on longterm exponential averaging with effective window length of114 days. It gets updated every block.

Operational Phase Starts with the first block mined acc. to BIP10X rules (block M), with BSL voteincluded in the block header.

Overbooked block This is a block with size greater than the current nominal block size limitBSL_curr. It is by a factor of up to 4 greater than BSL_curr.

Overbooking The method of creating overbooked blocks.rBSE “Relative Block Size Exponent” format specifies a number relative to BSL_curr. A

miner's vote is specified in rBSE format as a value relative to BSL_curr, keepingthe BSE resolution grid.

SW SoftwareTPS Transactions per second



TX Bitcoin transactionvBSL_50 The 50%ile (=median) vote of the miners' votes from the last voting interval. It

is the “main” vote that usually determines the new BSL.

vBSL_20i The 20%ile vote of the last voting interval. By definition it is vBSL_50, but ifvBSL_20i indicates a BSL increase, it will meet less strict constraints for longterm increase than vBSL_50. Hence, even if smaller than vBSL_50 before theconstraints, it can be greater than vBSL_50 after the constraints. It can thereforespeedup BSL growth if there is substantial (80%) miner support.

vBSL_80d The 80%ile vote of the last voting interval. By definition it is vBSL_50, but ifvBSL_80d indicates a BSL decrease, it will meet less strict constraints for longterm decrease than vBSL_50. Hence BSL decline can speedup if there issubstantial (80%) miner support.

Vote An expression of a miner's preferred BSL, indicated in the header's versionnumber field of a block. The votes have a granularity of 9.05% step incrementsacc. to the BSE format.

Voting interval An interval of 1008 blocks, from block M+n*1008 to M+n*1008+1007, n 0.



1 Overview of Main Characteristics of BIP10X

For many items of this specification, the detailed rationale is explained in separate chapter 4. To ease reading, a reference like “[Rat1]” points to the respective item in that chapter.

Miner voting mechanisms and main BIP10X characteristics are summarized as follows:

• Activation when achieving a 75% supermajority [Rat1]◦ During activation phase, BIP101 miners are taken into account in a reasonable way

• 23 week transitional grace period to allow miners update from legacy or BIP101 to BIP10X.• Adjustment interval for block size limit = 1008 blocks = 1 week = ½ difficulty adjustment

interval, permanently offset by 504 blocks to difficulty adjustment interval. [Rat2]• All voting info and some further BIP10X specific info is in the block header, making use of

largely unused 32bit space in the version number field. [Rat3]• Block Size Limit range is 1 MB to 60.1 GB, with granularity in step increments of 9.05%

[Rat3]• A special block size vote can be configured which says “voting for the next block size limit to

be equal to the current block size limit”.• A special block size vote can be configured which says “voting for the next block size limit to

be equal to someFactor times the actual block size”.• Block size limit decision based on median (50% quantile) [Rat6] of all votes to avoid

manipulation by a miner minority in up or down direction and to prevent tactical voting.• Miner votes do not have total power over block size limit evolution – the block size limit

adjustment is constrained by:◦ Actual block size of previous week (if actual block size is too far off, miner vote figures

get saturated accordingly)◦ Long term growth rate of block size limit cannot be greater than “2x per 2 years” (which

is the fixed rate of BIP101) or “0.5x per 8 years”.▪ Except in case of >80% voting majority: Then the growth rate limits are stretched to

“2x per 1 year” or “0.5x per 4 years”.◦ The very first block size limit votes (those of the first 1008 blocks) are not restricted by

above constraints, but are free votes only constrained by the absolute limits [1 MB ; 4 MB]. 80% majority (i.e. 20% quantile) is used for this initial voting. [Rat6]

• Block “overbooking” in case of temporary high TX load (up to 4x nominal Block Size Limit), but not permanently and with counterincentives [Rat7].

• Two additional configuration parameters for “bitcoin.conf”.



More information on the rules for block size limit evolution:

◦ Upon any circumstances, from one week to the next, block size limit can never in or decrease by more than a factor of 1.682. In practice, weekly change rate will be much lower due to other constraints. [Rat5]

◦ Upon any circumstances, the absolute limits for the block size limit are [1 MB ; 60.1 GB]. However, the protocol has taken precautions (a reserved bit) for a very simple increase of max. block size limit to 3939 TB, which corresponds to >1 transaction per second per person for a world population of 10 Billion people. This makes the protocol verylongterm futuresafe.

◦ If blocks are moderately occupied on average, then miners decide (median=50%quantile of1008 blocks' 1 week's votes) by how much block size limit will be increased or decreased, whereas max. longterm growth is strictly limited to …

• … +41%/8% p.a. (=factor 2x in 2 resp. 8 years).

Only in case of miner majority >80% (of 1008 blocks' 1 week's votes), longtermgrowth rate can be doubled to a max/min of …

• … +100%/16% p.a. (=factor 2x in 1 resp. 4 years).◦ If actual blocks are filled by >90% on average, block size limit will increase longterm by

+41% p.a., even if 100% of miners vote in opposite direction [Rat4]. Of course, a vote majority of >80% in the same direction can further increase growth rate to avg. +100% p.a.

◦ If actual blocks are filled by <20% on average, block size limit will decrease longterm by8% p.a., even if 100% of miners vote in opposite direction [Rat4]. Of course, a vote majority of >80% in the same direction can further increase decline rate to avg. 16% p.a.

◦ The block size limit (BSL) is a “nominal value” that must usually be obeyed, i.e. the actual block size (ABS) must not be above that limit. However, under certain circumstances the actual block size is temporarily allowed to exceed the current nominal block size limit (BSL_curr) by up to a factor of 4 [Rat7]. This prevents that a temporary increase in networkload causes a bottle neck in TPS capacity because of the limited block size limit adjustment speed. To ensure that this remains an exception, only a certain percentage of blocks are allowed to exceed the nominal block size limit on the long run, and there is a further counterincentive against such overbooking by that miners are obliged to destroy 25% of the“excess tx fees” (for details see ch. 2.4).

1.1 Introduction ScheduleIt is proposed to implement and test this BIP10X, and then to deploy it swiftly to the network.In the meantime, if there should be a need for larger blocks before this has been accomplished, it is proposed to deploy a hardfork with a simple fixed increase of Block Size Limit to e.g. 2 MB acc. to BIP102, in order to buy some time and avoid harming the Bitcoin ecosystem.



2 Detailed Specification

2.1 Three Phases After BIP10X DeploymentWhen BIP10X software is deployed by a miner, it operates in one out of 3 phases:

• Activation Phase: The first phase. Here BIP10X miners observe the mined blocks to determineif a supermajority for the BIP10X protocol change is achieved.

• Grace Period: Once the activation condition is met, the irrevocable decision is made that block size limit voting acc. to BIP10X will start at a certain time (precisely: certain block height) which lies about 23 weeks in the future. Until then, the BIP10X miners still behave like legacy miners. This transition period is called the Grace Period.

• Operational Phase: Finally, at the given time, BIP10X miners start voting, this is the start of the Operational Phase. 1 week (1008 blocks) later the first block size limit adjustment will take place.The operational phase is divided into the initial and the final operational phase:◦ Initial Operational Phase (first 1008 blocks): Miners vote for the initial BSL that the

protocol should start with, within 1 and 4 MB.◦ Final Operational Phase: Normal operation with regular BSL adjustment every 1008

blocks, based on miner votes and various constraints.

2.2 Details of the Three Phases

Activation Phase

1. No earliest start date is specified, neither in terms of date & time, nor in terms of block height. Instead, activation phase starts as soon as the BIP10X miner starts up.

2. Blocks mined by BIP10X clients are identified by a new version number “0x2000000B“.

3. The activation condition is met if 75% of the previous 1008 blocks (1 week), i.e. 756 blocks, are counted as BIP10X compliant. The condition is checked every new block. [Rat1]

4. 50% of the blocks mined by BIP101 clients (version number 0x20000007) are counted as BIP10X mined blocks (rounded down to full integer), while the remaining BIP101 blocks arecounted as legacy blocks. This means that every second BIP101 block helps to trigger the BIP10X activation condition. Note that these rules imply that the activation condition cannotbe met unless at least 50% of the blocks are proper BIP10X blocks. [Rat1]

5. When the activation condition is met with the appearance of block N, the grace period starts (see Fig.21 below).

Grace Period (Starting with Block N)

6. The grace period is between 2016 and 3023 blocks long, depending on where block N is located on the 504blockgrid that is aligned with the 2016difficultyadjustmentgrid, see Fig. 21 below.During this grace period, the BIP10X miner still behaves like a legacy miner, except that it sends the version number 0x2000000B.

7. The grace period is over when proper voting starts at block M. Block M is the block that fulfills two conditions: First it must lie on a 1008block grid which is offset by 504 blocks to the 2016block difficulty adjustment grid. Secondly its block height must fulfill the condition



2016 M N 3023,

where block N is the block when the activation condition was met [Rat2].Block M is the first block of the operational phase.

Fig.21: How BIP10X becomes activated and operational.Note: Here block M occurs 504 blocks before a difficulty adjustment. Acc. to BIP10X it could equally well occur 504 blocks after a difficulty adjustment (depends on when activation conditions [=block N] is achieved).

Operational Phase (Starting with Block M)

Voting procedure:8. The 32bit version number in the block header now has the form “0x20VTSS0B”. This field

always contains the miner's BSL vote and the “overbooking indication”. Also the current BSL (BSL_curr) is usually included, and sometimes the Overbooked Blocks Ratio (OBR) or the longterm average of BSL_curr (BSL_LongTermAvg) is included.The details of how these data are encoded to this version number header field is specified in chapter “2.3 Version Number Field of BIP10X”.

9. Note that every BIP10X block is a vote. Not voting is not possible. Voting strategy depends on the setting of parameter “blocksizelimitvote” in bitcoin.conf. It is possible to set up the miner such that it always votes for the current BSL to be kept, or that it votes for a fixed BSL value, or that it votes for a value that is by a specified factor greater than the average actual block size of the previous 1008blocklong voting interval.

10. Legacy miners (as well as BIP101 miners that behave like legacy miners) can still participate


1008 blocksBSL

votinginterval

504 blocks

504 blocks time grid

2016 blocks difficulty adjustment interval

BIP10X activation condition met any

time here

Start voting First BIP10X BSL adjustment

BIP10X initial BSL setting

Between 2016 and 3023 blocks grace period(2-3 weeks)

Activation Phase

Grace Period Operational Phase

Block N

Block M Block M+n*1008, n>1: First block with new BSL after adjustment

Next BIP10X BSL adjustment

1008 blocksBSL

votinginterval

Special voting for initial BSL

(blocksM .. M+1007)

ca. 1 week

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


and create valid blocks until block M+1007. After that, their blocks will not be accepted by BIP10X miners any more because of the different version number and missing votes.

Vote evaluation and Block Size Limit adjustment. The following takes place exactly once every 1008blocks, i.e. always after block M+n*10081 appears, n :

11. First, here are the special rules for nonBIP10X blocks (those with version different from 0x20VTSS0B) during the “initial operational phase” until block M+1007 (see Fig. 21):• Blocks containing BIP101 version number (0x20000007) are counted like BIP10X blocks

that are voting for 4MB. The reason for this is that the vote in this initial phase should not be biased too much towards small block sizes, just because some BIP101 miners havemissed switching to BIP10X in time.

• Blocks with a version number other then BIP101 or BIP10X, i.e. socalled “legacy blocks”,are ignored for BSL voting, such that 100% of votes after the 1008 block initial voting interval corresponds to less than 1008 votes. The 80% threshold (20% quantile) is then accordingly referring to this smaller absolute number of votes.

12. When reading another miner's block, only the two center bytes of the version number (i.e. “0xVTSS”) are of relevance, since they contain BIP10X specific infos like the vote. The other two bytes are of no relevance for the SW's behavior (except the special treatments in the “initial operational phase” acc. to previous item).

13. Votes are evaluated every 1008 blocks (1 week), always after a block M+n*10081 has been mined, with n . [Rat2]

14. Based on the 1008 votes, three quantiles are calculated and assigned to 64 bit double precision variables (52 bit mantissa), respectively:vBSL_50: The 50% (=floor(0.50*1008) = 504) of smallest BSL votes are discarded, and the smallest of the remaining votes is assigned to vBSL_50. This is the median or 50% quantile ofall 1008 valid BSL votes.vBSL_20i: The 20% (=floor(0.20*1008)=201) of smallest BSL votes are discarded, and the smallest of the remaining votes is assigned to vBSL_20i (20% quantile).vBSL_80d: The 80% (=floor(0.80*1008)=806) of smallest BSL votes are discarded, and the smallest of the remaining votes is assigned to vBSL_80d (80% quantile).Note: The values vBSL_50, vBSL_20i and vBSL_80d are already lying on the “BSE resolution grid” (compare ch. 2.3, format specification for “0xSS”).

15. Finally, the update of BSL_curr will be calculated by successively applying certain constraints(min/max functions). Then the final nominal block size limit BSL_curr applicable for the next 1008 blocks (M+n*1008 to M+n*1008+1007) will be known.The constraints are applied in the following order (i.e. later constraints in this list may overrule earlier ones):• (C0) This constraint is ONLY calculated once, namely exactly after block M+1007 has

been mined, i.e. at the end of the “initial operational phase”. This constraint setsBSL_curr = min(BSL_20i, 4 MB).

Then initialize the longterm averaged BSL as follows:BSL_LongTermAvg = BSL_curr.

The following 2 constraints, (C1) and (C2), as well as the remaining steps (F) and (L), are skipped, but only for this single time! For all the future, (C0) is never executed again and instead steps (C1), (C2), (F) and (L) are executed in sequence.

• (C1) The various quantiles of BSL vote will be constrained by the actual block sizes of the previous 1008 blocks. For this, calculate average Actual Block Size, aABS, of the last 1008 blocks. Then apply min/max limits to force the value into the interval

[39704/32768*aABS ; 150244/32768*aABS] [1.21*aABS ; 4.59*aABS]:



Constraining vBSL_50:Force vBSL_50 into the interval [39704/32768*aABS ; 150244/32768*aABS] while keeping it on the “BSE resolution grid”.

Constraining vBSL_20i:If vBSL_20i BSL_curr, then force vBSL_20i into the interval [39704/32768*aABS ; 150244/32768*aABS] while keeping it on the “BSE resolution grid”.

Constraining vBSL_80d:

If vBSL_80d BSL_curr, then force vBSL_80d into the interval [39704/32768*aABS ; 150244/32768*aABS] while keeping it on the “BSE resolution grid”.

• (C2) The longterm change rate of BSL_curr is limited to +41%/8% p.a. under “normal voting conditions” and to +100%/16% p.a. for “extreme voting conditions” with more than 80% consensus. This is achieved by following algorithm:◦ If vBSL_50 > 189/128*BSL_LongTermAvg, then reduce vBSL_50 on the BSE

resolution grid until it becomes 189/128*BSL_LongTermAvg.

Elseif vBSL_50 < 110/128*BSL_LongTermAvg , then increase vBSL_50 on the BSE resolution grid until it becomes 110/128*BSL_LongTermAvg.

◦ If vBSL_20i > 247/128*BSL_LongTermAvg, then reduce vBSL_20i on the BSE resolution grid until it becomes 247/128*BSL_LongTermAvg.

◦ If vBSL_80d < 98/128*BSL_LongTermAvg, then increase vBSL_80d on the BSE resolution grid until it becomes 98/128*BSL_LongTermAvg.

• (F) Finally, calculate the new BSL as follows:◦ If vBSL_20i > BSL_curr, then BSL_curr = max(vBSL_20i, vBSL_50)◦ Elseif vBSL_80d < BSL_curr, then BSL_curr = min(vBSL_80d, vBSL_50)◦ Else BSL_curr = vBSL_50

• (L) Last step: Now that the new block size limit BSL_curr is finally known, the longterm average value BSL_LongTermAvg gets updated as follows:

BSL_LongTermAvg = 32244/32768*BSL_LongTermAvg + 524/32768*BSL_curr.(all 64bit double precision types)

(Note: 32244/32768 0.984; 524/32768 10.984 = 0.016)

Note: This filtering with forgetting factor 0.984 realizes an exponential averaging window with an “effective length” of 62.5 weeks.Note: BSL_LongTermAvg is a value in units of bytes with full accuracy.

2.3 Version Number Field of BIP10X

Writing Version Number Field to Block Header

The 32bit version number field of blocks mined with BIP10X is constructed as follows:(meaning of letters: S=blockSizelimit, V=Vote, T=exTension)

Byte number = 3 2 1 0

0x20VTSS0B = 0010 0000 vvvv tttt ssss ssss 0000 1011

= 0x20 0xVT 0xSS 0x0B



The bits are defined somewhat differently for the different phases (compare Fig.21):

(1) Activation Phase and Grace Period, for all blocks M1 :

0xVT = 0x000xSS = 0x00

(2) Initial Operational Phase, initial voting interval, for all blocks M up to M+1007 :

0xVT = The initial vote in BSE format, i.e. 0xVT = 0..16 corresponding to vote= 1 MB .. 4 MB = 2^(0xVT/8) * 1 MB.

0xSS = 0x00(3) Final Operational Phase, for all blocks M+1008 :

0xV = BSL vote in “rBSE format” relative to BSL_curr, andoverbooking indication, as specified below.

(3a) All blocks except (3b) and (3c):0xT = 0x0

0xSS = BSL_curr in BSE format (value 0..127 1→ MB .. 60.1 GB), see below, i.e. the block size limit applicable to this block.

(3b) 2nd block of a voting interval, i.e. block height M+n*1008+1, n ):

0xTSS = uint12 carrying BSL_LongTermAvg as binary fractional number, see below for the format and see ch. 2.3 for the meaning of BSL_LongTermAvg.

(3c) Third last block of a voting interval, i.e. block height = M+n*1008+1005, n ):

0xTSS = uint12 carrying the value of OBR as binary fractional number, see below for the format and see ch. 2.4 for the meaning of OBR.

Format Specification:

(3a)→ Format of 0xSS (current BSL, BSL_curr):0xSS is uint8, used range is {0..127} (MSB=0 [reserved for future use]).

The “block size exponent” (BSE) format used for specifying BSL_curr in 0xSS has the following format [Rat3]:BSL_curr = floor(2^(0xSS / 8) * 1,000,000) bytesExamples:0xSS = 0 → BSL_curr = 1,000,000 bytes = 1 MB0xSS = 1 → BSL_curr = 1,090,507 bytes0xSS = 25 → BSL_curr = 8,724,061 bytes...

0xSS = 127 → BSL_curr = 60,096,776,975 bytes GB

Range of 0xSS: 0..127: Regular values. 128..255: Reserved for future use (would support block sizes up to 3939 TB).

Note that these values have a granularity of upincrements of 9.05% (or downincrements of 8.30%). BSL_curr is one out of a set of 128 distinct numbers that is referred to as the “BSE resolution grid”.



(3)→ Format of 0xV (the miner's BSL vote and overbooking indication):0xV is interpreted as signed int4, i.e. range {8..+7}.

The BSL vote is expressed relative to BSL_curr (“rBSE format”). The vote lies on the sameBSE resolution grid as BSL_curr [Rat3]:0xV { 6..+6}: Overbooking indication=OFF=0 (i.e. this block's size is BSL_curr)Vote for BSL = floor(2^((0xSS+0xV) / 8) * 1,000,000) bytesExamples:0xV = 1010 = 6 vote for BSL that is by factor 2^(6/8) → 1.6818 below current BSL

...0xV = 0000 = 0 vote for BSL that is same as current BSL→

0xV = 0001 = 1 vote for BSL that is by factor 2^(1/8) → 1.0905 above current BSL

...


0xV { 8, 7, +7}: Overbooking indication=ON=1 (i.e. this block's size is > BSL_curr)Special mapping (lookup table) as follows:0xV = 1000 = 8 vote for BSL that is same as current BSL→



Bitcoin SW shall set the vote to the highest possible value that is smaller or equal towhat is given by blocksizelimitvote (configuration parameter in bitcoin.conf).

Note: See [Rat5] for why the limited voting range [BSL_curr/1.6818 to BSL_curr*1.6818] isnot actually a restriction.

(3b)→ Format of 0xTSS (=BSL_LongTermAvg, see ch. 2.3 for details):0xTSS is uint12, i.e. range {0..+4095}.BSL_LongTermAvg = 0xTSS / 2^11 * BSL_curr, range = [0.0 .. 1.99951172]*BSL_curr

(3c)→ Format of 0xTSS (=Overbooked Blocks Ratio OBR, see ch. 2.4 for details):0xTSS is uint12, i.e. range {0..+4095}.OBR = 0xTSS / 8192, range [0.0 .. 0.49987793]

Reading Version Number Field from Block Header

[after BIP10X activation, block height M]

Bytes 0 and 3 are checked to see if this is a BIP10X block, nonBIP10X blocks are rejected.After the first block with size > 1 MB has occurred, legacy miners (incl. BIP101 miners) can no longermine on this chain, so checking bytes 0 and 3 becomes superfluous. It is proposed that only bytes 1 and 2 are checked for block validation from that point onwards, while bytes 0 and 3 are ignored. In particular, there shall be no check of version number in byte 0 any more.This allows future forks to reuse byte 0 for triggering a future hardfork activation upon the condition that byte 0 0x0B = 00001011.



2.4 Overbooking of Blocks: Block Size > Nominal Block Size Limit

The nominal block size limit, BSL_curr, is basically calculated from weekly miner votes, constrained by a range around the average actual block size of the same voting interval and by BSL_LongTermAvg, which is a roughly 1.2yearaverage (exponential averaging window) of “BSL_curr”. This provides a stable evolution path for the block size limit BSL_curr.As the name says, “block size limit” actually means that a block should not be greater than that limit.However, there can be times at which an unforeseeable load of transactions temporarily hits the Bitcoin network. In this case, it shall be possible to exceed the limit given by BSL_curr to a certain extend. This is what the block size “overbooking” feature is about:• It shall be possible to create blocks in excess of BSL_curr, if the following limits are kept:

◦ The block size shall absolutely never be greater than 4*BSL_curr

◦ The occurrence of overbooked blocks 2*BSL_curr should not exceed a 30% threshold

◦ The occurrence of overbooked blocks > 2*BSL_curr should not exceed the stricter 10% threshold

These requirements are implemented by the following algorithm:

This feature is disabled before block M+1008 and gets enabled with block M+1008, i.e. with the start of the final operational phase.

Part 1: Update of Overbooked Blocks Ratio OBR

• Initialization before mining of block M+1008: Set Overbooked Blocks Ratio OBR = 0.0• If new block arrives: Check if the block's Overbooking Indication (=0(off) or 1(on)) is set.

For a valid block it must be set =1 if blocksize > BSL_curr and must otherwise be set =0.• Update the longterm metric OBR for the ratio of overbooked blocks:

OBR = 16383/16384*OBR + (1/16384)*OverbookingIndication(NewBlock)More precisely, if H is the block height of the new block, then:

OBR(H) = 16383/16384*OBR(H1) + (1/16384)*OverbookingIndication(block(H))

Part 2: Condition When Overbooking is Allowed

If OBR(H) < 0.10 then it is allowed to create a block H+1 with size up to 4*BSL_currElseif OBR(H) < 0.30 then it is allowed to create a block H+1 with size up to 2*BSL_curr

What this means in particular is exemplified in the “rationale” chapter 4 in section [Rat7].

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

The creation of blocks exceeding the nominal BSL (BSL_curr) is further discouraged by imposing a penalty: An overbooked block must destroy 25% of the TX fees that are attributed to transactions exceeding the nominal BSL (BSL_curr) by sending them to the unspendable address

1BitcoinEaterAddressDontSendf59kuE (or another equivalent address t.b.d.)More precisely, the fraction of total TX fees to be destroyed is given by the factor

factor = max(0 ; 0.25*(ABS BSL_curr) / ABS),where ABS is the actual block size of that block.



The amount of satoshis to be destroyed is = ceil(total_tx_fees * factor).This means that miners will only create blocks greater than the current nominal BSL if they really see an overall benefit (e.g. user satisfaction bitcoin price mining profits).→ →

Validation Condition of an Overbooked Block

Let H denote the height of a block.Let OBR(H) denote the OBR as calculated from blocks up to and including block H.Let ABS(H+1) denote the actual block size of block H+1.Let BSL_curr(H+1) denote the BSL applicable to block H+1.

Rule: For a block “H+1” to be valid, both conditions must be true:

• (OBR(H) < 0.1 and ABS(H+1) 4*BSL_curr(H+1)) OR(OBR(H) < 0.3 and ABS(H+1) 2*BSL_curr(H+1))

• TX fees destroyed total_tx_fees * max(0 ; 0.25*(ABS(H+1) BSL_curr(H+1)) / ABS(H+1))

Note: In this equation, OBR is the value calculated BEFORE the block in question was created.This rule is to facilitate implementation:• A node has received blocks 1 to H and calculates OBR(H) from this.• If the node is a miner, it shall make its decision about overbooking block H+1 in dependence of

this value OBR(H).• If the node is a validation node, it shall validate block H+1 based on block size of block H+1

and OBR as calculated up to block H.



2.5 Re-Alignment of Long-Term Averaged Values

There are two points in BIP10X specification where LongTermAveraging takes place:• (double)BSL_LongTermAvg• (double)OBR ( the Overbooked Blocks Ratio)→

These two variables are longterm averages from an exponential window with infinite memory. Thisbears a risk: Since CPU implementations of double precision arithmetic might differ slightly (not to mention CPU bugs like the famous Pentium FDIVBug from 1994), this may cause the longterm averaged values to diverge on different computers in the Bitcoin network, and this may eventually cause an unexpected fork of the blockchain. It would be unexpected, because the “internal state” (inthe sense of the exact value of the longterm averaged value being interpreted as a state variable) would not be known by the other nodes.Hence, it is considered necessary, to “realign” these values regularly amongst all network nodes, such that all nodes periodically start over from exactly the same value (such that they have exactly the same internal “state”).BIP10X specifies a periodic realignment every 1008 blocks, here's how exactly this shall happen.

Re-Alignment of BSL_LongTermAvg

According to ch. 2.3, the longterm averaged BSL, BSL_LongTermAvg, is written to the block header once every 1008 blocks in block M+n*1008+1, n1. By this, the miner doing this task is carrying out a realignment as follows:

Calculation of the miner:Calculate

(uint12)tmp = floor(2^11 * (double)BSL_LongTermAvg / (double)BSL_curr)Note: The ratio of the two (double) values is surely between 0.76 and 1.93, hence tmp isguaranteed to not suffer any overflow).

Write (uint12)tmp to the bits 0xTSS of the new block M+n*1008+1, as of ch. 2.3.

Behavior of other nodes: (after validation (below) is “ok”)Other nodes read (uint12)tmp from block header bits 0xTSS of block M+n*1008+1 and calculate

(double)BSL_LongTermAvg = (double)((uint12)tmp/2^11 * (double)BSL_curr)and use this value BSL_LongTermAvg from now on (applicable the first time in block M+n*1008+2), overwriting their own internal and slightly different value BSL_LongTermAvg.

Validation:The validating node receiving block M+n*1008+1 containing tmp==0xTSS checks which value for(uint12)tmp he would have calculated.If the value deviates from the received value by no more than +/1, the block is accepted (the reason for a difference of +/1 could be different CPU HW implementations with rounding effects).Otherwise it is rejected (a difference of more than +/1 cannot be explained by different rounding effects).



Re-Alignment of Overbooked Blocks Ratio (OBR)

According to ch. 2.3, the Overbooked Blocks Ratio, OBR, is written to the block header once every 1008 blocks in block M+n*1008+1005, n1. The miner that is doing this task is carrying out a realignment as follows:

Calculation of the miner:Calculate

(uint12)tmp = floor((double)OBR*8192),where OBR is the value after block M+n*1008+1004 was fully processed, i.e.OBR = OBR(H), with H=M+n*1008+1004.

Write (uint12)tmp to the bits 0xTSS of the new block M+n*1008+1005, as of ch. 2.3.(!) Note: The decision whether or not to overbook this block H+1= M+n*1008+1005 is made based on OBR(H) before above realignment procedure!

Behavior of other nodes: (after validation (below) is “ok”)Other nodes read (uint12)tmp from block header bits 0xTSS of block H+1 = M+n*1008+1005 andcalculate

(double)OBR = (double)((uint12)tmp/8192)and use this new value OBR from now on, overwriting their own internal and slightly different valueOBR. Note that this happens before the Overbooking Indicator of block H+1= M+n*1008+1005 gets checked. The realigned OBR value, OBR(H+1), is first time used for block H+2 = M+n*1008+1006 to decide whether this block H+2 is allowed to be overbooked.

Validation:The validating node receiving block H+1= M+n*1008+1005 containing tmp==0xTSS checks which value for (uint12)tmp he would have calculated.If the value deviates from the received value by no more than +/1, the block is accepted (the reason for a difference of +/1 could be different CPU HW implementations with rounding effects).Otherwise it is rejected (a difference of more than +/1 cannot be explained by different rounding effects).



3 New Parameters in Bitcoin.conf

Note: For rationale of default parameter choice refer to [Rat8].

# Miner's Block Size Limit vote (BIP10X):

#

# Specify the block size limit (BSL) as a special parameter:

# blocksizelimitvote=0 > “keep current Block Size Limit unchanged”

#

# Specify the block size limit (BSL) in number of bytes, possible values e.g.:

# blocksizelimitvote=1000000 > means 1 MB vote (smallest possible value)

# =8000000 > means 8 MB vote

# =61000000000 > means 61 GB vote

#

# Specify the block size limit (BSL) as multiples of average *actual* block size of last 1008 bocks:

# blocksizelimitvote=1.2a > 1.2 x average actual block size of last 1008 bocks

# blocksizelimitvote=1.7a > 1.7 x average actual block size of last 1008 bocks DEFAULT !



#

# General remark: Actual vote will be <= blocksizelimitvote (up to 8.3% smaller) because of the

# protocol's exponential granularity resolution grid of possible voting values.

blocksizelimitvote=1.7a

# Overbooking strategy of the miner (BIP10X):

# Tendency of miner to create blocks greater than current nominal block size limit (up to 4x).

# blockoverbookingtendency=1.0 > never do any overbooking

# =1.5 > low tendency for overbooking, never more than 1.5x nominal BSL

# =2.0 > intermediate tendency, never more than factor 2.0 DEFAULT !

# =3.0 > intermediate tendency for overbooking, never more than 3.0x

# =3.5 > high tendency for overbooking, never more than 3.5x nominal BSL

# =4.0 > fill blocks to the max. from the mem pool, up to 4x nominal BSL.

blockoverbookingtendency=2.0



4 Rationale

[Rat1]Q.: During the BIP10X activation phase, why is 75% the activation limit, and why are BIP101

blocks counted by 50% as if they were mined by BIP10X miners?A.: Miners of BIP101 blocks are voting for a block size increase schedule, similarly to BIP10X

miners. The difference is that the block size increase schedule of BIP10X is less aggressive than that of BIP101, because BIP10X's growth rate max limits are set to be equal to the fixed growth rate of BIP101 (excluding BIP10X's 80% miner majority “boosted” growth, which is only meant to be as an emergency exit if demand and technology increases faster than expected). Also, the initial block size limit of 8 MB is at least by a factor of 2 greater than that of BIP10X.Hence it would be negligent to fully ignore the votes of BIP101 blocks for the BIP10X proposal, because in case of a stalemate between BIP101 and BIP10X (none reaching 75% on their own), BIP10X can serve as a “smallest common denominator” that is still better than “no growth at all”from a BIP101 supporter's viewpoint. On the other hand, a BIP10X miner is unlikely to switch to the more aggressive and predetermined fixed BIP101 growth schedule.It is assumed that at least 50% of the BIP101 miners will be willing to switch over to BIP10X mining if the supermajority of BIP10X is achieved.In this context it is important to note that if the BIP10X's “75% supermajority” condition is achieved, it is guaranteed that the number of BIP10X blocks is at least 50%, with “equal 50%” only being possible if there are no legacy blocks at all!Below is a list of examples of what situations would trigger BIP10X 75% supermajority achievement condition – with the corner cases included:

Nb of BIP10X Blocks Nb of BIP101 Blocks Nb of Legacy Blocks BIP10X Percentage

504 (50.0%) 504 (50.0%) 0 ( 0.0%) 504+252 = 756 = 75.0% of 1008

505 (50.1%) 503 (49.9%) 0 ( 0.0%) 505+251 = 756 = 75.0% of 1008

506 (50.2%) 501 (49.7%) 1 ( 0.1%) 506+250 = 756 = 75.0% of 1008

507 (50.3%) 499 (49.5%) 2 ( 0.2%) 507+249 = 756 = 75.0% of 1008

...

632 (62.7%) 248 (24.6%) 128 (12.5%) 632+124 = 756 = 75.0% of 1008

...

756 (75.0%) 0 ( 0.0%) 252 ( 0.0%) 756+ 0 = 756 = 75.0% of 1008

The operators of the BIP101 miners have 23 weeks time to switch over to BIP10X, which shouldbe fully sufficient.

[Rat2]Q.: Why are 1008 block intervals chosen for the Block Size Limit (BSL) adjustment, and why is

there this “504 block offset” to the difficulty adjustment block?A.: First, 1008 blocks corresponds to exactly one week (assuming block time=10min), which is a

good design value since it is long enough to average out periodic oscillations in traffic patterns that are likely to occur due to weekdays and weekends. Probably this is also the reason why Satoshi chose 2016 blocks (2 weeks) for the difficulty adjustment. On the other hand, 1 week is short enough to react with sufficiently fine granularity to changes in traffic volumes.Secondly, the 1008 interval is exactly half of the 2016 interval for difficulty adjustments. Since BIP10X offsets these two timegrids against each other, there is always a roughly 3.5 day (504 blocks) gap between a difficulty adjustment and a BSL adjustment. In particular, these events will never concur in the same block. Also note that some special contents are written to the block header 3 blocks before or 1 block after a BSL adjustment. By keeping a fixed 504 block offset between BSL and difficulty adjustment, we avoids any potential special conditions that the



SW may run into when different special cases of difficulty adjustment and BSL adjustment coincide, thereby reducing the number of SW scenarios to be tested, and decreasing the likelihood of an unexpected bug occurring in real operation lateron. While this may seem overcautious, at least it does not harm to have this 504 blocks offset.

[Rat3]Q.: Why is the vote (and other new information of BIP10X) put to the block header (and there

inside the version number field)?A.: It is believed that the current 32bit version number is much more than what will ever be

needed for version number purposes. The version number is typically only needed to ensure controlled transitions when introducing forks of the Bitcoin software. Once the fork has completed, the “old” version number is no more used. In principle, for future forks, once version number 255 is reached, the next fork can be deployed with version number 0, that one followed by 1, 2, 3, etc., i.e. a “modulo 256” cyclic version numbering would be fully sufficient (and even those 8 bits are much more than what is needed).Therefore the two middle bytes of the version number can be used for other purposes. BIP10X uses them for carrying the BSL voting information and other BIP10X specific information, without harming Bitcoin functionality elsewhere for the near or far future.The idea to include the BSL vote into the block header (here the version number field) was also inspired by Gavin Andresen's comment in his BIP101 proposal, when commenting on Jeff Garzik's BIP100's proposal which includes the vote in the coinbase scriptSig:“[...] [Having BIP100's vote in the coinbase scriptSig] is more complex to implement [than BIP101'ssolution to only have a modification in the header], because [with BIP100] the maximum allowed size for a block depends on information contained in coinbase transactions from previous blocks (which may not be immediately known if block contents are being fetched outoforder in a 'headersfirst' mode)”With BIP10X's approach to include the vote (and other new infos) in the header's version number field, this disadvantage is avoided.

[Rat3b]Q.: Why is the version number chosen to be “0x20VTSS0B”, and why is an exponential (“BSE”/

“rBSE”) rather than linear format used for the block size limit vote?A.: The least significant byte is chosen as 0x0B = 00001011 for best compatibility with legacy

version numbers. While BIP101 sets bit number 3 (yielding 0x7), BIP10X sets bit number 4 (yielding 0xB). The “0x20” of the most significant byte is taken from BIP101.The two middle bytes (“0xVTSS”), which were formerly unused in the Bitcoin protocol, now contain the current BSL, the BSL vote and other information needed by BIP10X. It turns out thatthese few bits are fully sufficient and futuresafe for this task, because block sizes from 1 MB to 60 GB (and by using a spare bit yet reserved in BIP10X, even up to 3939 TB) are supported.

Although this signaling range is huge, the step increments are as fine as 9.05% for the complete range of block size values. This means we have constant step increments on logarithmic rather than linear scale. This is much better suited, because a constant linear step increment of e.g. 1 MB might be considered too coarse in the year 2015 but much too fine than what is necessary at a future point in time when blocks are e.g. 100 MB in size. Since the block size exponent format of BIP10X is defined for powers of 2, implementation is easy and free of rounding artifacts on a binary digital processor.Hence, the exponential (“BSE”) format ensures optimum granularity for the complete range of block sizes while at the same time reducing the number of signaling bits to a minimum.

[Rat4]Q.: Why is the constraint (C1) set to be such that the Block Size Limit should be in the interval



[1.21 ; 4.585]*average_Actual_Block_Size?

Doesn't this mean that the BSL will increase even when the network is actually underloaded? For example, if average actual block size is 9 MB and current BSL_curr is 10 MB, this constraint will impose an increase of BSL from 10 MB to ca. 1.2*9 = 10.8 MB, even though the current block size limit is sufficient, since 10 MB can well accommodate the 9 MB traffic load. So doesn'tthis increase the BSL unnecessarily?

A. No. With reference to [5] we see: Blocks are not filled evenly in reality, due to the randomness of traffic processes, and also due to different miner strategies. Instead, the block occupancy varies substantially. Some blocks are full, others are quite empty. The analysis in [5] shows that the network already starts to exhibit noticeable symptoms of congestion when the blocks are on average 75% full (2.3 TPS vs. max. of 3.0 TPS in the example of [5]). In that case, the block confirmation times already increase noticeable.From this we can learn that a balanced healthy Bitcoin network needs to be dimensioned to have a max. capacity that is about 33% above its average traffic. So, for an average traffic off 9 MB per block, the recommended minimum BSL should actually be 1.33*9 = 12 MB.Constraint (C1) is therefore even a little conservative, because it only applies a factor of ca. 1.21 and not 1.33. Clearly, reducing the BSL, like a factor of 1.00 would suggest, would be the wrong way to go, since an already congested network would become even more congested.Note also that the constraint (C1) is not the last constraint in the row. There still is (C2), whichensures that even under heaviest load (as it might be caused e.g. by spammers), the growth rate is limited to a longterm value of 41% per year (or in extreme case 100% for consistent >80% vote majority). So, there cannot be a 21% BSL increase week after week, as it appears when only looking at the parameter “1.21” of constraint (C1).Another way of viewing this parameter “1.21” is, that as soon as average block occupancy reaches or exceeds 90%, the BSL will be raised, no matter what the miners vote. Because constraint (C1) says 0.90*1.21=1.09, which will be mapped to a BSL adjustment by +9%. (Note that adjustment steps are 9% due to the exponential representation of the BSL, so a block occupancy of only 89%, which yields 0.89*1.21=1.08, will not yet trigger a BSL increase, because 1.08 gets rounded down to 1.00 on the exponential resolution grid of block sizes.)When looking at Fig. 41 from [5], we see that 90% block occupancy corresponds to the value of2.7 on the xaxis. This is just before the situation starts becoming critical, so the 90% is a good design value to help avoiding the worst.

Fig. 41: Network congestion effects in dependence of how much blocks are filled relative to the max block size. Diagram taken from reference [5].

About the other side of the interval, the “4.585”: This is simply designed such that BSL will



decrease if actual block occupancy falls below 20%. Again, the exponential resolution grid for the block size limit is respected, the smallest decrease increment of BSL is 8.3% (=factor 0.917 = 1/1.0905), and BSL is only decreased if actual_block_size * 4.585 is below 0.917. Since 0.20*4.585=0.917, this is the case for <20% average block occupancy.

Moreover, the value 4.59 also serves another purpose: It avoids that a minority of miners can prevent a BSL increase by mining empty blocks and thereby reducing the average actual block size (aABS). Let's take the example that 50% of miners create empty blocks, while another 50% of miners create reasonably filled blocks of size = 0.8*BSL_curr. In that case, aABS = (0.5*0+0.5*0.8)*BSL_curr = 0.4*BSL_curr. The BSL vote is postprocessed to be forced to be <4.59*0.4*BSL_curr = 1.836*BSL_curr, hence a 51% voting majority can still make sure that BSL can be increased.

[Rat5]Q.: Why is the maximum instantaneous (i.e. weekly) increase or decrease of BSL limited to a

factor of 1.682 (=2^(6/8)) by definition of the BSL voting bit field in the header, which only ranges from “1/1.682*current_BSL” to “1.682*current_BSL”?

A.: This limitation is an implicit consequence of other design parameters, namely the longterm min/max change rate of BSL. Acc. to constraint (C2), the longterm BSL cannot change by morethan a factor between 0.8593750 and 1.4765625. This means, even in the extreme and unlikely case that this range is fully used to the one edge in one week, and to the other edge in the next week, we could not see an increase of more than a a factor 1.4765625/0.8593750 = 1.72. To realize such a change, a voting of 2^(7/8)) = 1.834 * current_BSL would be necessary and votes outside the range 2^(7/8)) .. 2^(+7/8)) would be useless. The voting protocol restricts this range by one more step, putting the effective limit to the range 2^(6/8)) .. 2^(+6/8)). Inthe extreme unlikely case that a greater adaptation step would be desired, this would just be achieved in the next voting interval one week later. The restriction to max. range 2^(6/8)) .. 2^(+6/8)) is made to keep one bit available for the Overbooking Indicator.Note that we did not talk about the extreme 80% miner majority voting here, which implies a slightly greater theoretical(!) range due to constraint (C2). This would yield a (very) theoreticalextreme instantaneous jump of BSL by a factor of 1.9296875/0.7656250 = 2.52, which, if votedfor, required a voting range 2^(11/8)) .. 2^(+11/8)). However, this would only practically be possible if 80% of miners in one week voted for extreme low block sizes, and 80% voted for extreme high block sizes the very next week (or vice versa), so practically this situation can be ruled out. And even if it happened, this would be no big deal at all, it would just take one additional week (another 1008 blocks of voting) to achieve the desired adjustment step, e.g. by voting for a step increment of 2^(+6/8)) in two successive weeks.To summarize: The voting format that restricts the BSL increment from one week to the next to steps between 2^((+/6)/8)), i.e. between factors 0.594 and 1.682, is fully sufficient and does not restrict the voting range in any significant and practically, not even theoretically, relevant way. By this restriction, we get an extra bit available that is used as Overbooking Indicator.

[Rat6]Q.: Why is the 50% quantile (median) chose for the voting decision? And why is the 80% majority

criterion chosen for the initial vote about the initial block size limit to start with?A.: The general 50% quantile (median) is chosen to make it impossible for any miner minority to

manipulate the voting decision in one way or another. If the protocol used the 20% quantile, it would mean that a minority of 21% could vote for 1 MB blocks forever, and the “1MB” vote would be the effective vote forever.[Side note: Even then, the block size limit would not be stuck at 1 MB forever, because of constraint (C1), compare [Rat4]: If actual block sizes are sufficiently high, the protocol will increase the BSLin any case, even if 100% of miners vote against it. To avoid BSL increase, miners would in that



case have to create smaller blocks.]If the protocol used the 80% quantile, it would mean that a minority of 21% of miners could enforce an “upvote” of the block size limit forever.[Side note: Even then, the block size limit would not grow indefinitely, because of constraint (C1), compare [Rat4]: If actual block sizes are sufficiently low, the protocol will not increase the BSL anyfurther (and might even decrease it), even if 100% of miners vote against it. To avoid BSL decrease, miners would in that case have to create larger blocks.]That is why the 50% quantile appears to be the most appropriate and fairest way to go. The 50%median value means:

“There are not more than 50% of miners who think that the new BSL is too small,and there are not more than 50% of miners who think that the new BSL is too large.”

So this seems to be the most agreeable solution.

For the INITIAL vote (first 1008 blocks 1st voting week after BIP10X activation) which determines the BSL where to start with, a higher majority of 80% is required. This ensures that the protocol will not start with a too large BSL that too many miners would disagree with, to avoid a too big disruption/shock. Here the idea of a wider consensus dominates, in a way that in case of doubt, a smaller block size is given preference to (hence the 20% quantile is taken, not the 80% quantile). The given solution means:

“For 80% of the miners, the initial BSL chosen by BIP10X is not too big.”

[Rat6b]Q.: Why using a quantile for the vote in the first place? Why not e.g. taking the average of all

votes except the top and bottom 20% votes?A.: This appears “fairer” only at the first glance. In fact it would be more prone to manipulation. For

example, a 30% minority could make an extremely high vote. While 20% of votes are cutoff, the remaining 10% are still taken into consideration in the averaging process, and thereby the final vote will become biased towards too high values.In the next voting interval, some miners would tend to make “tactical votes”: To counter a tactical voter on the one edge showing extremely high values, the other side might decide to vote for extremely low values, with the intent that the final average turns out to be what they actually want.So such “averaging rule” would open up the voting process to the field of game theory and tactical voting, which is completely unnecessary. Because, the “quantile” rule avoids tactical voting from the start. If a miner wants to have a BSL of say 10 MB, the best he can do is to vote for 10 MB, no matter what the other miners do! If most of the other miners vote below/above 10 MB, he could not offset this by himself voting with a particularly [high/low] vote like e.g. [100 MB/1 MB]. It would not change the final quantile selected. Only a voting rule based on quantiles eliminates tactical voting, and it is therefore the fairest, safest and most transparent voting scheme possible.

[Rat7]Q.: Why is the “Overbooking feature” introduced to allow blocks beyond the “nominal” BSL?A.: Overbooking is meant to act only as a last resort if transactions stack up too much, as it could be

the case during a temporary “spam attack”. In this case, block size is allowed to be greater than the nominal current block size limit denoted by BSL_curr. This gives some amount of “elasticity” or “flexibility” to the network. To limit the negative impact of too large blocks, the maximum overbooking allowed is a factor of 4. Moreover, the protocol only allows on average (ca. 150 dayaverage) 10% of blocks to be more than 2 times larger than BSL_curr, and only 30% of blocks tobe larger than BSL_curr.Another way of illustrating the limitations is as follows:



• The “effective” window length of the exponential window for determining the average overbooking block ratio (OBR) is 114 days (mathematical term describing at what time in the past the exponential averaging weight window has decayed to 36.8% (=1/e), when 100% is the weight at the present time). Together with the 10% / 30% limits mentioned before, this implies for example:

• Exceeding the nominal BSL by a factor 4 is allowed on no more than 11 successive days, when every block is overbooked this way (or 25 days with every second block being of “regular” size).

• Exceeding the nominal BSL by a factor 2 is allowed on no more than 40 successive days, when every block is overbooked this way (or 104 days with every second block being of “regular” size).

Moreover, a certain counterincentive against creating overbooked blocks is built into the protocol: It is the rule that a certain fraction of TX fees must be destroyed (spent to a predefinedunspendable address). This fraction is higher, the more the block size exceeds BSL_curr. According to this rule, the complete TX fees of the block are considered to be spread equally over the entire block size, and then 25% of those fees that fall in the area exceeding BSL_curr have to be destroyed.With this rule set, it is considered fair to assume that under normal circumstances overbooked blocks will not occur. However, should an emergency situation (very high TX load) occur, the protocol provides an “emergency exit” to increase the block size short term (decision can be made on a perblock basis) to avoid too long TX delays that may make users unhappy and thereby reduce utility and value of Bitcoin.

[Rat7b]Q.: Why is the counterincentive for overbooking blocks realized by burning TX fees, and not by

“rolling” those fees “over” to future blocks, as proposed by Meni Rosenfeld [8]?A.: There are two reasons: First, the overbooking of blocks is meant to be a “last resort” feature that

is not used extensively. Hence, there is anyway not a lot of TX fees to be lost by the miner community overall, so it is an overkill to implement a rather complicated and new rollover mechanism just to save the miners community some fees.Secondly, there is another argument against a rollover mechanism if we look at the (counter)incentivesituation for the “collective miner community” as a whole: With rollover mechanism, all TX fees would eventually go to the collective miners. If all miners followed the same overbooking policy, they would on average just loose as many TX fees in their own blocks due to overbooking as what they would get back as rollover from other miners. So, collectively, the counterincentive against overbooking would disappear.

[Rat8]Q.: Why is the configuration parameter blocksizelimitvote in bitcoin.conf set to “1.7a” by

default?A.: This parameter means that the default voting strategy is to vote for a block size that is by a

factor 1.7 higher than the actual average block size of the last 1008 blocks. This appears to be reasonable, because a healthy network without too many network delays should have a BSL thatis comfortably above the actual average block size, as Fig. 4.1 demonstrates. The factor 1.7 comes down to an effective average vote for only “factor 1.63” when considering the block size resolution grid imposed by the exponential format of the BSL (increments of 9.05%). A factor 1.63 means that a situation is aimed for at which the actual block size is ca. 1/1.63=61% of the BSL. On Fig. 4.1 this corresponds to the value “1.83” on the abscissa, and here extra block confirmation times due to congestions are in the range of ½ .. 1 blocks, which appears to be a reasonable design target.



[Rat9]Q.: Why is exponential averaging with forgetting factor applied for calculation of the average BSL

and the average overbooking ratio? Why not calculating a normal average (rectangular instead of exponential weighting window)?

A.: The exponential averaging method is a very cycle and memory efficient method, because unlike for a rectangular average window it does not require to store a big number of individual values over which to average, and it still realizes a floating averaging window. Moreover, it has the niceproperty that younger values are weighted more than older values. By one single tuning parameter, namely the forgetting factor, the effective averaging length can be tuned without anyfurther modification of the software code. For facilitating dimensioning, the effective window length can be calculated as 1/(1forgetting factor).Moreover, an exponential averaging window implemented this way is always a sliding window and therefore avoids artifacts occurring for stepwise averaging.In summary, the method is easy to implement and to adapt, easy to dimension, and it shows favorable behavior.

[Rat9b]Q.: And why is the exponential averaging method not applied to “actual block size” in constraint

(C1) then, why is the average actual block size (aABS) calculated as simple average (finite rectangular weight window) over the last 1008 blocks?

A.: Because (C1) wants to make sure that the “explicit” miner votes are not in contradiction to howmuch the blocks are actually filled (the latter could be considered “implicit” votes). For this to make sense, both have to relate to the same time interval, i.e. to the 1008 blocks voting interval.



5 Simulations

With constraint (C2) of the BSL calculation, the longterm change rate of the BSL gets limited. Depending on the “voting conditions”, one out of two sets of min/max limits apply. First we look at “normal voting conditions” this is the situation when there is NOT a >80% miner majority voting for a strong in or decrease of BSL.

In this case, every time that a new BSL is calculated from miners' votes and from actual block sizes (i.e. every 1008 blocks 1 week), the new BSL_curr is constrained to be below

189/128*BSL_LongTermAvg = 1.4765625*BSL_LongTermAvgand above

110/128*BSL_LongTermAvg = 0.8593750*BSL_LongTermAvg

After BSL_curr has been determined this way, longterm average is updated byBSL_LongTermAvg = 32244/32768*BSL_LongTermAvg + (132244/32768)*BSL_curr.(32244/32768 0.984)

The three parameters 189/128, 110/128 and 32244/32768 determine growth/decline rates.A simulation has been written (source code in appendix) for FreeMat 4.0 and has been run for various extreme cases of maximum growth and decline rates.

The parameters are chosen by design such that a doubling every 2 years and a halving every 8 yearsis achieved when each BSL update pushes against the respective limit of (C2). This is verified by simulation, as shown below.

The following simulations and diagrams assume without loss of generality, that BIP10X activation (more precisely block M+1008) occurs in the beginning of year 2016.

Note: The algorithm assumes that before start of BIP10X, the BSL was constant and identical to the BSL value set as initial BSL. This is because BSL_LongTermAvg is initialized with the initial BSL_curr,as specified in ch. 2.2. As a consequence, the “reference start time” of the adjustment is implicitly backdated to a point in time that lies one year before BIP10X activation. Therefore, the first BSL doubling occurs already 1 year after BIP10X activation, but then every 2 years afterwards. This can be nicely seen in the 3rd figure of simulation (SIM01) (next page).



(SIM01) In the maximum growth case, it is assumed that all votes are sufficiently high or the blocks themselves are sufficiently occupied (actually, only the latter is sufficient), such that the actual limit for BSL growth is determined by constraint (C2). Simulation started with initial condition BSL_curr=1 MB and then maximized growth rate. It can be seen that a fairly constant growth rate of +41% per year (+100% per 2 years) is achieved from the beginning.

Zoomedin for the first 4 years, illustrating doubling every 2 years:



(SIM02) In the maximum decline case, it is assumed that miner votes are sufficiently low or the blocks themselves are sufficiently empty (actually only the latter is sufficient), such that actual limit for BSL decline is determined by constraint (C2). Simulation started with initial condition BSL_curr=4 MB, and then maximized decline rate.As intended by design, we see a halving every 8 years (first time at t_ref+8years, with t_ref being one year before BIP10X starts.)

The following shows the analogous simulations for the case that growth/decline is boosted by >80% miner votes, such that the BSL doubling/halving rates are roughly speedup by a factor of 2.Now, constraint (C2) is less restricitive than before and is restricting BSL_curr to be below

247/128*BSL_LongTermAvg = 1.9296875*BSL_LongTermAvgand above

98/128*BSL_LongTermAvg = 0.7656250*BSL_LongTermAvg

The effect is shown in the following simulations:(In the simulation script, we set the parameter random_80percent_boost = 1.0 )



(SIM03) Simulations for the growth case show a doubling in a bit more than 1 year, as intended bydesign. For example, after 10 years (2015 2025) BSL has increased by roughly a factor →2^10=1024, which corresponds to 10 doublings, i.e. one per year, and further doublings the years after:

Zoomedin:



(SIM04) Simulations for the decline case show a halving every 4 years, as intended by design:



The following shows the situation that a certain percentage of blocks gets the “80% vote boost”. For the sake of illustration, it is assumed that the boost occurs in regular intervals, e.g. every 3rd week incase that 33.3% of blocks get the “80% majority upvote”:

The first of the following two figures illustrates the situation for the 10% case: For every 10th block, the relaxed growth constraints that are applicable to the “80% upvote” are applied, hence the block size limit shows peaks. For the nine blocks afterwards the normal and tighter constraints apply, hence the block size limit goes back down again, normally to where it was before the peak.Note that the constraint is applied relative to the longterm average block size limit (ca. 12 year average), so a single peak from the boost only contributes by a small fraction to the longterm average and does not affect the longterm growth rate a lot.However, if the “peaks” happen more often, they will eventually have an enduring effect on longterm growth rate, as is illustrated by the second figure below.

The last figure above illustrates the situation in case that the percentage of blocks experiencing a “boost” of the block size limit due to 80% majority vote is equal to [0%, 10%, 20%, 33%, 50%, 67%, 80%, 90%, 100%] respectively.



Appendix

A.1 Overview of BIP10X's Hardcoded Parameters and Design ChoicesVoting and direct Block Size Limit parameters:• 75% = miner majority for BIP10X activation• 50% = 50% of BIP101 miners are contributing to the BIP10X activation condition• 80% = majority determining the initial BSL (i.e. 20% quantile)• 50% = quantile (median) for normal BSL adjustment• 80% = majority (20% and 80% quantile) for accelerated BSL adjustment • 1MB = min. value for initial BSL• 4MB = max. value for initial BSL• 1,000,000 byte = floor(2^(0/8) * 1 MB) = absolute minimum BSL• 60,096,776,975 byte= floor(2^(127/8) * 1 MB) [ 60.1 GB] = absolute maximum BSL• 3,938,502,375,863,834 byte= floor(2^(255/8) * 1 MB) [ 3939 TB] = absolute maximum

BSL when activating a yet reserved bit (by simple hardfork in a very distant future)• 2^(1/8) [1.090508] = step increment factor of possible BSL values• 2^(6/8) [1.6818] = greatest instantaneous BSL adjustment step factor (in either direction)• 1008 blocks initial voting interval• 1008 blocks normal voting interval• 2016..3023 blocks grace period length

Block Size Limit averaging and constraints:• 32244/32768 [0.984] = Forgetting_factor determining “average” BSL, which is the basis for

limiting the longterm growth of the BSL. It corresponds to an effective window length of 1/(10.984) 62.5 weeks 1.2 years

• 189/128=1.4765625 = Parameter limiting the max. longterm growth of BSL to ca. 41% p.a. (together with above forgetting factor) under “normal voting conditions”

• 110/128=0.8593750 = Parameter limiting the max. longterm decline of BSL to ca. 8% p.a. (together with above forgetting factor) under “normal voting conditions”

• 247/128=1.9296875 = Parameter limiting the max. longterm growth of BSL to ca. 100% p.a. (together with above forgetting factor) in case of >80% miner upvote

• 98/128=0.7656250 = Parameter limiting the max longterm decline of BSL to ca. 16% p.a. (together with above forgetting factor) in case of >80% miner downvote

• [39704/32768 ; 150244/32768] [ [1.21;4.59] ] = Range relative to the average actual block size of the last voting period (=1008 blocks). The effective BSL vote is forced to lie within this range.

Overbooking of blocks:• 16383/16384 = 0.99993896484375 = Forgetting factor for calculating average overbooked

blocks ratio. It corresponds to an effective window length of 114 days = 16.25 weeks = 1/3 year.

• 2 = max. overbooking factor for up to 30% overbooking• 30% = max. ratio of overbooked blocks • 4 = max. overbooking factor for up to 10% overbooking• 10% = max. ratio of blocks overbooked by more than factor 2• 25% = fraction of “excess” TX fees to be burned for overbooked blocks.



A.2 Comparison of Different Block Size Evolution Proposals

Here is a concise comparison table, based on [6] and further extended:

Block size limit evolution mechanism:[1] BIP100: miner voting[2] BIP101: fixed exponential growth schedule[3] BIP102: constant block size limit[4] BIP103: fixed exponential growth schedule[x] BIP10X: miner voting and actual block size; plus shortterm adaptation to temporary peaks.

Block Size Limit growth/decline:[1] BIP100: By miner voting, x0.5 – x2.0 every 12000 blocks (3 months)

max growth rate: +1982% p.a. (x20.82 p.a.)→ max decline rate: → 95.2% p.a. (x0.048 p.a.)

[2] BIP101: Fixed growth rate: +41.4% p.a. = +100% every 2 years[3] BIP102: +/0% p.a. (2 MByte static)[4] BIP103: Fixed growth rate: +17.7% p.a. = +100% every 4.3 years (+4.4% every 97 days) [x] BIP10X: Depending on actual block size and miner's votes (median of all votes),

longterm growth/decline rate restricted to max. +41% p.a. / 8% p.a.= +100% in 2 years / 50% in 8 years.

With 80% miner support, maximum rates get pushed to +100% p.a. / 16% p.a.

Voting abuse possible by miner minority:[1] BIP100: Yes, miner minority (20%) can enforce excessive BSL decline of ca. 95% p.a.[2] BIP101: No (no miner vote)[3] BIP102: No (no miner vote)[4] BIP103: No (no miner vote)[x] BIP10X: No, a miner minority making excessive votes in either direction has no effect at all.

Voting abuse possible by miner majority:[1] BIP100: Yes, may enforce excessive growth/decline rate of ca. +2000% p.a. or 95% p.a.[2] BIP101: No (no miner vote)[3] BIP102: No (no miner vote)[4] BIP103: No (no miner vote)[x] BIP10X: Limited: Miner vote can influence growth/decline rate only within [16%..+100%] p.a.

But if actual block size does not keep pace with miner vote, even a 100% miner votecannot change the block size limit.

Risk due to “lazy” miner operators who keep bitcoin.conf unmodified:[1] BIP100: ?? Default voting mechanism not specified.[2] BIP101: No (no miner vote)[3] BIP102: No (no miner vote)[4] BIP103: No (no miner vote)[x] BIP10X: No. Default parameter causes reasonable vote for ca. 1.63 times avg. actual block size

Block Size Limit at initiation:[1] BIP100: 1MB [2] BIP101: 8MB (dpdt. on time of initiation, 0.7% increase per week, 100% per 2 years ) [3] BIP102: 2MB [4] BIP103: 1MB[x] BIP10X: 14 MB dpdt. on miner vote in 1st voting week (takes minimum of top 80% votes)



Final Block Size Limit and when is it reached:→[1] BIP100: 32 MB → can slow down/stop/reduce by miner vote[2] BIP101: 8192 MB → 20360106[3] BIP102: 2 MB → 20151111[4] BIP103: 2048 MB → 20630709[x] BIP10X: 60.1 GB → can slow down/stop/reduce by miner vote or permanently small blocks

(theoretically in 2047 w/o 80% miner support, or 2031 with 80% minersupport, but will never happen if actual blocks are not sufficiently filled)

“Elasticity” of block sizes in case of temporary high TX load:[1] BIP100: No (fastest reaction time = x2 increase every 3 months)[2] BIP101: No (fixed growth rate)[3] BIP102: No (constant 2 MB)[4] BIP103: No (fixed growth rate)[x] BIP10X: Yes, immediate up to 4x block size limit “overbooking” allowed in exceptional cases,

but associated with a counterincentive to avoid abuse. [Rat7]

Miner voting used to initiate the hard fork?[1] BIP100: Yes, support with 10800 out of last 12000 blocks (90%)[2] BIP101: Yes, support with 750 out of last 1000 blocks (75%)[3] BIP102: No[4] BIP103: No[x] BIP10X: Yes, support with 756 out of last 1008 blocks (75%); BIP101 blocks counted by 50%

When does the hard fork happen?[1] BIP100: 20160111, after 90% miner support[2] BIP101: 20160111, two weeks after 75% miner support[3] BIP102: 20151111[4] BIP103: 20170101[x] BIP10X: today, 23 weeks after 75% miner support



A.3 Simulation Source Code and Simulation Tool

How to Use FreeMat Tool

Simulations were done using FreeMat 4.0. FreeMat is freely available under GPLv2 license for all major operating systems. To execute this simulation script, do the following steps:

• Copypaste the source code below to an empty text editor window and save as “BSL_change.m” or any other file name ending with “.m” (file name has only letters, numbers and underscore, first character is a letter).

• Install FreeMat 4.0 or later.

• Start up FreeMat. You see the GUI as shown in the screenshot below.

◦ Browse (1) to the director where your file “BSL_change.m” is located. You can also use “cd” command like in the console of your operating system.

◦ Type (2) “edit BSL_change.m” <ENTER> to open the file in an mfile editor with syntax highlighting.

◦ Modify the parameters as desired, in the parameter section of “BSL_change.m”.

◦ Type (3) “BSL_change” <ENTER> to execute the script which starts the simulation.



The Source Code (“BSL_change.m”)% % Simulation for FreeMat v4.0 (Matlab clone with GPLv2 license) % % Purpose: Find out how the Btcoin Block Size Limit (BSL) evolves with the rule set of BIP10X, in % the corner case that the growth or decline rate is determined by constraint (C2) % of BIP10X (either the normal limit, or the stretched limit of 80% miner majority). % In case of growth, this corresponds to the case that >50% (>80%) of miners continually % vote for substantial Block Size Limit increase, or that the blocks are sufficiently full % in each oneweek average period, such that other factors do not limit the growth. % In fact, if the blocks are sufficiently full, this would already be enough to cause this % "50%votelike" BSL increase, irrespective of the actual miner votes. % In case of decline, this corresponds to the case that >50% (>80%) of miners continually % vote for substantial Block Size Limit decrease, or that the blocks are sufficiently % empty in a oneweek average period, such that other factors do not limit the decline. % In fact, if the blocks are sufficiently empty, this would already be enough to cause a % "50%votelike" BSL decline, irrespective of the actual miner votes. % % Note: This simulation assumes 52 weeks == 1 year for simplicity (the error is 1.25 days or 0.34%). % This simulation assumes further that 1 week = 1008 blocks. % Since hash rate is expected to increase longterm, be it alone due to the advances in % technology, reality is expected to show that 1008 blocks < 1 week. % This can be accounted for by setting 'time_warp_hash_speedup_factor' accordingly. % % As a consequence, results are slightly biased in that actual growth/decline rates under the % given circumstances can be expected to be slightly stronger vs. time than what this % simulation shows. % On the other hand, actual growth rates cannot always be expected to be at the maximum % in reality, and this effect should offset (or even overcompensate) the first one. % % (C) 2015 by Michael_S % % close all; clear all;

% %% #0) Parameter Settings:

Start_Year = 2016 + 0*1/12;% e.g. 2016.5 means 1st July 2016

NbYrs=5; % simulate for this number of years (1008*52 blocks == 52 weeks == 1 year)

% If block times are shorter than 10 min, enter corresponding factor <1.0 here. Or vice versa: time_warp_hash_speedup_factor = 1.0;%[1.0] e.g. 0.9 means 9 min avg. block time

BSL_init_MB = 1;% Initial value of the block size limit, e.g. 1 or 4 [MByte]

Direction = 1;% 1 = grow ; 1 = decline

%averaging_method = 'flat';% 'flat' or 'forgetting_factor' < NOT used in BIP10X averaging_method = 'forgetting_factor';% 'flat' or 'forgetting_factor' < this one for BIP10X!

% forgetting_factor only applicable if averaging_method=='forgetting_factor': forgetting_factor=32244/32768;% (~0.984) = eff. window length = 1/(10.984)=62.5 weeks = 1.2 years

% Parameters for 'flat': (this method is not used in BIP10X gives worse results) %incmax_yearAvg = 1.24;% New BSL can be max. this much higher than avg over last Yr %decmin_yearAvg = 0.90;% same for decrease

% Parameters for 'forgetting_factor': (this method is used in BIP10X) incmax_yearAvg = 189/128;% =1.4765625;% New BSL can be max. this much higher than avg over last Yr decmin_yearAvg = 110/128;% =0.8593750;% same for decrease incmax_yearAvg2 = 247/128;% =1.9296875;% parameter for growth speedup (needs 80% vote majority) decmin_yearAvg2 = 98/128;% =0.7656250;% parameter for decline speedup (needs 80% vote majority)

% Random Event 1: >80% miner vote: Boosted maximum growth/decline rate, stretched limits apply: probability_80percent_boost = 0.0;% probability that a BSL increase is boosted by >80% miner vote % Following pattern is followed cyclically, one step per week. If value <>0, boost condition is met: pattern_80percent_boost = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];

% Random Event 2: Stay one step away from max growth/decline value: probability_one_step_less = 0.0;% probability that BSL adjustment is modified as follows: % BSL is one step smaller (in case of growth) or higher (in case of decline) on the BSE resolution % grid than what it would otherwise be. % Following pattern is run cyclically, 1 step p. wk. If value <>0, condition "one step less" is met: pattern_one_step_less = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0];

% Plot Screen Size modify in dependence of your monitor's resolution: plot_window_width = 900; plot_window_height = 360;

% %% #1) Initializations:

BSE = max(0,min(127,floor(8*log(BSL_init_MB+eps)/log(2))));%block size exponent, 0..127

N = round(NbYrs*52/time_warp_hash_speedup_factor);% nb of 1008 block periods (~weeks).

BSL_vector(1:52)=2^(BSE/8)*1e6; % [in MByte] Initialise the BSL value for the first 52 weeks BSL_vector = [BSL_vector, nan*ones(1,N)];

% Initialize BSL_LongTermAvg only needed if averaging_method = 'forgetting_factor': BSL_LongTermAvg = BSL_init_MB * 1e6;

% %% #2) The Simulation:

if Direction == 1,% GROWTH Case % Try to increase BSL as much as possible, for the given limits for k = 52+1:52+N, % start with first week of the 2nd year % Calculate average BSL if strcmpi(averaging_method, 'flat'),% not BIP10X BSL_LongTermAvg = mean(BSL_vector(k52:k1)); elseif strcmpi(averaging_method, 'forgetting_factor'),% BIP10X ! BSL_LongTermAvg = forgetting_factor*BSL_LongTermAvg + ... (1forgetting_factor)*BSL_vector(k1); else disp('ERROR: Invalid value for parameter "averaging_method"!') return; end % Determine which longtermchange constraint applies: if rand()<probability_80percent_boost, incmax = incmax_yearAvg2;% boosted growth by >80% miner vote else incmax = incmax_yearAvg;% normal case end if pattern_80percent_boost(1+mod(k52, length(pattern_80percent_boost))), incmax = incmax_yearAvg2;% boosted growth by >80% miner vote end BSE_last=BSE; % Calculate next BSL for week k, assuming miner vote and actual block sizes were progressive: if (floor(2^(BSE/8)*1e6)) > BSL_LongTermAvg*incmax,% is current BSL > current constaint? BSE = floor(8*log((BSL_LongTermAvg)/1e6)/log(2)); end % Try to go up as much as possible, but don't go more than 6 steps up from last time: 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))), % A random event causes the growth to be not quite as big as it could be: BSE = BSE 1; end BSL_vector(k) = floor(2^(BSE/8)*1e6); end elseif Direction == 1,% DECLINE Case % Try to decrease BSL as much as possible, for the given limits for k = 52+1:52+N, % start with first week of the 2nd year % Calculate average BSL if strcmpi(averaging_method, 'flat'),% not BIP10X BSL_LongTermAvg = mean(BSL_vector(k52:k1)); elseif strcmpi(averaging_method, 'forgetting_factor'),% BIP10X ! BSL_LongTermAvg = forgetting_factor*BSL_LongTermAvg + ...



(1forgetting_factor)*BSL_vector(k1); else disp('ERROR: Invalid value for parameter "averaging_method"!') return; end % Determine which longtermchange constraint applies: if rand()<probability_80percent_boost, decmin = decmin_yearAvg2;% boosted decline by >80% miner vote else decmin = decmin_yearAvg;% normal case end if pattern_80percent_boost(1+mod(k52, length(pattern_80percent_boost))), decmin = decmin_yearAvg2;% boosted decline by >80% miner vote end BSE_last=BSE; % Calculate next BSL for week k, assuming miner vote and actual block sizes were low: if (floor(2^(BSE/8)*1e6)) < BSL_LongTermAvg*decmin,% is current BSL < current constaint? BSE = floor(8*log((BSL_LongTermAvg)/1e6)/log(2)) + 1; end % Try to go down as much as possible, but don't go more than 6 steps down from last time: while ((floor(2^((BSE1)/8)*1e6)) >= BSL_LongTermAvg*decmin) && (BSE1>=BSE_last6), BSE = BSE 1; end if (rand()<probability_one_step_less) ... || pattern_one_step_less(1+mod(k52,length(pattern_one_step_less))), % A random event causes the growth to be not quite as big as it could be: BSE = BSE + 1; end BSL_vector(k) = floor(2^(BSE/8)*1e6); %keyboard end else disp('ERROR: Invalid value for parameter "Direction"!') return end

% %% #3) PostProcessing & Display:

% Yeartoyear percentage change of BSL: % (this one is less meaningful because more "noisy", I use the other metric for display) BSL_percent_change_YoY = 100*(BSL_vector(53:end) ./ BSL_vector(1:end52) 1);

% Yearly average percentage change of BSL since the start: (I use this for display!) years_tmp = (51+[1:length(BSL_vector(53:end))]) / 52;% years, without the first year of course 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); grid on; a=axis; axis([Start_Year1 Start_Year1+(N+53)/52 0 a(4)]); xlabel('Year') ylabel('Block Size Limit [MB]') title(['Block Size Limit vs. Time']) sizefig(plot_window_width,plot_window_height)

if 0;% Dont't plot this one not as meaningful as the next plot (if plot wanted: change 0 > 1) figure; plot(Start_Year+[1:N]/52*time_warp_hash_speedup_factor,BSL_percent_change_YoY); grid on; a=axis; axis([Start_Year1 Start_Year1+(N+53)/52 min(0,a(3)) max(0,a(4))]); xlabel('Year') ylabel('BSL change vs. 52 weeks ago [%]') title(['YeartoYear Block Size Limit Change Rate']) sizefig(plot_window_width,plot_window_height) end

figure; plot(Start_Year+[1:N]/52*time_warp_hash_speedup_factor,BSL_percent_change_avg); grid on; a=axis; axis([Start_Year1 Start_Year1+(N+53)/52 min(0,a(3)) max(0,a(4))]); xlabel('Year') ylabel('BSL avg. yearly change [%]') title(['Yearly Avg. Block Size Limit Change Rate Since Year ',num2str(Start_Year1,'%0.2f')]) sizefig(plot_window_width,plot_window_height)



References

[1] BIP100 (v0.8.1) by Jeff Garzik, http://gtf.org/garzik/bitcoin/BIP100blocksizechangeproposal.pdf

[2] BIP101 by Gavin Andresen, https://github.com/bitcoin/bips/blob/master/bip0101.mediawiki

[3] BIP102 by Jeff Garzik, https://github.com/bitcoin/bips/pull/173/files

[4] BIP103(?) by Pieter Wuille, https://gist.github.com/sipa/c65665fc360ca7a176a6

[5] “Bitcoin Network Capacity Analysis – Part 4: Simulating Practical Capacity” https://tradeblock.com/blog/bitcoinnetworkcapacityanalysispart4simulatingpracticalcapacity

[6] A summary of block size hard fork proposals, https://lists.linuxfoundation.org/pipermail/bitcoindev/2015July/009808.html

[7] “BIP1xx Dynamically Controlled Bitcoin Block Size Max Cap” by Upal Chakraborty https://github.com/UpalChakraborty/bips/blob/master/BIPDynamicMaxBlockSize.mediawiki

[8] “Elastic block cap with rollover penalties” by Meni Rosenfeld https://bitcointalk.org/index.php?topic=1078521.0


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

https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki

https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html

https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-4-simulating-practical-capacity

https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-4-simulating-practical-capacity

https://gist.github.com/sipa/c65665fc360ca7a176a6

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

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

Documents

A Hybrid Mechanism for Adaptively Adjusting Bitcoin's Block Size Limit [BIP10X]