Note that discussion of this patch should be limited to the code itself on github; discussion of the value of a 2MB hard fork is better suited for the mailing list.

Except the difference in size, is this same as Gavin's original 20MB proposal?

@jl2012 no, this is a one off change.

@jwilkins I'm talking about this: gavinandresen@5f46da2 They look very similar, if not identical

@jl2012 is correct that this patch is adapted from the original static 20MB change from @gavinandresen

That means this has actually received some testing and thought beyond my own personal testing.

Could you please move the block size and tx max size to consensusparams, as was done here: gavinandresen@7148527 and gavinandresen@b58d925 ? That would allow (for ex) a different blocksize or flagday on testnet so that we could test before the real thing.

Also, I think we could avoid a good bit of competing proposals if we pulled in a generic version of this that just parametrizes things as necessary to make the block size dynamic. It'd then just be a matter of debating what MaxBlockSize(uint64_t nBlockTimestamp) does internally.

We could even go as far as making it:
uint64_t MaxBlockSize(uint64_t nBlockTimestamp) { (void)nBlockTimestamp; return 1000000; }
for now, which should be 100% uncontentious, and could be merged immediately.

Any real blocksize changes would then be very straightforward in code.

ACK on building sometjing that can be meged without consensus changes first, without new size or activation height. Then to make the consensus changes we just need to add those two to Consesnsus::Params and change 1 line in MaxBlockSize(nHeight, consensusParams).

I'm happy to adapt jtimon@0734eef from #6382 to use MaxBlockSize MaxBlockSigops functions as in here and separate it as a PR if there's interest.
Then, as said, a rebase of this on top of that new PR should be a 3-line change (plus documentation).
Thoughts?
By "if there's interest" I mean something along the lines of "if it's going to be reviewed and merged/nacked within one month or less". Otherwise I have enough "rebase mouse-wheels" to maintain already.

I think it would be good time to increment PROTOCOL_VERSION.

What about to stop discussion about "the constant" and invent some rules how the max block size should be calculated from "fullness" of blocks in the recent history - similar to calculating the difficulty.

@ondra-novak That is outside the scope of this PR. Feel free to mention that on the mailing list.

@jgarzik I can't access mailing-list

This is only official visible discussion on the internet.

@ondra-novak https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

NACK due to lack of miner vote mechanism.

See http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009504.html for details on why this is a very bad idea.

@petertodd Do you mean NACK ONLY due to lack of miner vote mechanism? I don't think that would be difficult as we could just borrow the voting code from BIP66. I also think it's good to have a vote, just to make sure the legacy chain will extinct and the value of the legacy coins will approach zero.

@jl2012 I'm making no statement other than the pull-req as proposed is unacceptable by to that reason alone; I'll review further versions later. (though right now given how close we are to the scalability limits of the system already, simple blocksize increases as a scaling mechanism are going to be either big enough to be dangerous, or too small to be worth it)

The reason for a vote isn't to ensure the original chain "goes extinct" - it's because without miner support the chain is insecure. Furthermore with this pull-req every block mined on the original Bitcoin chain acts to 51% "attack" the Garzik chain; you can't mine original Bitcoin without participating in that 51% "attack".

Note how the normal nVersion supermajority soft-fork mechanism is explicitly designed so that once 95% support is reached, that overwhelming majority "attacks" the 5% minority, ensuring that users still on the 5% minority only see the secure, 95% majority chain. Equally, the Bitcoin Core software is designed to allow that "attack" to happen, because with a 95% majority we'd prefer to go along. (the definition of a soft-fork!)

@petertodd is it necessary then to make the code soft-fork capable?

No, this just can't be a softfork, must be a hardfork. But if it's an uncontroversial hardfork, you can use the same mechanism that you use in uncontroversial softforks to confirm that miners have upgraded.

I too cannot find another visible debate for the Blocksize issue. Especially regarding the 8mb & 20mb proposals.

Can someone prepare a pull request with miner voting (maybe 75%)? A 2MB approach is low risk and could gain consensus if binaries are available. This bip102 can be a consensus response to bip101. The community focus is on this issue right now and people are "voting". I would like to vote for Bitcoin Core and it's process whilst asking that you who know better than I give an extra round of thought to this Garzik proposal and augment Bitcoin Core with a short term block size increase as a response to recent events.

Again, why would we want miners to vote on the rule to limit mining
centralization? Let's analyze them all, chose aan uncontroversial one and
just deploy that (with or without mining upgrade confirmation (but if so
use 95% like with uncontroversial softforks).

95% of the hashrate is stronger but still an awful metric, there was >30% (effectively 100%) of the Bitcoin hashpower mining BIP65 blocks before there was even a single release of Bitcoin Core which supported the soft fork.

@tulip0 I think 95% is ok but it should be measured over a much longer period, maybe 10k blocks with a large activation delay of another 10k blocks.

@btcdrak F2Pool and Bitcoin Affiliate Network were, possibly more.

@jameshilliard That's sub-optimal, if you have >50% (maybe 33%) of the hash power you also have 100% by virtue of censoring any other non-conforming blocks. It really gives nobody any insight into who is going to accept the blocks other than SPV clients which blindly follow the most work.

@tulip0 What would you suggest for a threshold? I think the majority of miners will want as many other miners to support the fork before they switch.

@jameshilliard Talk of miner thresholds are completely irrelevant in a hard fork, they can mine whatever they want but anything invalid according to local rules will be rejected by validating nodes. There's no measure of validating nodes which isn't trivial to forge and it's not clear if number means anything to begin with. Choosing your metric wrong means people accepting Bitcoin as payment end up undetectably on different incompatible networks and viciously double spent against.

At any rate, supermajority of miners is un-measurable.

@jtimon #6625 was closed at the time.

Actually it was closed 10 hours ago when I realised that nobody that I know is writing a blocksize patch is using that code.

@tulip0 I think a miner threshold is still important to have since we need majority hashrate to secure the forked chain. Maybe also add a minimum block height as well.

@jgarzik this PR has changed a few times, and it'd probably be good to see if its worth re-opening a-fresh?

concept ACK

Agree with @petertodd i.e. strong NACK without at least a 95% (I'd say 90%) miner vote. I don't think this is the answer - off-chain transactions is a better solution. There have been many papers written on how important it is for the security of the network to keep block sizes small AFAIK.

Does the "consensus" flag mean that this pull request has achieved consensus?
Or does it mean that consensus is required for it, or something else?

I agree the 95% rule. But the voting process should be AFTER the merge of this PR. If 95% cannot be met, nothing happens, if we have 95% in the future, as the code is already there, it is not only running on miners' side, but also on countless users and merchants. It saves us lots of time and could absolutely accelerate the fork process. In fact the switch over of BIP 34/66 was exactly like that.

I would NACK any BIP that proposes a fixed way forward in terms of block size, prediction of future requirements.

Why not create a BIP that allows the miners to vote in each block whether to increase or decrease the blocksize, in addition to increasing or decreasing the average delay between blocks. This would require 9 different values, i.e. vote size same/up/down, delay same/up/down. I'd suggest 12.5% increases or decreases. This way the miners can tune as they require, and they are the main people with the incentive to make it sustainable (is this a correct assumption?)

I've reserved bitcoinmv.com (MV stands for Miner Vote) as a potential fork to the bitcoin project to give people another option in addition to Bitcoin Core, Bitcoin XT, etc... I think we need more options than the current two proposals. Hopefully the domain will never get used, as I'm hoping either Bitcoin Core or Bitcoin XT will go forward with this idea of letting the miners decide.

@wangchun A request from a majority of miners to have an activation percentage of 95% doesn't make sense, as that majority would already be able to abstain with enough hashing power to emulate/simulate a 95% activation percentage. Just make sure that about 20% abstains until 75% is met and you are golden.

Or 40% of miners can abstain until 55% is reached, or 30% can abstain until 65% is reached. Take your pick.

A majority of miners is in control over the activation anyway. It is just easier to increase the effective activation percentage than it is to lower it. Because lowering needs a completely new software release, new version numbers, or it needs miners to orphan votes which abstain for nefarious reasons.

Giving a minority some kind of veto is very dangerous and irresponsible. Obviously a minority (which aligns with preventing such a change) isn't going to admit that when that means losing the power to force things upon the majority with this inaction.

You go drive a bus with 100 passengers, and then when 5 people disagree with the direction you stop steeing completely. Clearly inaction is always better. Forcing "not steering" upon 95% makes total sense.

For non contentious non time sensitive issues a 95% activation percentage is fine, as that means the majority of miners don't have to do any coordination amongst themselves to safely activate the soft/hard fork. But if there is any significant cost to not upgrading or not upgrading on time and there is a chance that not everyone is going to upgrade in time (for whatever reason) then a 75% activation percentage gives you way more flexibility. It is a nice number, not too high, not too low.

Two things I don't understand, and would appreciate having explained. 1) Why does it suddenly jump to 2MB rather than gradually? 2) Why fix it at a number rather than allow for it to change per demand? i.e. allow the miners to vote per block on whether to increase or decrease the block size limit (or indeed the average time between blocks). Mining pools would gain subscribers based upon their advertised policy/voting on this.

I see no disadvantages with adding this to the BIP, and it makes it far less contentious, and far more future proof, plus reduces any sudden effects on the economy by allowing the change to occur gradually.