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 > To: Patrick Strateman > Cc: Bitcoin Dev > Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size > Max Cap > Message-ID: > 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 > * > > *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 > . > Satoshi's opinion regarding block size can be found here > . 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 > - by > Jeff Garzik > > Elastic block cap with rollover penalties > ? by Meni Rosenfeld > > Increase maximum block size > - by > Gavin > Andresen > > Block size following technological growth > - by Pieter Wuille > > The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments > - 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. > >