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