I think the key is comity and humility in terms of being honest about our inability to predict future trends in a meaningful way while passing through scrutiny coming from divergent perspectives. 8MB + 40% annually (at whatever increase frequency is preferred, at coinbase halvings seems most ideal) is the proposal to use.
What if 40% is too fast? If 40% turns out to be excessive, miners have a built in incentive to cap their blocks at a lower amount that meets the supply / demand equilibrium vs. the price of bitcoin trading on the free market. The key here is to understand “price of bitcoin on the free market”. Most developers don’t understand free market economics beyond gambling, which is a good bit of the problem here. Bottom line is, miners directly benefit from higher bitcoin prices when denominated in other currencies. This fact will naturally limit excessive growth of blk*.dat. size, because if the storage requirements for bitcoin grow out of reach of amateurs, it will lead to excessive centralization and capture by powerful interests, which would threaten to convert bitcoin to a form of sovereign currency and kill free demand for bitcoin (and tank the price). Miners don’t want that without some other body paying them to make econonically distorted decisions. They will limit the size themselves if they see this as an emerging threat. It’s in their best interests and will keep them in business longer. Now, is there a risk that some excessively well funded entity could artificially inflate the price of bitcoin while this bribing miners to let blk*.dat size grow out of hand (distorting miner economics) in some sort of “subsidies for increased liquidity” corruption scheme? No there isn’t, because we are going to have a cap on the size that is reasonable enough that we know it won’t force out any amateurs for at least 5 years, and likely longer. What if 40% is too slow? That’s a problem anyone who actually owns bitcoin would like to have. We’ll gladly support an increase in the rate if demand supports it later with a subsequent change. We’ll have to do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, or some other non-self imposed existential threat rears its head. Long game Now, this entire scheme is predicated on the price going higher over the extended term. I would argue that if we are doing a good job, the price should go higher. Isn’t that the best barometer of performance? Demand for the scarce units inside the protocol denominated in other currencies? 8MB is 1MB + 40% a year from January 2009 to today. 40% a year is as good as we are going to get in terms of our extrapolated estimation of future ability to host full nodes. Anything else is overengineering something we can’t predict anyway. Any arguments against this setting and rate of growth that aren’t exclusively focused on the computer science side of the debate are misguided at best, and corrupted by competing incentives at worst. This is because it’s not possible to predict the future any better than using an extrapolation of the past, which is exactly what 8MB + 40% represents. So TLDR? Go with 8MB + 40% annually and we will cross any (likely imaginary) bridges when we come to them down the road. Will From: Pieter Wuille via bitcoin-dev <[email protected]> Reply: Pieter Wuille <[email protected]>> Date: August 6, 2015 at 5:32:20 PM To: Dave Scotese <[email protected]>> Cc: Bitcoin Dev <[email protected]>> Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <[email protected]> wrote: "Miners can do this unilaterally" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding. They don't need to use full nodes for propagation. Miners don't care when other full nodes hear about their blocks, only whether they (eventually) accept them. And yes, full nodes can change what blocks they accept. That's called a hard fork :) -- Pieter _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
