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.