Dynamically Controlled Bitcoin Block Size Max Cap

I have tried to solve the maximum block size debate, depending on the previous block size calculation.

Requesting for comment - http://upalc.com/maxblocksize.php

Interesting. I am writing down something similar. Will share soon.

Upal Chakraborty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr:

> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Nobody is going to click that...

On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:

> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap <http://upalc.com/maxblocksize.php>*

*Assumption*: This article is for those, who already understand the bitcoin protocol and aware of the block size controversy. Details of the problem statement can be found in BIP 100 <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>. Satoshi's opinion regarding block size can be found here <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will be directly going into the solution without explaining the problem in details.

*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016 block each full node does a calculation to find the next target. We will do just another calculation here. Nodes will also calculate what % of blocks in the last difficulty period is higher than 90% of the maximum block size, which is 1 MB for now. If it is found that more than 90% blocks in the last difficulty period is higher than 90% of the maximum block size, then double the maximum block size. If not, then calculate what % of blocks in the last difficulty period is less than 50% of the maximum block size. If it is higher than 90%, then half the maximum block size. If none of the above condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take into account the first 2000 of the 2016, than the whole of 2016. This helps to avoid the calculation mistake if some of the last few blocks get orphaned.

*Reasoning*: This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty.

*Other Solutions of this Problem*:-

Making Decentralized Economic Policy <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by Jeff Garzik

Elastic block cap with rollover penalties <https://bitcointalk.org/index.php?topic=1078521> – by Meni Rosenfeld

Increase maximum block size <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin Andresen

Block size following technological growth <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments <https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon & Thaddeus Dryja

Please share your opinion regarding this solution below. For mail communication, feel free to write me at bitcoin [at] upalc.com.

> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Words cannot capture how much I wish Satoshi had put logic like this (or even just a simple block size doubling every reward halving) in place when he put in the "temporary" 1MB anti-spam block size limit...

I see problems to this approach. The biggest one I see is that a miner with 11% of hash power could sabotage block size increases by only ever mining empty blocks.

I haven't run any statistics or simulations, but I'm concerned that the interplay between the random distribution of transaction arrival and the random distribution of block times may lead to false signals.

A 90% full block 1 minute after the previous block is a more "serious" problem than a 90% full block 30 minutes after the previous block. A 90% full block after a 90% full block is a more "serious" problem than a 90% full block after an empty block.

I would expect a robust approach in this manner to look at block sizes weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the great schisms in this debate - those that believe blocks should always be full (or close to it), to encourage a "fee market" and to encourage off-chain transactions, and those that think that the blockchain should be useable by almost anyone for almost anything, implying there should always be spare space in blocks, with off-chain transactions reserved for microtransactions and zero-conf (and possibly low-fee transactions). At least, that's my take on it.

Rodney

>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> From: Btc Drak <btcdrak@gmail•com>
> To: Patrick Strateman <patrick.strateman@gmail•com>
> Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation•org>
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
>         Max Cap
> Message-ID:
>         <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw@mail•gmail•com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> wrote:
> > Nobody is going to click that...
>
> I guess I am nobody. Here's a copy of the text:-
>
> *Dynamically Controlled Bitcoin Block Size Max Cap
> <http://upalc.com/maxblocksize.php>*
>
> *Assumption*: This article is for those, who already understand the bitcoin
> protocol and aware of the block size controversy. Details of the problem
> statement can be found in BIP 100
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
> Satoshi's opinion regarding block size can be found here
> <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will
> be
> directly going into the solution without explaining the problem in details.
>
>
> *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
> block each full node does a calculation to find the next target. We will do
> just another calculation here. Nodes will also calculate what % of blocks
> in the last difficulty period is higher than 90% of the maximum block size,
> which is 1 MB for now. If it is found that more than 90% blocks in the last
> difficulty period is higher than 90% of the maximum block size, then double
> the maximum block size. If not, then calculate what % of blocks in the last
> difficulty period is less than 50% of the maximum block size. If it is
> higher than 90%, then half the maximum block size. If none of the above
> condition satisfies, keep the maximum block size as it is.
>
> Please note that, while calculating the % of blocks, it is better to take
> into account the first 2000 of the 2016, than the whole of 2016. This helps
> to avoid the calculation mistake if some of the last few blocks get
> orphaned.
>
>
> *Reasoning*: This solution is derived directly from the indication of the
> problem. If transaction volume increases, then we will naturally see bigger
> blocks. On the contrary, if there are not enough transaction volume, but
> maximum block size is high, then only few blocks may sweep the mempool.
> Hence, if block size is itself taken into consideration, then maximum block
> size can most rationally be derived. Moreover, this solution not only
> increases, but also decreases the maximum block size, just like difficulty.
>
>
> *Other Solutions of this Problem*:-
>
> Making Decentralized Economic Policy
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
> Jeff Garzik
>
> Elastic block cap with rollover penalties
> <https://bitcointalk.org/index.php?topic=1078521> ? by Meni Rosenfeld
>
> Increase maximum block size
> <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by
> Gavin
> Andresen
>
> Block size following technological growth
> <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
>
> The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
> <https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
> Thaddeus Dryja
>
>
> Please share your opinion regarding this solution below. For mail
> communication, feel free to write me at bitcoin [at] upalc.com.
>
>

I've been sharing a similar solution for the past 2 weeks. I think 2016 blocks is too much of a wait, I think we should look at the mean block size during the last 60-120 minutes instead and avert any crisis caused by transactional spikes that could well be caused by organic use of the network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network starts working as imagined, XYZ startup really kicks ass and succeeds in a couple of major cities with major PR push)

Pseudo code in Python https://gist.github.com/gubatron/143e431ee01158f27db4

My idea stems from a simple scalability metric that affects real users and the desire to use Bitcoin: Waiting times to get your transactions confirmed on the blockchain. Anything past 45mins-1 hour should be unnacceptable.

Initially I wanted to measure the mean time for the transactions in blocks to go from being sent by the user (initial broadcast into mempools) until the transaction was effectively confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins)

When blocks get full, people start waiting unnaceptable times for their transactions to come through if they don't adjust their fees. The idea is to avoid that situation at all costs and keep the network churning to the extent of its capabilities, without pretending a certain size will be right at some point in time, nobody can predict the future, nobody can predict real organic usage peaks on an open financial network, not all sustained spikes will come from spammers, they will come from real world use as more and more people think of great uses for Bitcoin.

I presented this idea to measure the mean wait time for transactions and I was told there's no way to reliably meassure such a number, there's no consensus when transactions are still in the mempool and wait times could be manipulated. Such an idea would have to include new timestamp fields on the transactions, or include the median wait time on the blockheader (too complex, additional storage costs)

This is an iteration on the next thing I believe we can all agree is 100% accurately measured, blocksize. Full blocks are the cause why many transactions would have to be waiting in the mempool, so we should be able to also use the mean size of the blocks to determine if there's a legitimate need to increase or reduce the maximum blocksize.

The idea is simple, If blocks are starting to get full past a certain threshold then we double the blocksize limit starting the next block, if blocks remain within a healthy bound, transaction wait times should be as expected for everyone on the network, if blocks are not getting that full and the mean goes below a certain threshold then we half the maximum block size allowed until we reach the level we need. Similar to what we do with hashing difficulty, it's something you can't predict, therefore no fixed limits, or predicted limits should be established.

On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> I haven't run any statistics or simulations, but I'm concerned that the
> interplay between the random distribution of transaction arrival and the
> random distribution of block times may lead to false signals.
>

You could just take the average of all the block sizes for the last 2016 window.

If average of last 2016 > 50% of the limit, then increase by 6.25% Otherwise, decrease by 6.25%

This means that the average would be around 50% of the limit. This gives margin to create larger blocks when blocks are happening slowly.

A majority of miners could force the limit upwards by creating spam but full blocks.

It could be coupled with a hard limit that grows at whatever is seen as the maximum reasonable. This would be both a maximum and a minimum.

All of these schemes add state to the system. If the schedule is predictable, then you can check determine the maximum block size purely from the header and coinbase.