{"type":"rich","version":"1.0","author_name":"npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx","author_url":"https://nostr.ae/npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:Matt,\n\nIt seems you missed my suggestion about basing the maximum block size on\nthe bitcoin days destroyed in transactions that are included in the block.\nI think it has potential for both scaling as well as keeping up a constant\nfee pressure. If tuned properly, it should both stop spamming and increase\nblock size maximum when there are a lot of real transactions waiting for\ninclusion.\n\n- Joel\n\nOn Fri, May 8, 2015 at 1:30 PM, Clément Elbaz \u003cclem.ds at gmail.com\u003e wrote:\n\n\u003e Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my\n\u003e favorite.\n\u003e\n\u003e I see two problems with proposal #2.\n\u003e The first problem with proposal #2 is that, as we see in democracies,\n\u003e there is often a mismatch between the people conscious vote and these same\n\u003e people behavior.\n\u003e\n\u003e Relying on an  intentional vote made consciously by miners by choosing a\n\u003e configuration value can lead to twisted results if their actual behavior\n\u003e doesn't correlate with their vote (eg, they all vote for a small block size\n\u003e because it is the default configuration of their software, and then they\n\u003e fill it completely all the time and everything crashes).\n\u003e\n\u003e The second problem with proposal #2 is that if Gavin and Mike are right,\n\u003e there is simply no time to gather a meaningful amount of votes over the\n\u003e coinbases, after the fork but before the Bitcoin scalability crash.\n\u003e\n\u003e I like proposal #1 because the \"vote\" is made using already available\n\u003e data. Also there is no possible mismatch between behavior and vote. As a\n\u003e miner you vote by choosing to create a big (or small) block, and your\n\u003e actions reflect your vote. It is simple and straightforward.\n\u003e\n\u003e My feelings on proposal #3 is it is a little bit mixing apples and\n\u003e oranges, but I may not seeing all the implications.\n\u003e\n\u003e\n\u003e Le ven. 8 mai 2015 à 09:21, Matt Whitlock \u003cbip at mattwhitlock.name\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Between all the flames on this list, several ideas were raised that did\n\u003e\u003e not get much attention. I hereby resubmit these ideas for consideration and\n\u003e\u003e discussion.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of the actual\n\u003e\u003e block sizes over some trailing sampling period. For example, take the\n\u003e\u003e median block size among the most recent 2016 blocks and multiply it by 1.5.\n\u003e\u003e This allows Bitcoin to scale up gradually and organically, rather than\n\u003e\u003e having human beings guessing at what is an appropriate limit.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be determined by a vote of the\n\u003e\u003e miners. Each miner could embed a desired block size limit in the coinbase\n\u003e\u003e transactions of the blocks it publishes. The effective hard block size\n\u003e\u003e limit would be that size having the greatest number of votes within a\n\u003e\u003e sliding window of most recent blocks.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of block-chain\n\u003e\u003e length, so that it can scale up smoothly rather than jumping immediately to\n\u003e\u003e 20 MB. This function could be linear (anticipating a breakdown of Moore's\n\u003e\u003e Law) or quadratic.\n\u003e\u003e\n\u003e\u003e I would be in support of any of the above, but I do not support Mike\n\u003e\u003e Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the\n\u003e\u003e road without actually solving the problem, and it does so in a\n\u003e\u003e controversial (step function) way.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b6a95d5e/attachment.html\u003e"}