On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgar...@gmail.com> wrote: >> You present this as if the Bitcoin Core development team is in charge >> of deciding the network consensus rules, and is responsible for making >> changes to it in order to satisfy economic demand. If that is the >> case, Bitcoin has failed, in my opinion. > > Diverging from the satoshi block size change plan[1] and current economics > would seem to require a high level of months-ahead communication to users.
I don't see any plan, but will you say the same thing when the subsidy dwindles, and mining income seems to become uncertain? It will equally be an economic change, which equally well will have been predictable, and it will equally well be treatable with a hardfork to increase the subsidy. Yes, I'm aware the argument above is a straw man, because there was clear expectation that the subsidy would go down asymptotically, and much less an expectation that the blocksize would remain fixed forever. But I am not against a block size increase hard fork. My talk on segregated witness even included proposed pursuing a hard fork at a slightly later stage. But what you're arguing for is that - despite being completely expected - blocks grew fuller, and people didn't adapt to block size pressure and a fee market, so the Core committee now needs to kick the can down the road, because we can't accept the risk of economic change. That sounds very much like a bailout to me. Again. I am not against growth, but increasing in response to fear of economic change is the wrong approach. Economic change is inevitable. > Segregated Witness does not kick the can, it solves none of the problems #1, > #3 - #8 explicitly defined and listed in email #1. > > 1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there > will be no Fee Event, because the core block size is still heavily contended > -- 100% contended at time out SW rollout. That is an assumption. I expect demand for transactions at a given feerate to stop growing at a certain contention level (and we've reached some level of contention already, with mempools not being cleared for significant amounts of time already). > SW mitigates this > - only after several months That is assuming a hard fork consensus forming, deployment, activation, ... goes faster than a softfork. > - only assuming robust adoption rates by up-layer ecosystem software, and That's not required. Everyone who individually switches to new transactions gets to do 1.75x more transactions for the same price (and at the same time gets safer contracts, better script upgradability, and more security models at their disposal), completely independent of whether anyone else in the ecosystem does the same. > - only assuming transaction volume growth is flat or sub-linear The only question is how many transactions for what price. Contention always happens at a specific feerate level anyway. > Those conditions must go as planned to fulfill "SW kicked the can" -- a lot > of if's. > > As stated, SW is orthogonal to the drift-into-uncharted-waters problem > outlined in email #1, which a short term bump does address. Both SW and a short bump (which is apparently not what BIP102 does anymore?) increase capacity available per price, and yes, they are completely orthogonal. My only disagreement is the motivation (avoiding economic change, as opposed to aiming for safe growth) and the claim that a capacity increase hardfork is easier and safe(r) to roll out quickly than sortfork SW. Apart from that, we clearly need to do both at some point. -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
