BIP 102: Increase block size limit to 2MB

jgarzik commented at 9:05 pm on July 16, 2015: contributor

BIP 102 - hard fork increase to 2M on flag day (currently May 5 2016)

Specification summary:

Increase MAX_BLOCK_SIZE to 2,000,000 bytes at trigger point.
Increase max block sigops by similar factor, preserving size/50 formula.
Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support via IsSuperMajority (ISM).

in src/consensus/consensus.h: in 526f8e71d5 outdated

 5@@ -6,10 +6,22 @@
 6 #ifndef BITCOIN_CONSENSUS_CONSENSUS_H
 7 #define BITCOIN_CONSENSUS_CONSENSUS_H
 8 
 9+static const uint64_t MEG_FORK_TIME = 1447200000; // 11 Nov 2015 00:00:00 UTC
10+
11 /** The maximum allowed size for a serialized block, in bytes (network rule) */
12-static const unsigned int MAX_BLOCK_SIZE = 1000000;
13+inline unsigned int MaxBlockSize(uint64_t nBlockTimestamp) {
14+    // 1MB blocks until 1 March 2016, then 20MB

djpnewton commented at 10:01 pm on July 16, 2015:

comment should be // 1MB blocks until 11 Nov 2015, then 2MB

in src/test/block_size_tests.cpp: in 526f8e71d5 outdated

70+}
71+
72+//
73+// Unit test CheckBlock() for conditions around the block size hard fork
74+//
75+BOOST_AUTO_TEST_CASE(TwentyMegFork)

djpnewton commented at 10:04 pm on July 16, 2015:

twenty? (also in comments below)

petertodd commented at 1:14 am on July 17, 2015: contributor

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.

jl2012 commented at 4:52 am on July 17, 2015: contributor

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

jwilkins commented at 9:51 am on July 17, 2015: none

@jl2012 no, this is a one off change.

jl2012 commented at 2:14 pm on July 17, 2015: contributor

@jwilkins I’m talking about this: https://github.com/gavinandresen/bitcoin-git/commit/5f46da29fd02fd2a8a787286fd6a56f680073770 They look very similar, if not identical

jgarzik commented at 2:31 pm on July 17, 2015: contributor

@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.

jgarzik force-pushed on Jul 17, 2015

theuni commented at 6:58 pm on July 17, 2015: member

Could you please move the block size and tx max size to consensusparams, as was done here: https://github.com/gavinandresen/bitcoin-git/commit/714852722960d6851890b4eb2939bb66d1cd7f2e and https://github.com/gavinandresen/bitcoin-git/commit/b58d92578566a52d696891b5611694b785fd2734 ? 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.

in src/consensus/consensus.h: in 4d6c6b7d46 outdated

 5@@ -6,10 +6,24 @@
 6 #ifndef BITCOIN_CONSENSUS_CONSENSUS_H
 7 #define BITCOIN_CONSENSUS_CONSENSUS_H
 8 
 9+#include <stdint.h>
10+
11+static const uint64_t MEG_FORK_TIME = 1447200000; // 11 Nov 2015 00:00:00 UTC

jtimon commented at 8:46 pm on July 17, 2015:

This should be in Consesnsus::Params. Also, why timestamp instead of height?

in src/consensus/consensus.h: in 4d6c6b7d46 outdated

12+
13 /** The maximum allowed size for a serialized block, in bytes (network rule) */
14-static const unsigned int MAX_BLOCK_SIZE = 1000000;
15+inline unsigned int MaxBlockSize(uint64_t nBlockTimestamp) {
16+    // 1MB blocks until 11 Nov 2015, then 2MB
17+    return (nBlockTimestamp < MEG_FORK_TIME ? 1000*1000 : 2*1000*1000);

jtimon commented at 8:48 pm on July 17, 2015:

The old and new sizes should also be in Consesnsus::Params. MaxBlockSize should therefore take a height and a const Consesnsus::Params& as parameters. The same goes for MaxBlockSigops().

in src/miner.cpp: in 4d6c6b7d46 outdated

329@@ -329,7 +330,6 @@ CBlockTemplate* CreateNewBlock(const CScript& scriptPubKeyIn)
330 
331         // Fill in header
332         pblock->hashPrevBlock  = pindexPrev->GetBlockHash();
333-        UpdateTime(pblock, Params().GetConsensus(), pindexPrev);

jtimon commented at 8:52 pm on July 17, 2015:

Why this? won’t this break tesnet mining?

jtimon commented at 9:00 pm on July 17, 2015: contributor

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).

laanwj added the label Consensus on Jul 18, 2015

jtimon commented at 9:17 am on July 18, 2015: contributor

I’m happy to adapt https://github.com/jtimon/bitcoin/commit/0734eefd1667e14fd2830d65e47fe97cec0eb6bb 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.

veqtrus commented at 11:57 am on July 18, 2015: contributor

I think it would be good time to increment PROTOCOL_VERSION.

ondra-novak commented at 7:56 am on July 20, 2015: none

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.

jgarzik commented at 2:32 pm on July 20, 2015: contributor

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

in src/test/block_size_tests.cpp: in 4d6c6b7d46 outdated

 95+
 96+    // A year after fork time:
 97+    uint64_t yearAfter = MEG_FORK_TIME+60*60*24*365;
 98+    BOOST_CHECK(TestCheckBlock(*pblock, yearAfter, 1000*1000)); // 1MB : valid
 99+    BOOST_CHECK(TestCheckBlock(*pblock, yearAfter, 2*1000*1000)); // 20MB : valid
100+    BOOST_CHECK(!TestCheckBlock(*pblock, yearAfter, 2*1000*1000+1)); // >20MB : invalid

andrewtoth commented at 5:20 pm on July 20, 2015:

These comments should be changed to 2MB.

ondra-novak commented at 10:01 am on July 21, 2015: none

@jgarzik I can’t access mailing-list

This is only official visible discussion on the internet.

jtimon commented at 10:13 am on July 21, 2015: contributor

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

petertodd commented at 4:50 pm on July 21, 2015: contributor

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.

jl2012 commented at 5:20 pm on July 21, 2015: contributor

@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.

petertodd commented at 5:47 pm on July 21, 2015: contributor

@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!)

dcousens commented at 5:32 am on July 30, 2015: contributor

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

jtimon commented at 7:56 am on July 30, 2015: contributor

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.

vladroberto commented at 6:25 pm on August 13, 2015: none

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

pointbiz commented at 1:15 pm on August 19, 2015: none

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.

jtimon commented at 3:01 pm on August 19, 2015: contributor

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).

petertodd commented at 7:30 pm on August 19, 2015: contributor

@jtimon Agreed, although I would still argue that miner confirmation of the change is mandatory - miners do have a veto in this issue, and we should respect that veto and design systems where miners using their veto is non-disruptive.

jtimon commented at 8:05 pm on August 19, 2015: contributor

@petertodd I agree that this change (since it’s framed as a potential uncontroversial hardfork), but I disagree that miners should always have veto power as explained in BIP99. @pointbiz For the record, BIP102 is my favorite consensus block size change proposal because it’s a one time thing that doesn’t make any exponential growth assumptions (even though I would like some simulations on the concrete 2MB proposal and the deployment mechanism doesn’t follow BIP99).

jgarzik commented at 8:07 pm on August 19, 2015: contributor

Talked with @dcousens on IRC… two changes on the todo list:

miner voting
modularize block size related code, in a separate commit from the hard fork changes

As discussed upthread, the latter will minimize changes in all the various block size BIPs and test harnesses.

jtimon commented at 9:52 pm on August 19, 2015: contributor

I adapted https://github.com/jtimon/bitcoin/commit/c4cfb5e098d23e017f98aad93698350bb91960b4 in #6382 to use a function, but it’s not taking the block.nHeight, the block.nTime nor the median time as parameter since I first wanted to have more discussion on http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html When we decide on a time threshold that is more general for any kind of hardfork (not just a block size increase) I’m happy to propose rewrite that commit and propose it as a separate PR (as well as adapting BIP99’s document and code, of course) that would make all block size change proposals easier to implement. Feels free to cherry pick or squash that commit as you want in the meantime. BIP99 currently recommends a minimum height plus 95% after that: https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11#diff-ba91592f703a9d0badf94e67144bc0aaR49

theuni commented at 10:09 pm on August 19, 2015: member

@jgarzik Please see #6526, which does the modularization part as simply (I think) as possible.

MarcoFalke commented at 8:12 am on October 30, 2015: member

What is the status of this? @jgarzik ?

jtimon commented at 10:17 am on October 30, 2015: contributor

@jgarzik If you want me to rebase this on top of #6625 I’m happy to do so.

MarcoFalke commented at 10:33 am on October 30, 2015: member

@jtimon I think this needs more work than just rebase. At least needs the date (Nov 11) fixed but I remember some new blocksize suggestions popped up in the meantime

jtimon commented at 10:37 am on October 30, 2015: contributor

@MarcoFalke You are right, but I was just offering to do the rebase part (because I want this to be rebased on top of #6625 which should also simplify this patch once/if #6625 is merged), not taking over the PR.

jgarzik commented at 1:02 pm on October 30, 2015: contributor

If @jtimon wants to rebase on top of another patch, I can take it from there and finish the miner voting, the second of two to-do items.

jtimon commented at 9:29 am on November 3, 2015: contributor

What miner voting? bip99 currently recommends a starting height + versionbits 95% miner upgrade confirmation (although it seems I’m alone with height so I’ll probably change it to mediantime soon). I can leave this just as it currently is just to show how #6625 simplifies this and hopefully get that out of the way before starting to move consensus validation code to the consensus dir ( like in #6672 failed attempt). Please review #6625.

jtimon commented at 2:54 pm on November 3, 2015: contributor

I’m sorry but I would need to review #6622 before being able to rebase this (see #6625 (comment) ). It won’t be as easy as I expected, so if someone else wants to do it, I don’t plan to do it myself in the short term. In any case I would still recommend to do it on top of #6625, which should simplify things.

jgarzik commented at 2:59 pm on November 3, 2015: contributor

OK, I’ll hop back on the rebase, then.

The goal of this pull request is to have something that really can be pulled in the short term if need be.

jgarzik commented at 5:35 pm on December 17, 2015: contributor

Rewritten OP: BIP 102 - hard fork increase to 2M on May 5, 2016.

luke-jr commented at 7:42 pm on December 17, 2015: member

Would be nicer to switch on block 420,000 instead of time.

petertodd commented at 7:52 pm on December 17, 2015: contributor

Again, strong NACK without at least a 95% miner vote.

We can’t support ethically something this dangerous given the high probability of massive reorgs if the fork is controversial.

jgarzik commented at 8:29 pm on December 17, 2015: contributor

Updated to add hashpower activation to critieria (it was agreed to up-thread, and should have been listed)

jgarzik commented at 8:46 pm on December 17, 2015: contributor

@luke-jr That’s two shocks at the same time. Economically speaking, halving day is a BTC supply shock. Changing the block size is a supply shock if-and-only-if the economy has transitioned from current blocks-not-full-on-avg to a tighter supply buffer.

The reasonable suggestion on the mailing list was to separate the two supply events in time.

jgarzik force-pushed on Dec 18, 2015

jgarzik commented at 3:07 am on December 18, 2015: contributor

Rebased.

BIP 102 implementation bbdf5d2971

jgarzik force-pushed on Dec 18, 2015

BIP 102: Fix ISM, test. 9e2d59ae11

jgarzik renamed this:
~~BIP 102: Increase block size limit to 2MB on Nov 11, 2015.~~
BIP 102: Increase block size limit to 2MB + 20b/10min
on Dec 18, 2015

eragmus commented at 6:25 am on December 18, 2015: none

Just to clarify, the first post in this thread stated:

Each 10-minute segment thereafter increases MAX_BLOCK_SIZE by 20 bytes.

This seems to equal a 1MB increase in block size each year, in perpetuity. Is that true? It has typically been characterized as merely a static bump to 2MB, but it actually seems to be: 2 + x , where x = number of years after activation. – This would mean BIP102 is similar to BIP248 in years 0-2, more conservative in years 2-4, and thereafter slightly more aggressive in the longterm (infinitely increasing by 1MB/year).

Also, is it advisable to include a fix for amaclin’s sigop attack (needs hard fork to properly fix) in BIP102? I know pork-barreling a hard fork with too many things isn’t advisable, but perhaps exceptions should be made for security fixes and such high-priority items.

Thanks.

jameshilliard commented at 7:04 am on December 18, 2015: contributor

NACK on https://github.com/jgarzik/bitcoin/commit/bbdf5d2971daf00c0355526177c568937149b61c there needs to be a cap ceiling that’s not too high, I would stay away from anything over 8MB in general.

jameshilliard commented at 7:15 am on December 18, 2015: contributor

@jgarzik I should also add that it’s a bad idea to non-trivially change proposals after they already have a BIP number that people are referring to them with, it’s causing confusion, you did the same thing with BIP100, a lot of the miners backed the original proposal only and not your subsequent modifications. If you are making non-trivial changes please don’t use the same BIP.

laanwj commented at 8:46 am on December 18, 2015: member

Right: If you make changes that seriously differ from the original proposal when opening a pull, open a new pull request. Otherwise reviewers will get confused.

jtimon commented at 11:38 am on December 18, 2015: contributor

Yes, please don’t change bip102 to something that grows forever and I cannot support. Just create another BIP so that we don’t have to clarify all our previous supportive comments about it.

BIP 102: revert back to fixed, one time bump ee061f4b70

jgarzik commented at 1:08 pm on December 18, 2015: contributor

Fair enough - updated as per comments back to one-time fixed.

jtimon commented at 1:23 pm on December 18, 2015: contributor

No rebase on top of #6625 ?

jgarzik commented at 1:33 pm on December 18, 2015: contributor

@jtimon #6625 was closed at the time – Just ACK’d that PR – will rebase if #6625 goes in first

BIP 102: require 95% upgrade 5ce9067f70

jgarzik renamed this:
~~BIP 102: Increase block size limit to 2MB + 20b/10min~~
BIP 102: Increase block size limit to 2MB
on Dec 18, 2015

tulip0 commented at 1:43 pm on December 18, 2015: none

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.

jameshilliard commented at 1:49 pm on December 18, 2015: contributor

@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.

tulip0 commented at 2:01 pm on December 18, 2015: none

@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.

jameshilliard commented at 2:05 pm on December 18, 2015: contributor

@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.

tulip0 commented at 2:17 pm on December 18, 2015: none

@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 commented at 2:53 pm on December 18, 2015: contributor

@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.

jameshilliard commented at 3:49 pm on December 18, 2015: contributor

@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.

dcousens commented at 11:27 pm on December 18, 2015: contributor

@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

in src/consensus/consensus.h: in 5ce9067f70

 5@@ -6,10 +6,26 @@
 6 #ifndef BITCOIN_CONSENSUS_CONSENSUS_H
 7 #define BITCOIN_CONSENSUS_CONSENSUS_H
 8 
 9+#include <stdint.h>
10+
11+static const uint64_t BIP102_FORK_TIME = 1462406400; // May 5 2016, midnight UTC

jtimon commented at 10:17 am on December 20, 2015:

Should be in Consensus::Params.

in src/consensus/consensus.h: in 5ce9067f70

14-static const unsigned int MAX_BLOCK_SIZE = 1000000;
15+inline unsigned int MaxBlockSize(uint64_t nTime) {
16+    if (nTime < BIP102_FORK_TIME)
17+        return 1000*1000;
18+
19+    return (2*1000*1000);

jtimon commented at 10:19 am on December 20, 2015:

Should also be in Consensus::Params, and the current limit as well. Also why 1000*1000 instead of 1000000 like it was?

MarcoFalke commented at 11:14 am on December 20, 2015:

It’s easier to see when there the zeros are separated.

in src/consensus/consensus.h: in 5ce9067f70

10+
11+static const uint64_t BIP102_FORK_TIME = 1462406400; // May 5 2016, midnight UTC
12+
13 /** The maximum allowed size for a serialized block, in bytes (network rule) */
14-static const unsigned int MAX_BLOCK_SIZE = 1000000;
15+inline unsigned int MaxBlockSize(uint64_t nTime) {

jtimon commented at 10:21 am on December 20, 2015:

Should use median time or height so that you can always predict whether the next block needs to follow the new rules or not.

in src/main.cpp: in 5ce9067f70

3062@@ -3055,6 +3063,11 @@ bool ContextualCheckBlockHeader(const CBlockHeader& block, CValidationState& sta
3063         return state.Invalid(error("%s : rejected nVersion=3 block", __func__),
3064                              REJECT_OBSOLETE, "bad-version");
3065 
3066+    // Reject block.nVersion=4 blocks when 95% (75% on testnet) of the network has upgraded:
3067+    if (block.nVersion < 5 && IsSuperMajority(5, pindexPrev, consensusParams.nMajorityRejectBlockOutdated, consensusParams))
3068+        return state.Invalid(error("%s : rejected nVersion=3 block", __func__),

jtimon commented at 10:23 am on December 20, 2015:

Wrong version in the error message.

in src/net.cpp: in 5ce9067f70

2123@@ -2124,7 +2124,7 @@ void CNode::RecordBytesSent(uint64_t bytes)
2124 void CNode::SetMaxOutboundTarget(uint64_t limit)
2125 {
2126     LOCK(cs_totalBytesSent);
2127-    uint64_t recommendedMinimum = (nMaxOutboundTimeframe / 600) * MAX_BLOCK_SIZE;
2128+    uint64_t recommendedMinimum = (nMaxOutboundTimeframe / 600) * (1*1000*1000);
2129     nMaxOutboundLimit = limit;

jtimon commented at 10:25 am on December 20, 2015:

At the very least create a new constant instead of using “1_1000_1000” here.

in src/main.cpp: in 5ce9067f70

957@@ -958,7 +958,7 @@ bool AcceptToMemoryPoolWorker(CTxMemPool& pool, CValidationState &state, const C
958         // Check that the transaction doesn't have an excessive number of
959         // sigops, making it impossible to mine. Since the coinbase transaction
960         // itself can contain sigops MAX_STANDARD_TX_SIGOPS is less than
961-        // MAX_BLOCK_SIGOPS; we still consider this an invalid rather than
962+        // MaxBlockSigops; we still consider this an invalid rather than

jtimon commented at 10:29 am on December 20, 2015:

maybe s/MaxBlockSigops/MaxBlockSigops()/ to make it clearer that now is a function?

in src/main.cpp: in 5ce9067f70

2067@@ -2068,6 +2068,13 @@ bool ConnectBlock(const CBlock& block, CValidationState& state, CBlockIndex* pin
2068         flags |= SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY;
2069     }
2070 
2071+    bool fBIP102Enforcing = (pindex->GetBlockTime() >= (int64_t)BIP102_FORK_TIME);
2072+    if (fBIP102Enforcing && block.nVersion >= 5 && !IsSuperMajority(5, pindex->pprev, chainparams.GetConsensus().nMajorityRejectBlockOutdated, chainparams.GetConsensus()))

jtimon commented at 10:34 am on December 20, 2015:

If version is lower than 5 it doesn’t matter the result of the IsSuperMajority call? You don’t need an if and to assign false to the bool: just assign all the conditions to the variable directly . It’s simpler and you would have probably not made the mistake you did if it wasn’t for the unnecessary if statement.

in src/main.cpp: in 5ce9067f70

2984@@ -2978,7 +2985,8 @@ bool CheckBlock(const CBlock& block, CValidationState& state, bool fCheckPOW, bo
2985     // because we receive the wrong transactions for it.
2986 
2987     // Size limits
2988-    if (block.vtx.empty() || block.vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(block, SER_NETWORK, PROTOCOL_VERSION) > MAX_BLOCK_SIZE)
2989+    unsigned int nMaxSize = MaxBlockSize(block.GetBlockTime());

jtimon commented at 10:37 am on December 20, 2015:

This now depends on CBlockIndex (for ISM or bip9), the check should be moved to contextualcheckblock.

rebroad commented at 12:09 pm on January 5, 2016: contributor

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.

ripper234 commented at 11:43 am on January 17, 2016: none

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?

wangchun commented at 4:17 pm on January 17, 2016: none

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.

sipa commented at 5:24 pm on January 17, 2016: member

BIP34/66 were soft forks. They didn’t require the entire ecosystem to switch to new code beforehand.

In my opinion, the correct way to do a hard fork is to first see if there is universal support for it, and when so, schedule it for 1 year in the future or so. No vote needed; everyone knows they have to upgrade by that time.

There can still be a miner vote after that 1 year to be sure miners also agree to the change, and know we’ll end up with a secure chain after the fork, but that’s just belt and suspenders.

rebroad commented at 7:04 pm on January 17, 2016: contributor

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.

seweso commented at 12:15 pm on February 3, 2016: none

@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.

rebroad commented at 12:48 pm on February 5, 2016: contributor

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.

sipa commented at 12:53 pm on February 5, 2016: member

Keep the discussion here about implementation details, please.

jgarzik closed this on Sep 29, 2016

MarcoFalke locked this on Sep 8, 2021

BIP 102: Increase block size limit to 2MB #6451