a hybrid mechanism for adaptively adjusting bitcoin's block size limit [bip10x]

Version 0.1 (30 August 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.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 and evolutionary 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. the exact definition of the vote majority) and has some disadvantages by solely relying on miner votes and by allowing excessive annual BSL change rates in both directions. It has been criticized that miners would have too much unrestricted power.This BIP10X proposal takes all ideas of all the above proposals into consideration and adds new ideas, thereby providing a concrete novel solution that tries to promote the advantages and to eliminate the drawbacks of each individual proposal seen so far.This paper proposes that Block Size Limit (BSL) is predominantly determined by miner votes, however restricted and possibly even overruled by several constraints and addons. Miner voting is only possible within certain limits. These limits are the evolution of the block size limit itself (max. annual change rate) as well as the evolution of the actual block size, such that e.g. miners cannot arbitrarily “vote up” the Block Size Limit (BSL) when the actual block sizes do not keep pace. The proposal also incorporates a condition to stretch the growth rate constraints a bit further if a really huge miner majority is in favor of this. Moreover, a mechanism is incorporated to cope with temporary high TX load, to allow a possibility for shortterm reaction to minimize user dissatisfaction.The whole proposal is concrete, complete and detailed on all algorithm, function and protocol specifications. 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 37]


Version Historyv0.1 30 August 2015 First version

“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 thoughts of 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..................................................................................7

1.1 Introduction Schedule................................................................................................................8

2 Detailed Specification........................................................................................................................92.1 Three Phases After BIP10X Deployment..................................................................................9

2.2 Details of the Three Phases........................................................................................................9

Activation Phase..........................................................................................................................9

Grace Period................................................................................................................................9

Operational Phase (Starting with Block M)..............................................................................10

2.3 Version Number Field of BIP10X............................................................................................12

Writing Version Number Field to Block Header.......................................................................12

Reading Version Number Field from Block Header.................................................................14

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

Part 1: Update of Overbooked Blocks Ratio OBR....................................................................15

Part 2: Condition When Overbooking is Allowed....................................................................15

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

Validation Condition of an Overbooked Block.........................................................................16

2.5 Re-Alignment of Long-Term Averaged Values........................................................................17

Re-Alignment of BSL_LongTermAvg......................................................................................17

Re-Alignment of Overbooked Blocks Ratio (OBR).................................................................18

3 New Parameters in Bitcoin.conf......................................................................................................19

4 Rationale..........................................................................................................................................20

5 Simulations......................................................................................................................................26

Appendix............................................................................................................................................31A.1 Overview of BIP10X's Hardcoded Parameters and Design Choices......................................31

A.2 Comparison of Different Block Size Evolution Proposals.....................................................32

A.3 Simulation Source Code and Simulation Tool........................................................................34

How to Use FreeMat Tool.........................................................................................................34

The Source Code (“BSL_change.m”).......................................................................................35

References..........................................................................................................................................37



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/8v) 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 of 114 days. Itgets updated once 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 2 or 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 secondTX Bitcoin transaction



vBSL_50 The 50%ile (=median) vote of the miners' votes from the last voting interval. Itis 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% steps acc. tothe 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 61 GB, with granularity in step increments of 9.05% [Rat3]

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

• Block size limit decision based on median (50% quantile) [Rat6] of all votes to avoid manipulation by a miner minority in either up or down direction.

• 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 votes don't

matter)◦ 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 vote is not restricted by above constraints, but a free vote

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 [Rat7].

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



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 miners 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 this 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 decrease this 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 Schedule

It 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 Deployment

When 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 determine

if 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 Phase1. 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 (sliding window). [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

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, ot that it votes for a fixed BSL value, or that it votes for a value that is by a specified factor greater than the actual block size of the current 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.

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 correspond 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*H)=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*H)=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) to it. Then the final nominal block size limit BSL_curr applicable for the next 1008 blocks (M+n*1008 to M+(n+1)*10081) 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 the average Actual Block Size, aABS, of the last 1008 blocks. Then apply min/max limits such that the constrained value lies in 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:◦ If vBSL_50 > 189/128*BSL_LongTermAvg, then reduce vBSL_50 on the BSE

resolution grid until it becomes 189/128*BSL_LongTermAvg.

Esleif 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 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 HeaderThe 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 = 0x00xSS = 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 = 0110 = 6 vote for BSL that is by factor 2^(6/8) → 1.6818 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.After the first block with size > 1 MB has occurred, legacy miners (incl. BIP101 miners) can no longer mine 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 actual block size and by BSL_LongTermAvg, which is a roughly 1yearaverage(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” function is all 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 given threshold

◦ The occurrence of overbooked blocks > 2*BSL_curr should not exceed another, stricter, 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(no) or 1(yes)) 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)

Part 2: Condition When Overbooking is Allowed

If OBR < 0.10 then it is allowed to create a block with size up to 4*BSL_currElseif OBR < 0.30 then it is allowed to create a block 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, 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 destroys 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 ValuesThere 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 value 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) 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 (or “state”).BIP10X specifies a periodic realignment every 1008 blocks, here's how 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, 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) after above realignment procedure!

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

(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 M+n*10081005 gets checked.

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 granularity 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 blocksize 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 peaks in terms of CPU



load or 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:“It [the coinbase scriptSig thing] is more complex to implement, because 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% it is a gooddesign 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 reasonable filled block of 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 factorof 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 to high values.In the next voting interval, some miners would tend to make “tactical votes”: To counter a tactical voter on the one edge who votes for extremely high values, the other side might decide to vote for extremely low values, with the intend that the final average turns out to be what theywant.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 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 (but smaller than 2*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.

[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).In summary, the method is easy to implement and to adapt, easy to dimension, and it shows favorable behavior.



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 3 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 initialied with the initial BSL, 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:



Appendix

A.1 Overview of BIP10X's Hardcoded Parameters and Design Choices

Voting 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% 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)

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



A.2 Comparison of Different Block Size Evolution ProposalsHere 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

Simulation was 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 solely by constraint (C2) % of BIP10X (the normal limit, not the stretched limit of 80% miner majority). % In case of growth, this corresponds to the case that >50% 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 % BSL increase, irrespective of the miner votes. % In case of decline, this corresponds to the case that >50% 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 % BSL decline, irrespective of the 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=8; % 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, 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: random_80percent_boost = 0.0;% probability that a BSL increase is boosted by >80% miner vote

% Random Event 2: random_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 then what it would otherwise be.

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

% %% #1) Initializations:

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

BSL_vector(1:52)=BSL_init_MB; % [in MByte] Initialise the BSL value for the first 52 weeks BSL_vector = [BSL_vector, nan*ones(1,N)];

% Granularity due to exponential representation of BSL, granularity = ca. 9.05% steps: upstep = 2^(1/8);% =1.09050773 : +9.0508% downstep = 1/2^(1/8);% =0.91700404 : 8.0300%

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

% %% #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 % Find largest possible BSL for week k: BSL_try = BSL_vector(k1);% first try with BSL of previous week if rand()<random_80percent_boost, incmax = incmax_yearAvg2;% boosted growth by >80% miner vote else incmax = incmax_yearAvg;% normal case end while BSL_try * upstep <= BSL_LongTermAvg*incmax,% Try to go up as much as possible BSL_try = BSL_try * upstep; end BSL_vector(k) = BSL_try; if rand()<random_one_step_less, % A random event causes the growth to be not quite as big as it could be: BSL_vector(k) = BSL_vector(k)/upstep; end 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 % Find smallest possible BSL for week k: BSL_try = BSL_vector(k1);% first try with BSL of previous week if rand()<random_80percent_boost, decmin = decmin_yearAvg2;% boosted decline by >80% miner vote else decmin = decmin_yearAvg;% normal case end



while BSL_try * downstep >= BSL_LongTermAvg*decmin,%Try go down as much as possible BSL_try = BSL_try * downstep; end BSL_vector(k) = BSL_try; if rand()<random_one_step_less, % A random event causes the decline to be not quite as big as it could be: BSL_vector(k) = BSL_vector(k)/downstep; end 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); 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


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

a hybrid mechanism for adaptively adjusting bitcoin's block size limit [bip10x]

Documents