Hacker News Reader

Comment by ISL | Hacker News Reader

Is there a sensible fashion by which two robust blockchain forks might merge?

Widespread use of the currency is troublesome if it's possible for anyone to have reasonable odds of forking the chain. If it's possible for a mass panic to reverse transactions, it's not as reliable.

If Asia (4 billion people), banking institution (US federal debt = ~23% of world GDP), or a social group (Catholicism: 63% of the Americas) buys a bunch of stuff then decides, en masse, to revert to an earlier blockchain, it could drive instability. Large groups of people sometimes do unpredictable things (Gangnam Style: 1.4 billion views).

View on HN

"Is there a sensible fashion by which two robust blockchain forks might merge?"

They will not merge, but transactions will homogeneize.

I have simulated this scenario, forking the Bitcoin chain on a private network 2 years ago. What happens is that if the chain is forked, and if a client unexpectedly sees that another chain (say chain B) suddenly replaces the chain it was following (say chain A), thereby reverting a bunch of transactions, then the client will automatically retransmits its transactions that it had saved in chain A, to have them saved again in chain B.

That is how a non-malicious client operates.

Of course, if you are a malicious person, you can actually kill the client and manually wipe out its cache of transactions before it has time to retransmit transactions for chain B (therefore recovering coins that you had spent on chain A).

I think this scenario is worse because in theory the transactions aren't going to get copied over from the 0.8 chain to the 0.7 chain until the 0.7 chain overtakes the 0.8 one. The two versions aren't database-compatible, so anyone who follows the advice and manually downgrades to get on the right chain is going to lose all the transactions from the previous chain whether they want to or not.

The fork was at the block level not transaction level.

The transactions are on both chains. While they may be in v0.8 blocks and still unconfirmed in the v0.7 fork they do exist in the v0.7 fork. The only transactions which couldn't exist in the v0.7 fork are those generated in "v0.8 only blocks" and those are hard locked by the protocol for 100 blocks.

Had both halves of the fork existed for more than 100 blocks that would have presented a more serious problem. This is why the stakeholders (exchanges, merchants, miners, and developers) moved quickly to halt transactions, warn users, and move to the v0.7 version of the chain BEFORE one chain got more than 100 blocks from the fork point.

They never merge. But each should want to (and be able to) subsume all non-conflicting transactions from the sibling chain, so it's only a small number of 'double-spends' that wouldn't live in both. Eventually one history will win, and only the conflicting transactions from the losing history lose out.

Unless...

Perhaps an enduring, permanent split, under the right conditions, with people motivated to keep both chains alive indefinitely, could be a good thing. Among other things, it might solve the deflation problem, or allow a runt network to continue if the mother network were compromised by technical or legal attacks. (Or depending on your perspective, allow the mother network to continue if a runt network is created by certain attacks.)

While it's not the same scenario you've described, bitcoin forks like litecoin are interesting for similar reasons.

> Is there a sensible fashion by which two robust blockchain forks might merge?

No, but the "transaction graph" which underlies both chains can (and will) be merged, in some sense.

> If [lots of people conspire] to revert to an earlier blockchain, it could drive instability.

The blockchain will only ever split inadvertently, or due to probability (the unlikelihood of multiple blocks being orphaned). A majority of miners would have to conspire to begin mining on a chain with less than 50% of the hashrate, which would be a waste of resources if the chain fails (which it will).

There's not just an incentive but a probabilistic force preventing forks from occurring.

What if, rather than a client failing blocks that should succeed, a client is designed that accepts things (and generates things) that should fail, and yet becomes the most popular client among a very large subgroup (either by accident, or on purpose). I think that's the question being asked with regards to the "Asia, banks, etc." scenario.

Those are equivelent scenerios. If client A generates and accepts coins that client B rejects, it is the same as client B regecting the same coins that client A accepts.

Yes: I understand that they are equivalent in the final problem, which is precisely why I went to the effort to try to make the formation more specific; the argument ewillbefull was making that it is highly unlikely for this kind of thing to be a problem due to probabilistic reasons doesn't apply when you setup the problem in reverse.

There are two ways that a fork could occur. 1) 2 transactions happen at the same time and one of them happens to win. This is normal, and the loosing transaction simply re-transmits. This is also why you should wait (I think) ~5 minutes before you consider a transaction `validated`. 2) All of Asia (or another group) decides to fork. This is equivelent to all of Asia saying that they do not acknowledge all transactions made after a certain time. There are the same consequences as in a traditional currency when this happens.

Reply on news.ycombinator.com