5 ms·
> 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 m
by ewillbefull 14y ago
> 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.
- saurik 14y agoWhat 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.
- gizmo686 14y agoThose 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.
- saurik 14y agoYes: 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.