<blockquote>
  <p>If there is a block-size hard fork, will the old chain have an advantage?</p>
</blockquote>

<p>This is partially true, but it is not as grave a problem as the writer would have us believe. It would be much more problematic if the implementation of increasing the block size were done very poorly and discretely (such as just putting out a new client with the MAX_BLOCK_SIZE parameter changed), but there will be a more continuous process to switch over to using larger block sizes. </p>

<p>In <a href="http://gavintech.blogspot.com/?m=1" rel="nofollow noreferrer">Gavin's proposal</a>, nodes that aim to eventually allow larger block sizes will start using blocks with nVersion set to 4. When a supermajority is obtained, in this case meaning that 800 of the last 1000 blocks signal support for the larger block size limit proposal by using nVersion = 4, then the network will start actually relaxing the 1 MB limit to somewhere around 16 MB. From there, every 2 years the block size limit will double. </p>

<p>(Aside: I think it would be beneficial to have a grace period after the supermajority is obtained to allow miners in the losing side of the hard fork to update their software. I have commented on Gavin's blog post but haven't heard back, I'm sure he is very busy)</p>

<p>This proposal essentially puts the decision to use a higher block size limit to a vote on the network. <strong>However, until the supermajority is obtained, all nodes will still enforce the 1 MB block size limit.</strong> Thus, nodes that embrace the hard fork will not be at a disadvantage at all before the network supermajority is obtained. </p>

<p>After the network supermajority is obtained, technically blocks &lt; 1MB will be accepted by all nodes, and blocks with size 1MB &lt; size &lt; 16MB will only be accepted by 80%. But by this point 80% of the network has already committed to allowing larger block sizes. If the nodes with the old rule don't update, they will be on the losing side of the fork and will be working on a slower-growing chain than the main chain. The old network's chain could be accepted by the new network (if they could create block fast enough to overtake the new chain), while the main network's chain could not be accepted by the old network because it breaks consensus rules. </p>

<p>It is also possible that the supermajority will never be obtained due to lack of support among the mining community. I would hope this does not happen. My personal opinion is that miners who are rationally trying to make a profit should make using Bitcoin as easy as possible (while still preventing spam) so that new people who want to join the ecosystem can do so painlessly and without having to wait hours for their transaction to be confirmed. More users bringing in buying pressure means the bitcoins mined will be worth more.</p>

<p>Coincidentally, according to <a href="http://www.poll-maker.com/results233857xDa614c79-9#tab-2" rel="nofollow noreferrer">a recent survey</a>, Gavin has about 80% support among the community for his proposal. </p>

<p>Related: <a href="https://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit">What are the arguments for and against the increase of the block size limit?</a></p>

CC BY-SA 3.0
2015-02-21T19:48:11.033Z
So you are saying his argument only makes sense if miners return to the old chain.  Why wouldn't the fork chain be a completely new, incompatible chain (which Popescu says "you don't do")?
apwx3
CC BY-SA 3.0
2015-02-21T19:55:27.757Z
It's not a new chain, it's more like the old chain taking a different direction than it would have otherwise. And the switch waits for 80% support before enforcing the rule. Popescu says "you don't just fork bitcoin" because most of the time it would be a pointless waste of effort and would not just get support. This case may be different.
morsecoder
CC BY-SA 3.0
2015-02-21T05:37:22.137Z
2015-02-21T19:57:35.950Z
2017-04-13T12:47:34.187Z
morsecoder
<p>It's clear at this point that Mircea was right.  </p>

<p>Forking bitcoin is incredibly hard to do even with the "80% community support" the forkers had back in 2015.  They're still at it in 2017, although their support amongst hodlers seems to be much diminished, while big blockers have simultaneously gained a quasi mining monopoly.  But it still looks like the s2x hard fork will fail in a couple weeks.</p>

CC BY-SA 3.0
2017-11-06T16:11:41.557Z
2017-11-06T16:11:41.557Z
apwx3
<p>On <a href="http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/" rel="nofollow">his blog</a>, Mircea Popescu claims the old chain will have an advantage:</p>

<blockquote>
The situation here is aggravated by the fact that the fork proposed is not simply nondeterministic behaviour, and so the holdings on the two chains aren't notionally equivalent. Instead, all the holdings on the Bitcoin chain are accepted as valid on both Bitcoin and Gavincoin, but holdings on Gavincoin are rejected by Bitcoin. Consequently, everyone involved with the fork is writing options to everyone in Bitcoin, free of charge.
</blockquote>

<p>He makes similar claims <a href="http://qntra.net/2015/01/the-hard-fork-missile-crisis/" rel="nofollow">here</a>:</p>

<blockquote>
    mircea_popescu: ben_vulpes if one block's large and the other small, all i need a tx that's included in the large block but not the small one. then doublespend it on the small one, which will be rejected necessarily by the large block blockchain.
<br/>
    mircea_popescu: now i have bitcoin separated in two addresses, one for each chain.
<br/>
    mircea_popescu: the attempt may fail, but the cost to me of this failure is not significant, so i can keep on trying until it succeeds.
<br/>
    mircea_popescu: <b>the only way to guard against it is, obviously,for the ."large" chain to maintain 1:1 identity with the "small" one. because you don't just fork bitcoin.,</b>
<br/>
    ben_vulpes: i still fail to see how you're going to make a txn that gets included in the large block chain and not the small block chain.
<br/>
    artifexd: ben_vulpes: You don't. You keep sending money to yourself until it happens.
<br/>
    mircea_popescu: ben_vulpes what do you mean ? it necessarily will occur.
<br/>
    mircea_popescu: since one contains more txn than the other by definition.
<br/>
    mircea_popescu: suppose i make 50k 1btc txn. they don't fit in a 1mn block. they do fit in a 10mb block. what now ?
</blockquote>  

<p>I'm skeptical of these claims -- but how exactly is he wrong?  </p>

CC BY-SA 3.0
2015-02-21T20:29:16.300Z
These two quotes are making two unrelated points: 1) People who own lots of bitcoins will have a large effect on which option is selected, and 2) the two chains will diverge.
Nick ODell
<blockchain-fork><scalability><block-size-increase>
If there is a block-size hard fork, will the old chain have an advantage?
apwx3
# If there is a block-size hard fork, will the old chain have an advantage?

(Asked by: username_0 on 2015-02-21)

On [his blog](http://trilema.com/2015/lets-address-some-of-the-more-common-pseudo-arguments-raised-by-the-very-stupid-people-that-like-the-gavin-scamcoin-proposal/), Mircea Popescu claims the old chain will have an advantage:

> The situation here is aggravated by the fact that the fork proposed is not simply nondeterministic behaviour, and so the holdings on the two chains aren't notionally equivalent. Instead, all the holdings on the Bitcoin chain are accepted as valid on both Bitcoin and Gavincoin, but holdings on Gavincoin are rejected by Bitcoin. Consequently, everyone involved with the fork is writing options to everyone in Bitcoin, free of charge.

He makes similar claims [here](http://qntra.net/2015/01/the-hard-fork-missile-crisis/):

> mircea\_popescu: ben\_vulpes if one block's large and the other small, all i need a tx that's included in the large block but not the small one. then doublespend it on the small one, which will be rejected necessarily by the large block blockchain.
>   
> mircea\_popescu: now i have bitcoin separated in two addresses, one for each chain.
>   
> mircea\_popescu: the attempt may fail, but the cost to me of this failure is not significant, so i can keep on trying until it succeeds.
>   
> mircea\_popescu: **the only way to guard against it is, obviously,for the ."large" chain to maintain 1:1 identity with the "small" one. because you don't just fork bitcoin.,**
>   
> ben\_vulpes: i still fail to see how you're going to make a txn that gets included in the large block chain and not the small block chain.
>   
> artifexd: ben\_vulpes: You don't. You keep sending money to yourself until it happens.
>   
> mircea\_popescu: ben\_vulpes what do you mean ? it necessarily will occur.
>   
> mircea\_popescu: since one contains more txn than the other by definition.
>   
> mircea\_popescu: suppose i make 50k 1btc txn. they don't fit in a 1mn block. they do fit in a 10mb block. what now ?

I'm skeptical of these claims -- but how exactly is he wrong?

**Tags:** blockchain-fork, scalability, block-size-increase

> **Comments:**
> **username_1**: These two quotes are making two unrelated points: 1) People who own lots of bitcoins will have a large effect on which option is selected, and 2) the two chains will diverge.  

---

## 2 answers

### Answer by username_2 on 2015-02-21. Score: 4

> If there is a block-size hard fork, will the old chain have an advantage?

This is partially true, but it is not as grave a problem as the writer would have us believe. It would be much more problematic if the implementation of increasing the block size were done very poorly and discretely (such as just putting out a new client with the MAX\_BLOCK\_SIZE parameter changed), but there will be a more continuous process to switch over to using larger block sizes.

In [Gavin's proposal](http://gavintech.blogspot.com/?m=1), nodes that aim to eventually allow larger block sizes will start using blocks with nVersion set to 4. When a supermajority is obtained, in this case meaning that 800 of the last 1000 blocks signal support for the larger block size limit proposal by using nVersion = 4, then the network will start actually relaxing the 1 MB limit to somewhere around 16 MB. From there, every 2 years the block size limit will double.

(Aside: I think it would be beneficial to have a grace period after the supermajority is obtained to allow miners in the losing side of the hard fork to update their software. I have commented on Gavin's blog post but haven't heard back, I'm sure he is very busy)

This proposal essentially puts the decision to use a higher block size limit to a vote on the network. **However, until the supermajority is obtained, all nodes will still enforce the 1 MB block size limit.** Thus, nodes that embrace the hard fork will not be at a disadvantage at all before the network supermajority is obtained.

After the network supermajority is obtained, technically blocks < 1MB will be accepted by all nodes, and blocks with size 1MB < size < 16MB will only be accepted by 80%. But by this point 80% of the network has already committed to allowing larger block sizes. If the nodes with the old rule don't update, they will be on the losing side of the fork and will be working on a slower-growing chain than the main chain. The old network's chain could be accepted by the new network (if they could create block fast enough to overtake the new chain), while the main network's chain could not be accepted by the old network because it breaks consensus rules.

It is also possible that the supermajority will never be obtained due to lack of support among the mining community. I would hope this does not happen. My personal opinion is that miners who are rationally trying to make a profit should make using Bitcoin as easy as possible (while still preventing spam) so that new people who want to join the ecosystem can do so painlessly and without having to wait hours for their transaction to be confirmed. More users bringing in buying pressure means the bitcoins mined will be worth more.

Coincidentally, according to [a recent survey](http://www.poll-maker.com/results233857xDa614c79-9#tab-2), Gavin has about 80% support among the community for his proposal.

Related: [What are the arguments for and against the increase of the block size limit?](https://bitcoin.stackexchange.com/questions/36085/what-are-the-arguments-for-and-against-the-increase-of-the-block-size-limit)

> **Comments:**
> **username_0**: So you are saying his argument only makes sense if miners return to the old chain.  Why wouldn't the fork chain be a completely new, incompatible chain (which Popescu says "you don't do")?  
> **username_2**: It's not a new chain, it's more like the old chain taking a different direction than it would have otherwise. And the switch waits for 80% support before enforcing the rule. Popescu says "you don't just fork bitcoin" because most of the time it would be a pointless waste of effort and would not just get support. This case may be different.  

---

### Answer by username_0 on 2017-11-06. Score: 1

It's clear at this point that Mircea was right.

Forking bitcoin is incredibly hard to do even with the "80% community support" the forkers had back in 2015. They're still at it in 2017, although their support amongst hodlers seems to be much diminished, while big blockers have simultaneously gained a quasi mining monopoly. But it still looks like the s2x hard fork will fail in a couple weeks.


---

