rich1.0npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrxhttps://nostr.ae/npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrxnjumphttps://nostr.ae📅 Original date posted:2015-05-08 📝 Original message:Matt, It seems you missed my suggestion about basing the maximum block size on the bitcoin days destroyed in transactions that are included in the block. I think it has potential for both scaling as well as keeping up a constant fee pressure. If tuned properly, it should both stop spamming and increase block size maximum when there are a lot of real transactions waiting for inclusion. - Joel On Fri, May 8, 2015 at 1:30 PM, Clément Elbaz <clem.ds at gmail.com> wrote: > 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 >> > > > ------------------------------------------------------------------------------ > 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/b6a95d5e/attachment.html>