rich1.0npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7xhttps://nostr.ae/npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7xnjumphttps://nostr.ae📅 Original date posted:2015-05-08 📝 Original message:Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my favorite. I see two problems with proposal #2. 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. 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). 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. 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. My feelings on proposal #3 is it is a little bit mixing apples and oranges, but I may not seeing all the implications. Le ven. 8 mai 2015 à 09:21, Matt Whitlock <bip at mattwhitlock.name> a écrit : > 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. > > - 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. > > - 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. > > - 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. > > 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. > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/6f9d5ecd/attachment.html>