<div dir="ltr"><div><div><div>Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my favorite.<br><br></div><div>I see two problems with proposal #2.<br></div>The first problem with proposal #2 is that, as we see in democracies, there is often a mismatch between the people conscious vote and these same people behavior. <br><br>Relying on an intentional vote made consciously by miners by choosing a configuration value can lead to twisted results if their actual behavior doesn't correlate with their vote (eg, they all vote for a small block size because it is the default configuration of their software, and then they fill it completely all the time and everything crashes).<br><br></div><div>The second problem with proposal #2 is that if Gavin and Mike are right, there is simply no time to gather a meaningful amount of votes over the coinbases, after the fork but before the Bitcoin scalability crash. <br></div><div><br></div>I like proposal #1 because the "vote" is made using already available data. Also there is no possible mismatch between behavior and vote. As a miner you vote by choosing to create a big (or small) block, and your actions reflect your vote. It is simple and straightforward.<br><br></div>My feelings on proposal #3 is it is a little bit mixing apples and oranges, but I may not seeing all the implications.<br><div><div><div><div><div><br><div class="gmail_quote">Le ven. 8 mai 2015 à 09:21, Matt Whitlock <<a href="mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Between all the flames on this list, several ideas were raised that did not get much attention. I hereby resubmit these ideas for consideration and discussion.<br>
<br>
- Perhaps the hard block size limit should be a function of the actual block sizes over some trailing sampling period. For example, take the median block size among the most recent 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, rather than having human beings guessing at what is an appropriate limit.<br>
<br>
- Perhaps the hard block size limit should be determined by a vote of the miners. Each miner could embed a desired block size limit in the coinbase transactions of the blocks it publishes. The effective hard block size limit would be that size having the greatest number of votes within a sliding window of most recent blocks.<br>
<br>
- Perhaps the hard block size limit should be a function of block-chain length, so that it can scale up smoothly rather than jumping immediately to 20 MB. This function could be linear (anticipating a breakdown of Moore's Law) or quadratic.<br>
<br>
I would be in support of any of the above, but I do not support Mike Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the road without actually solving the problem, and it does so in a controversial (step function) way.<br>
<br>
------------------------------------------------------------------------------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target="_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</blockquote></div></div></div></div></div></div></div>