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 <btcd...@gmail.com> > To: Patrick Strateman <patrick.strate...@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= > v...@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. > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
