It has been claimed, mostly by proponents of Bitcoin SV, that by adding replay protection Bitcoin Cash capitulated a hashpower war with BTC that it would have won. Moreover, it's claimed that by not having replay protection between Bitcoin SV and Bitcoin ABC that the two competing Bitcoin Cash implementations will be able to have the sort winner-take-all hashpower war that Bitcoin Cash capitulated early on during the split with BTC. The former claim is interesting, but out of scope this post, and the latter claim is egregiously wrong.
To begin, let's recall what replay protection is. In a nutshell, replay protection is when a diverging chain D introduces a transaction format that is incompatible with the incumbent chain C, and disallows previously valid transactions that do not include that transaction format from being included in blocks past the forking block height.
What this does then is it makes blocks from D past the fork height get rejected by C's node, and it makes previously valid blocks from C get rejected past the fork height by nodes from D. Thus, without leveraging dirty tricks like diverting hashpower from chain C to chain D or vice-versa, in order to launch a 51%, the introduction of this replay protection prevents a hashpower war.
To illustrate this let's take a look at the following blockchain, where blocks labelled C are compatible only with Bitcoin BTC, blocks from D are compatible only with Bitcoin BCH and blocks labeled B are compatible with both chains. And let's say the fork height was 6.
---------------------------/D6->D7->D8
B1->B2->B3->B4->B5
---------------------------\C6->C7->C8->C9->C10
As the above illustrates (crudely), past the fork height, blocks from Bitcoin Cash and blocks from Bitcoin were mutually incompatible and were each rejected by their respective nodes. This is why even though Bitcoin (BTC), in the graph above has a longer chain, the blocks for Bitcoin (BCH) continue to be built on top of one another rather than redirecting towards the longer BTC chains nodes.
Now, what is it about the addition of replay protection that facilitated this split with no hashpower war? The introduction of mutually incompatible rules for both chains, right? BCH nodes viewed BTC's blocks, irrespective of their length, as invalid because they did not follow BCH's rules, and BTC nodes viewed BCH's blocks as invalid, irrespective of their length.
Do we have the same situation right now between ABC and SV? Yes.
ABC is introducing things like:
- Canonical transaction ordering
- OP_CDSV
and SV is introducing changes like:
- The allowing of more op codes in scripts
- The introduction of OP_RSHIFT, and OP_LSHIFT to the code
Consequently once the SV and ABC chains both include blocks with these divergent features they will have branched off irrevocably and in-communicably in a manner identical to how Bitcoin Cash and Bitcoin BTC branched off at the fork given their incompatible transactions formats.
For the sake of illustration, suppose SV completely out-muscles ABC with hashpower at the fork and eventually produces an SV-only block. Let's call blocks that contain ABC-only features like DSV, A, blocks that contain SV only features like OP_RSHIFT, S, and blocks that are mutually compatible between both chains, B.
B1->B2->B3->B4->B5->S6
Once the 6th block is produced S6, that is incompatible with ABC, ABC nodes will reject S6 and build their own block A6.
--------------------------/A6->A7->A8
B1->B2->B3->B4->B5
-------------------------\S6->S7->S8->S9->S10
Does this look familiar? Here we have a situation where ABC nodes reject S6 and any blocks built on top of it, and SV nodes reject A6 and any blocks built on top of it. This is identical to the situation at the Bitcoin Cash hard-fork with replay protection. Consequently not having replay protection does not facilitate a hashpower war when you have mutually incompatible chains. We're in the exact same situation as before and SV proponents need to stop lying about this.
Appendix
How do we have a hash-power war that prevents a chain split?
As an interesting aside, it's worth thinking about how we can possibly have a hashpower war that prevents a chain-split. The introduction of any hard-forked change will always result in a chain-split so long as there is any market interest in the incumbent chain. Had the BCH split been just a blocksize increase with no replay protection or EDA, and had it gotten say 90% of the hash-power, Core die-hards could have still kept their chain alive. They'd have had 100 minute block times for 20 weeks until the difficulty adjustment finally happened, but the Core chain has coped with absurd block-congestion before, and that does not seem to deter the most zealous among them.
Consequently, it seems to me that the only way the term "hashpower war" is particularly meaningful is when it is between two chains, one of which is compatible with another chain but more permissive, and the other which is more restrictive.
To illustrate what I mean, suppose again the only change Bitcoin BCH had introduced was larger blocks. In that case, though BTC nodes would reject BCH the minute it allowed for a block larger than 1MB, BCH nodes would always and forever be in a hashpower war with BTC, because BTC's rules would still be compatible with its rules. Consequently, miners would be forced to choose between either Bitcoin BTC or Bitcoin BCH immediately given that BCH could not survive meaningfully without greater hashpower than BTC.
This is not what is happening though with the situation between SV and ABC, as I have already detailed. The only way this could be happening is if one of either SV or ABC was saying we should introduce no changes come the hard-fork, and the other was saying we should introduce changes, but changes that would continue to accept blocks from the current rule-set as valid. In such a situation the side that wanted to introduce changes would start a hashpower war. That side could only survive with majority hash, though the minority hash side could still survive with any amount of hash.
[link] [comments]
source https://www.reddit.com/r/btc/comments/9poqvy/on_replay_protection_and_hashpower_wars/
No comments:
Post a Comment