6

On his blog, 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:

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?

  • 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. – Nick ODell Feb 21 '15 at 20:29
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, 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, 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?

  • 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 Feb 21 '15 at 19:48
  • 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. – morsecoder Feb 21 '15 at 19:55
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.