The PR discussion should be used only for technical review of the code. Please discuss the merits of this consensus change on the bitcoin-dev ML.
This PR is only changes to the consensus code. Mining code, and some RPC calls, will also need updating for the new rules should this protocol change be accepted.
As this is would be a hardfork, the mainnet BIP9 deployment must not be defined without consensus from the Bitcoin community. (This PR does not define it.)
Concept NAK.
At least on an initial impression: We haven't even been able to see/measure the effects of segwit doubling it-- increasing it again seems really imprudent, especially with the result going beyond what prior measurements suggested could be supported without massive decentralization losses. This change also likely leaves the supply radically above the transaction demand (well increasingly it looks like segwit will too, but this would make it worse), which would put the system back in an unstable state where fees don't adequately protect it from abuse and users have a bad experience any time a little load shows up, or when users gain unrealistic expectations about the costs of using it.
Also, calling it "safe" is misleading. It's like naming the PATRIOT act... who could oppose patriots, never-mind that there wasn't anything especially patriotic about it. You could plausibly call it safer, since it's certainly safer than some of the more outright reckless proposals. :)
A procedural comment: directing people to not discuss the proposal here is bad form and was looked none to kindly on when Gavin tried it with BIP-101. Please don't do that.
I appreciate your efforts on this front, but I have to agree with @gmaxwell here. Lets leave PRs for when the community is in a place that it can reasonably come together and form consensus around a spec.
At least on an initial impression: We haven't even been able to see/measure the effects of segwit doubling it-- increasing it again seems really imprudent, especially with the result going beyond what prior measurements suggested could be supported without massive decentralization losses. This change also likely leaves the supply radically above the transaction demand (well increasingly it looks like segwit will too, but this would make it worse), which would put the system back in an unstable state where fees don't adequately protect it from abuse and users have a bad experience any time a little load shows up, or when users gain unrealistic expectations about the costs of using it.
Unless I severely mis-implemented the proposal, this impression doesn't seem to reflect the behaviour of the code at all...?
A procedural comment: directing people to not discuss the proposal here is bad form and was looked none to kindly on when Gavin tried it with BIP-101. Please don't do that.
My apologies. I took the lack of procedural objections on #9602 to indicate it was now acceptable.
I see, I missed the initial value and just looked at rate of change. Ugh. I am not suddenly cheered up. All this is going to do is create drama and noise, anger and upset people and set back actually productive work.
on the procedural, splitting discussion across github issues is less significant then directing people to entirely other venues. But I can see why you thought it would be okay.
Concept NACK as I explained at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013498.html
To summarize, I think we should facilitate people to run full nodes by optimizing the protocol. Trying to solve a problem by "simply changing 1 to 0.3" or "simply changing 1 to 2" are equally naive. It just shows a lack of creativity and never really solves the problem.
@jgarzik The existing, working, tested, deployed code are developed under the 1MB limit assumption. When this is lifted, it is unknown territories.
But equally, as everyone developed bitcoin apps around the 1MB limit assumption, a sudden 70% decrease will break many of these apps, and therefore I can't agree with this proposal
point of clarification it's not a 70% decrease, it's a ~40% decrease because it uses segwit like accounting for all transaction.
Depends on when it's activated by miners. Provided the hardfork is accepted by consensus, that can be any time up until after passes 1 MB (assuming the current BIP9 timeout is used). If activated today (which is obviously not going to happen, since the hardfork hasn't been accepted), the block weight limit today would be 600k (with both segwit and non-segwit benefitting from the discount), but the block size limit of 300k would hold no matter what the weight is - so it would be 70% as @jl2012 said (again, only in the hypothetical of a present-day activation, which can't realistically happen).
I've done some updates to the BIP draft text in hopes of clarifying how the activation works, and why I think this BIP should be entirely uncontroversial (insofar as the hardfork itself is concerned; contention over the "stage 2" activation is a separate matter).
@luke-jr : my understanding is it is not possible to early "lock-in" an eventual hardfork, without also reducing the size before 2024. To minimize any possible controversy, you should simply remove the reduction stage, so people may agree to lock-in earlier without side effect.
Also, it doesn't prohibit you from proposing an independent softfork that reduce the the block size for the following 7 years.
@jl2012 To lock-in just the hardfork, we'd simply ship the code in all full nodes for the next 7 years. That wouldn't imply the reduction needs to be activated.
But in any case, preliminary results suggest even putting it 7 years out is unacceptable to the community, which completely kills this idea regardless of merits. Closing unless evidence later shows up suggesting something is possible here.