Blocksize debate | SeeBitcoin

Bitcoin rival has a major vulnerability which could help Bitcoin miners to destroy it in 2020

TLDR: Due to a flawed emergency difficulty adjustment at its creation, Bitcoin Cash is now running ahead of the Bitcoin blockchain. Since future supply ‘halvenings’ should occur around 48 days before the Bitcoin network, it creates a window where it is ‘half price’ to 51% attack the network. The mere threat could cause the value to fall in anticipation, creating a feedback loop that makes such an attack increasingly inevitable and its outcome even more devastating.

Supporters of Bitcoin Cash (also called BCH and bcash) love to talk about a hypothetical “flippening”, a scenario in which a rise in the value of BCH would see miners switch away from the main Bitcoin blockchain causing the block production speed there to slow. They believe that with the Bitcoin blockchain operating at capacity, the network performance would suffer thus further reducing the value of Bitcoin and increasing the value of BCH which has a higher onchain capacity.

This, they speculate, would create a feedback loop, ultimately resulting in the Bitcoin blockchain completely grinding to a halt as miners jump ship for the more profitable BCH chain which would rise triumphant and replace Bitcoin as #1 cryptocurrency.

This is all pie in the sky fantasy, completely misunderstanding the complex and mature ecosystem that has formed and the incentives of those who operate within it. It simply will not happen. I am simultaneously amused by and feel bad for those who invest heavily in altcoins in the naive hope a flippening in value will occur.

However, there is a flippening of sorts looming for BCH that I have not yet noticed any consideration given towards.

One of the rules of the Bitcoin network, that BCH also inherited, is that every 210,000 blocks (approx 4 years) the supply of new coins created with each block is halved, in a much celebrated event known as “the halvening”. This also causes the profitability of mining to halve since in 2020 the supply of new coins created will fall from 12.5 to 6.25 per block.

To uncover why this may create a problem for BCH we must look back to its creation. In order to deviate from the Bitcoin network and create a new version, it underwent a process known as a hard fork.

The main rule change was to increase the block size, however as the BCH developers knew there would likely not be much support for their fork they also added a bit of code called an emergency difficulty adjustment (EDA). This is because the difficulty determines how frequently new blocks are created. If you reduce the volume of miners without reducing the difficulty, block creation can take a much longer time. Losing 80% of the mining hashrate would result in blocks only being created every 50 minutes instead of 10, and consequently the mechanism to readjust difficulty every 2016 blocks could take as long as 10 weeks instead of the usual 2. The EDA meant that instead of adjusting the difficulty every 2016 blocks it could readjust down based on just the last 6 blocks.

As with many ‘simple’ changes, this had major unintended consequences as it created an incentive for miners to collectively hold off on mining until the difficulty was really low, and then suddenly start mining blocks again really quickly at high profitability. This caused huge fluctuations in difficulty and at times made the BCH network grind to a halt while no blocks were being created, while at other times they were being churned out in seconds.

The BCH network had no choice but to introduce yet another hard fork to fix the difficulty adjustment algorithm. Hard forks require that every single participant on the network upgrades their software or gets kicked off, so handing them out like Oprah gives away cars is not ideal.

Oprah hard fork giveaway

By the time the problem was resolved, the BCH block count had rocketed ahead of the main Bitcoin blockchain.

At the time of writing, BCH is on block #541236 while Bitcoin is on block #534392, a difference of 6,844 which at 10 minutes on average means that the BCH halvening is currently expected to occur approximately 48 days before it does on the Bitcoin blockchain.

At that point, the reward for creating a new BCH block will fall to 6.25, while on the Bitcoin blockchain it will remain at 12.5 (plus higher fees).

The market currently values BTH at around 10% the value of a Bitcoin and the hashrate roughly correlates with the price.

That would mean, at current prices, to mount a 51% attack on BCH would require just over 11% of the Bitcoin hashrate switching over to make that attack.

For a 48 day window in 2020 (and then every 4 years) that dynamic will change, and the cost to attack the network will suddenly halve. Suddenly just 6% of the Bitcoin hashrate would be sufficient to mount a 51% attack against BCH, well within the capabilities of a number of mining pools.

There are a number of ways to ‘short’ cryptocurrencies. Shorting is basically betting that a value will fall, and profiting if it does. Anyone mounting a 51% attack successfully would cause the value of that cryptocurrency to fall, with shorting creating an easy opportunity for them to profit.

A 51% attack itself provides other opportunities for an attacker to profit, most notably through a double spend attack. This could be achieved by depositing a large quantity of BCH onto an exchange, converting and withdrawing them as something else, and then reversing the original transaction so the exchange is out of pocket and the attacker keeps their original BCH.

However an attacker chooses to profit from a 51% attack, the outcome will almost always be a fall in value of the cryptocurrency as people lose both trust in its security and their money.

These rough figures are based on a BCH/BTC rate of 0.1 and ignore the even higher fees available on the Bitcoin network. Since the value of BCH has already been falling for some time it could easily be much lower by 2020. This means an attack would become even cheaper and even more likely.

The increased risk of a 51% attack during period is likely to decrease the price in anticipation of it. This could create a feedback loop where the increased risk caused by the price falling causes the price to fall even further. Miners could engage in all kinds of game theory here: merely hinting they are considering attacking the network would likely cause a downward pressure on price making the cost of an attack even lower.

In summary, hard forks are risky and can introduce a whole host of unintended consequences. While the BCH community may now think their difficulty adjustment woes are behind them, there may be other nasty surprises lurking ahead.

The Nuclear Option: BIP148 + MR POWA

This idea is highly contentious as it would guarantee a viable chain of Bitcoin with SegWit activated whether BIP148 gained sufficient support or not. I am not necessarily advocating it – just putting it out for discussion. While the downside is that it could permanently split the network, the upside is that it could heap additional pressure on miners to follow the BIP148 chain and ensure a minimally disruptive upgrade to SegWit. This is pure game theory.

MR POWA (Mining Reactive Proof of Work Addition) is a method to introduce an additional proof of work to a blockchain in response to a detected mining behaviour.

In the case of BIP148, the criteria for activation could be when the software detects a non-BIP148 compliant chain that is 144 blocks (24 hours) ahead of a BIP148 compliant chain.

At this stage the software would change its consensus rules (hard fork) to do two things:

Lower the difficulty for existing PoW method (SHA256).
Introduce a second POW method, such as Scrypt or Ethash, that is incompatible with SHA256 hardware but already has an established mining industry for altcoins.
The difficulty should be low, and blocks will initially be found much more quickly than every 10 minutes until the difficulty adjusts. Each method would have its own difficulty. It could be a requirement that POW methods alternate to neutralise attacks from the other chain.

This would guarantee SegWit activation. Anybody who is already running a BIP148 node could just as easily run a BIP148 + MR POWA node. This could not realistically be supported by Core and would have to be implemented in a grassroots movement, similar to BIP148.

Ideally, it would just force the miners to follow the BIP148 chain (or risk the value of their hardware being hurt) and the code would never be activated. MR POWA would mean BIP148 miners would no longer need to ‘hold their nerve’ as they would be guaranteed a viable chain and rewarded for their early support.

Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I’m very worried about the state of miner centralisation in Bitcoin.

I always felt the centralising effects of ASIC manufacturing would resolve themselves once the first mover advantage had been exhausted and the industry had the opportunity to mature.

I had always assumed initial centralisation would be harmless since miners have no incentive to harm the network. This does not consider the risk of a single entity with sufficient power and either poor, malicious or coerced decision making. I now believe that such centralisation poses a huge risk to the security of Bitcoin and preemptive action needs to be taken to protect the network from malicious actions by any party able to exert influence over a substantial portion of SHA256 hardware.

Inspired by UASF, I believe we should implement a Malicious miner Reactive Proof of Work Additions (MR POWA).

This would be a hard fork activated in response to a malicious attempt by a hashpower majority to introduce a contentious hard fork.

The activation would occur once a fork was detected violating protocol (likely oversize blocks) with a majority of hashpower. The threshold and duration for activation would need to be carefully considered.

I don’t think we should eliminate SHA256 as a hashing method and change POW entirely. That would be throwing the baby out with the bathwater and hurt the non-malicious miners who have invested in hardware, making it harder to gain their support.

Instead I believe we should introduce multiple new proofs of work that are already established and proven within existing altcoin implementations. As an example we could add Scrypt, Ethash and Equihash. Much of the code and mining infrastructure already exists. Diversification of hardware (a mix of CPU and memory intensive methods) would also be positive for decentralisation. Initial difficulty could simply be an estimated portion of existing infrastructure.

This example would mean 4 proofs of work with 40 minute block target difficulty for each. There could also be a rule that two different proofs of work must find a block before a method can start hashing again. This means there would only be 50% of hardware hashing at a time, and a sudden gain or drop in hashpower from a particular method does not dramatically impact the functioning of the network between difficulty adjustments. This also adds protection from attacks by the malicious SHA256 hashpower which could even be required to wait until all other methods have found a block before being allowed to hash again.

50% hashing time would mean that the cost of electricity in relation to hardware would fall by 50%, reducing some of the centralising impact of subsidised or inexpensive electricity in some regions over others.

Such a hard fork could also, counter-intuitively, introduce a block size increase since while we’re hard forking it makes sense to minimise the number of future hard forks where possible. It could also activate SegWit if it hasn’t already.

The beauty of this method is that it creates a huge risk to any malicious actor trying to abuse their position. Ideally, MR POWA would just serve as a deterrent and never activate.

If consensus were to form around a hard fork in the future nodes would be able to upgrade and MR POWA, while automatically activating on non-upgraded nodes, would be of no economic significance: a vestigial chain immediately abandoned with no miner incentive.

I think this would be a great way to help prevent malicious use of hashpower to harm the network. This is the beauty of Bitcoin: for any road block that emerges the economic majority can always find a way around.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

A quick reminder on why we can’t depend on the block reward until 2140

I used to argue that we shouldn’t worry about a lack of fees because blocks were subsidised ‘until 2140’. I thought it would be a problem ‘for the future to worry about’. I figured the world would have changed so much by then that there was no point limiting ourselves now, and that they’d be able to ‘figure it out’.

Then I realised that I was wrong – 2140 isn’t the year to worry about.

We are now closer to 2024 than we are to 2009 when Bitcoin began. In 2024 the block reward will fall to just 3.1BTC.

In 2028 it will be 1.6BTC, and in 2032 we’ll be at less than 0.8BTC. This reward will continue falling for another 108 years until block subsidies end in 2140 – the year I naively perceived as the time the lack of block reward would become ‘a problem’.

A simple look at the numbers tells us this is something we need to consider a lot sooner.

In February I analysed how much the fees had increased. On 6th March 2015 the average cost over 10 days for 1MB of transactions was $67.

On 6th March 2017, that number has increased to $1912.

This is supply and demand in action, literally how free markets work. When there is an abundance of something it becomes extremely cheap. When in short supply it becomes expensive.

People argue that if we made the blocks bigger so they weren’t full, the miners would be able to include more transactions so they could receive more reward.

Let’s take an objective look at the facts. The numbers show us that when blocks aren’t full miners have, even in recent years with high Bitcoin value, accepted less than $67 per MB.

Only when the blocks have become full has the pressure on fee prices skyrocketed to $1912 per MB.

This means that at $67 per MB to earn the same fees miners would right now need to be mining 29MB blocks.

Even if this didn’t have centralisation issues, the transaction volume just isn’t there yet to achieve it.

Another argument can be made that the current 12.5BTC reward means this is less of an issue right now – and that is a very valid point. We do have room to increase the block capacity without a short term fear over mining incentive, and we should if the miners will let us.

The concern is that in 7 years time we’re going to be mining blocks with just 3.1BTC of reward. The simple and indisputable fact is that the less reward there is for mining a block the less secure the network is, and this is a problem we’re going to face a lot sooner than 2140.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

How user activated soft forks (UASF) work and why they might solve the blocksize debate too

For a soft fork to activate miners currently are required to signal their support. For SegWit that requires 95% of blocks over a 2016 block window signalling in favour.

Currently the Bitcoin network has around 6,000 nodes. ~5,000 of those are running Bitcoin Core, and ~3,000 nodes are running Bitcoin Core versions that fully support SegWit (>=0.13.1).

Those 3,000 nodes, despite being SegWit ready, can currently do nothing more than wait for miners to activate it. This just isn’t happening, and they are being denied all the benefits that come along with it.

UASF would mean there is no signalling by miners for activation. Instead a new version of the Bitcoin software is released and installed on nodes which has an agreed activation point in the future.

At the time of writing we’re at block #455855. If we wanted to activate SegWit in 90 days time (approximately 12,960 blocks), the new version of the software could say “from block #468,815 only accept blocks that support SegWit”.

Let’s imagine that by block #468815, 60% of nodes have upgraded to this new version of the software. In addition a number of large exchanges and Bitcoin businesses have also publicly announced their support and upgraded.

This gives miners a conundrum. If they don’t create SegWit compatible blocks from that point all those nodes and businesses will completely ignore the blocks they create. This would prove very expensive.

SegWit blocks will be backwards compatible, as nodes that haven’t upgraded their software will still recognise them as valid.

This means that the odds of SegWit activation succeeding are massively stacked in its favour, as the miners are the only ones who incur an economic cost if they make an incorrect decision about activating. By far the safest option is to mine blocks compatible with SegWit as these will be accepted by 100% of nodes, rather than the 40% of non-upgraded nodes and economic minority.

So that’s the basics. The nodes basically tell the miners that if they don’t play ball they will be ignored. It would take an incredible amount of nerve (or stupidity) for a miner to refuse to mine SegWit compatible blocks when such a huge part of the network will suddenly start invalidating their work.

If just 51% of miners update then SegWit would activate without any issues.

I don’t believe SegWit would struggle to gain miner consensus, but in the unlikely event that over 51% of miner hashrate refused to switch this would create a fork in the network with non-upgraded nodes seeing one version of the blockchain, and upgraded nodes seeing another.

I believe a more likely outcome is that a rival implementation of the bitcoin software would use the activation point as a catalyst and attempt to rally support for and introduce a change of their own.

This wouldn’t be a property of UASF itself, but an activation point creates a natural window of opportunity to force the community to make a choice between rival visions.

Instead of a soft fork, a rival implementation could activate a hard fork block size increase. In addition they would likely need to change how quickly the difficulty is adjusted and hopefully add replay protection.

This would lead to all nodes and miners having a clear choice between two directions for Bitcoin. The likely reason a rival implementation wouldn’t attempt this is because they feared humiliation, but a set activation point would present a perfect opportunity to also force a referendum on the block size debate to those with the conviction to back their belief.

There would likely be just one winner, with an economically insignificant altcoin created on the other side. The block size debate would finally be settled once and for all.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

A tragedy on our hands? What if miners would rather have higher fees than bigger blocks?

We’ve got so caught up in the whole SegWit and Bitcoin Unlimited dispute that there’s something we may all have overlooked.

For either of these changes to be activated requires miner support, of which neither side has anywhere near enough.

What if the reason we’re seeing no progress is because miners don’t want the block size to increase?

While we’re all desperate to see scaling solutions, the miners are sitting there and quietly collecting record fees.

I’ve compiled the fee data over the last 2 years and created 10 day averages of the price in USD.

Here are the results:

2017-02-2yearsfeespermb

2017-02-2yearsfeesperblock

The above graph shows the fees miners receive on average per block.

It also shows what would have happened if the initial rate of $60 per MB had continued as the blockchain grew.

As you can see in the last two years miners have gone from earning fees of next to nothing per block ($25) to now averaging over $1000.

This rate equates to more than $52m extra per year for miners compared to two years ago, as demonstrated by the graph below:

2017-02-2yearsfeesperyear

Are the miners happy with the status quo? They sit back quietly collecting record fees while the rest of the community fights amongst itself.

The most recent rate equates to $54m in fees per year. At $1000 per BTC there is currently $657m new Bitcoins created each year. This means fees currently make up 8.2% of miner revenue and is growing exponentially.

Doubling the blocksize would not see fees halve. More likely we’d see fees fall to the rate when blocks were half full. This would see miner fee revenues falling from around $1100 per block to perhaps $70 per block – and we’re asking them to impose this upon themselves!

A real tragedy of the commons may be upon us. It doesn’t matter what scaling option you support if the miners won’t implement any of them, instead opting to accumulate as many Bitcoins as possible until other scaling solutions they cannot impede emerge.

I have my suspicions that on the whole miners currently favour Core, but are happy to exploit the community disharmony and delay on-chain scaling for as long as physically possible. Their actions only heighten the tension and inflicts real damage.

Instead of being divided, let’s unite in putting pressure on the miners. Until we know we can even overcome this obstacle the rest of our debate may be a futile waste of energy.

Nothing unites humans like a common enemy.

If you liked this article please consider donating now to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE

Cynical miner power grabs are healthy for Bitcoin and should not be feared. Cryptoeconomics will always triumph.

There are competing visions for Bitcoin.

I support the Core scaling roadmap. I believe in prioritising off chain scaling where possible but also for SegWit and hard forks to increase the block size as required to allow Bitcoin to grow exponentially.

Others believe the block size should be left to the miners. I think this could enable a path towards centralisation and fundamentally change Bitcoin’s value proposition.

Some miners are signalling for Bitcoin Unlimited – a hard fork to enable this. It is rumoured some would attack the other chain in the event of a fork to ensure there is no permanent split and their vision is realised.

Miners are within their rights to attack another chain. This is crypto economics in action, if you don’t like it then cryptocurrency by its nature is not for you.

If miners attempt this power grab they are taking a huge risk and we are within our rights to plan for how we could mitigate it and punish them. There may be a permanent fork, but as long as one becomes economically dominant this isn’t a problem. When the battle is over the loser will be just another altcoin.

I’m skeptical this power grab will come to fruition but if it does I believe the best approach would be increasing the proof of work methods from 1 to 4.

Ideally a ‘Quad Core’ fork could trigger when 75% of miners are signalling for an implementation like BU. This would allow the remaining 25% to bring their hashpower to the new chain and abandon the other one. The opportunity should also be taken to activate SegWit and introduce a block size capacity increase.

The addition of Scrypt, Ethash, and Equihash methods of PoW would provide a mix of CPU and memory intensive implementations and improve diversity of hardware. Each having a target block difficulty of 40 minutes would retain 10 minute block intervals overall. This should reduce centralisation and these are proven PoW methods in use with other altcoins and so there would be a willing mining infrastructure already in place.

If successful this would prove bitcoin resistant to hostile miners.

I actually think this would be quite exciting. Each side of the fork would have a clear mandate for their scaling vision and the market would decide the winner. This is exactly how crypto economics works and should be celebrated rather than feared.

No politics, pure numbers: if the blockchain grew at its current rate and hard drive prices fell at their current rate – what storage cost in 20 years?

I decided to look objectively at one of the costs of scaling on chain. This is pure numbers, no politics.

Storage is currently a very small part of the cost of running a full node. The block chain is around 100GB. With storage currently available from as little as $0.019 per GB, that’s just $1.90.

This is just a look at storage alone, it does not consider bandwidth, CPU or electricity requirements of operating a full node.

According to http://www.statisticbrain.com/average-cost-of-hard-drive-storage/ the 6 years from 2010-2016 saw the cost per GB fall from $0.09 to $0.019 – a fall of 79%.

This equates to an average fall in price of 23% each year.

From 1995 to 2000 the cost per GB fell by 99% – an average of 60% each year.

This represents a fall in the rate at which prices drop by 5% each year on average.

I will perform two calculations:

Assuming the price continues to fall by 23% each year
Reducing the rate at which the prices fall by 5% each year

I will also estimate blockchain growth based on actual current levels of growth.

For example the blockchain sizes: 2013: 13,490MB, 2014: 27,840MB, 2015: 53,700MB equates to an increase of 2014: 14,350MB, 2015: 25,860MB, so 2015 saw an increase of 80%. Through 2012 to 2016 the blockchain transactions grew by an average of 88.6% each year (used in calculations).

This gives the following results for the next 20 years:

Year ending	Blockchain Size (MB)	Annual Increase (MB)	Average block size (MB)	Cost per GB (USD)	Storage cost	Cost per GB (5% slowdown)	Storage cost
2012	4270	3637	0.1	0.06	$0.25	0.06	$0.25
2013	13490	9220	0.2	0.05	$0.66	0.05	$0.66
2014	27840	14350	0.3	0.03	$0.82	0.03	$0.82
2015	53700	25860	0.5	0.022	$1.15	0.022	$1.15
2016	96345	42645	0.8	0.019	$1.79	0.019	$1.79
2017	176759	80414	1.5	0.01463	$2.53	0.0148485	$2.56
2018	328391	151633	2.9	0.0112651	$3.61	0.011766323	$3.77
2019	614318	285927	5.4	0.008674127	$5.20	0.009446048	$5.67
2020	1153477	539159	10.3	0.006679078	$7.52	0.007676459	$8.65
2021	2170144	1016667	19.3	0.00514289	$10.90	0.006310283	$13.37
2022	4087226	1917083	36.5	0.003960025	$15.81	0.005243396	$20.93
2023	7702182	3614956	68.8	0.003049219	$22.94	0.004401214	$33.10
2024	14518739	6816557	129.7	0.002347899	$33.29	0.003729648	$52.88
2025	27372412	12853672	244.6	0.001807882	$48.33	0.003189008	$85.24
2026	51609997	24237585	461.1	0.001392069	$70.16	0.002749851	$138.59
2027	97313708	45703711	869.6	0.001071893	$101.87	0.002390104	$227.14
2028	183495118	86181409	1639.7	0.000825358	$147.90	0.002093056	$375.06
2029	346003480	162508363	3091.9	0.000635526	$214.74	0.001845931	$623.73
2030	652438106	306434626	5830.2	0.000489355	$311.79	0.001638882	$1,044.21
2031	1230267939	577829833	10993.7	0.000376803	$452.70	0.001464248	$1,759.20
2032	2319855365	1089587426	20730.4	0.000290138	$657.30	0.001316023	$2,981.43
2033	4374440803	2054585438	39090.3	0.000223407	$954.37	0.001189464	$5,081.29
2034	8248679087	3874238284	73710.8	0.000172023	$1,385.71	0.001080796	$8,706.19
2035	15554153957	7305474870	138993.1	0.000132458	$2,011.98	0.000986992	$14,992.02
2036	29329755549	13775601592	262092.9	0.000101992	$2,921.30	0.000905613	$25,938.87
2037	55305780734	25976025185	494216.6	7.85342E-05	$4,241.60	0.000834677	$45,080.52

Assuming the optimistic scenarios that Bitcoin continues to achieve the levels of growth it has the last 4 years for the next 20, the cost of storage hardware alone to operate a full node would be $4,241.60 by 2037 – assuming the price of storage continues to fall rapidly.

If the rate at which storage gets cheaper continues to fall by around 5% each year, the cost for storage hardware alone would be $45,080 by 2037.

That’s just the numbers based on past performance. Past performance is no guarantee of future results.

Like this research? Please consider donating to 1H2zNWjxkaVeeE3yX6uVqng5Qoi6gGvYTE and I’ll try and find the time to do more.

I analysed 24h worth of transaction fee data and this is what I discovered

The idea of allowing of allowing miners to increase the blocksize with demand is an interesting one but creates a problem: miners can game such a system by filling the blockchain with transactions at zero cost.

Asking miners to pass on a portion of the transaction fees to the next block would solve this problem as the miner would then incur a cost. Unfortunately this introduces a new problem: miners are incentivised to accept fees away from the blockchain (out of band).

What if there were a way that could not be manipulated without an economic cost to the miner for doing so?

I decided to do a little analysis of the last 24 hours worth of transaction fees:

Satoshis/byte group	Transactions	MB used	BTC fee	Cumulative MB %	Cumulative BTC %
0	81	0	0	0.0%	0.0%
1-10	686	0.3	0.02	0.2%	0.0%
11-20	2588	1.2	0.18	1.0%	0.2%
21-30	3755	1.7	0.43	2.2%	0.5%
31-40	2677	1.2	0.42	3.0%	0.8%
41-50	13654	6.3	2.84	7.2%	3.1%
51-60	15052	7	3.85	11.9%	6.2%
61-70	108748	50.2	32.63	45.8%	32.4%
71-80	27432	12.7	9.53	54.3%	40.0%
81-90	32969	15.2	12.92	64.6%	50.4%
91-100	31188	14.4	13.68	74.3%	61.3%
101-110	13704	6.3	6.62	78.6%	66.7%
111-120	38051	17.6	20.24	90.4%	82.9%
121-130	4510	2.1	2.63	91.8%	85.0%
131-140	6294	2.9	3.92	93.8%	88.1%
141-150	2793	1.3	1.89	94.7%	89.7%
151-160	3021	1.4	2.17	95.6%	91.4%
161+	14015	6.5	10.73	100.0%	100.0%
Totals	321218	148.3	124.7

I collected data on evening of 10th January 2017 . The transaction data came from https://bitcoinfees.21.co/.

I used an average transaction fee of 462 bytes from here, and also had to average out satoshis/byte groups. Despite multiple data sources and rounding I was happy with how closely these calculations tallied up with the 24 hour stats at https://blockchain.info/stats:

Blocks Mined	150
Total Transaction Fees	118.84277985 BTC
No. of Transactions	313900

What does the data tell us?

It compares fee level groups in two ways:

How much space they use
What fees they generate

This shows how the fees generated and capacity used were distributed:

A fairly expected distribution, no odd outliers.

The cumulative BTC column in our chart shows us that the median economic fee is around 90 satoshis/byte.

What’s the idea?

I wondered if we could use this data to generate a threshold to calculate whether the network is ready for a block size increase.

Let’s say we need blocks to be considered 75% full for miners to activate an increase.

If we did that currently there is no cost to the miners to fill every block with transactions and force an increase as they get all the fees reimbursed.

What if we discounted all transactions of a fee below half the economic mean for the threshold? That would equate to around 45 satoshis/byte.

From the table we can see that around 95% of transactions are above this level. Since the blocks are consistently over 95% full at the moment and we’re counting 95% of the transactions toward the threshold, 0.95 * 0.95 gives us a figure of over 90% – well above the required level.

How could we stop miner manipulation?

Well, technically we can’t. We can disinsentivise manipulation by making it expensive though.

I’ve taken the original figures and reduced them by 25% to simulate less full blocks. I’ve then filled this freed up space with the cheapest but non-free transactions. This shows what it would look like if miners themselves tried to fill blocks with cheap transactions to activate a block size increase.

As you can see the manipulation is obvious but the protocol cannot see charts. We need to calculate how full the blocks would be considered for activation purposes in this scenario.

Since 25% of transactions are in the 1-10 satoshis/byte group they are discounted from the calculation.

Infact only around 72% of the transactions are above the 45 satoshis/byte required. 0.72 * 0.95 gives 68.4% full blocks for activation purposes – short of the 75% threshold.

Getting to the point

There are benefits to allowing miners to signal for block size increases. It’s quicker and less risky than hard forking each time for a start.

The problem of miners accepting fees out of band to avoid paying to signal for an increase can be completely mitigated – if miners do not vote for a block size increase they can keep 100% of their transaction fees as normal.

If there is consensus, miners passing transaction fees to the next block will average itself out. Only miners who consistently signal for a block size increase against consensus will incur an economic cost.

Signalling to increase the block size while simultaneously receiving fees out of band is counter-productive as those transactions will not count towards the reaching the activation threshhold.

While it may superficially appear the case, zero and low fee transactions are not punished under this implementation. They are effectively just factors in a scoring system when miners are suggesting additional block space is required. Remember that miners currently cannot signal for an increase at all, so this does not alter any fundamentals or discourage low fee transactions when there is capacity.

Thank you for reading, let me know any thoughts in the comments!

Dynamic block size with economic safeguards – could this be the solution that we can all get behind?

One side of the block size debate wants to hand over control of the block size to the miners. Many fear such an implementation would cause catastrophic failures of consensus, and that miners could even be incentivised to bloat the block size at a rate that overly compromises Bitcoin’s decentralistion.

Others are worried that scaling solutions such as Lightning Network and sidechains will take too long and not achieve sufficient gains, stifling Bitcoin’s network effect and preventing its continued exponential growth.

What if there were a way to simultaneously allow for exponential growth on chain if needed – allowing time for layer two solutions to take some heat off the chain, but also creating an economic disincentive for miners trying to inflate the block size arbitrarily.

Such a solution should allow for an exponential increase in block size if miners were in consensus, but require they face an economic risk when signaling for a block size increase where there was no consensus. Cryptoeconomics is built on incentive game theory, why not introduce it here?

Allowing the block size to change dynamically with demand would reduce the risk of requiring additional contentious block size hard forks and hostile debate. I fear a simple 2MB increase would reignite the debate almost as soon as it was activated, we need to buy as much time as possible.

Any solution is going to be a compromise, but by allowing a few years of exponential growth with strict safeguards and appropriate economic incentives we can hopefully achieve that.

So how do we do it?

My basic idea is for miners to vote in each block to increase the block size.

Allowing for exponential growth would mean that the block size could double every year.

This would be achieved by each of the previous 2016 blocks voting to increase the block size by the maximum amount of 2.7% each time. An increase of 2.7% every 2 weeks would result in an annual block size increase of 99.9% (rounding).

We only need to use 3 bits for miners to vote on block size:
000 = not voting
001 = vote no change
011 = vote decrease 2%
101 = vote increase 1.35%, pay 10% of transaction fees to next block
111 = vote increase 2.7%, pay 25% of transaction fees to next block

Not including any transactions in a block will waive a miners’ right to vote.

Each block is a vote, and the block size change could be calculated by averaging out all the votes over 2016 blocks.

In order to achieve an increase in block size, the blocks must also have been sufficiently full to justify one. Transactions with no fee and perhaps outliers far from the mean tx fee/kb should perhaps not be included.

By asking miners to pay a percentage of their transaction fees to the miner of the next block, you discourage miners from stuffing the blocks with transactions to artificially inflate the block size.

If miners are in unanimous agreement that the block size needs to increase, the fees would average out and all miners should still be equally rewarded. Only miners trying to increase the block size when consensus is not there would incur a cost.

There should be a limit on the maximum increase, perhaps 8MB. This isn’t a permanent solution, it is just to create time for Bitcoin to progress, and then re-evaluate things further down the line. Combined with SegWit this should provide a reasonable balance between satisfying those who are worried about missing out on exponential growth for a few years if LN and other solutions are not as fast or effective as hoped.

This is my rough idea for trying to find a compromise we can all get behind. Please let me know any thoughts or suggestions in the comments.