Did you ever realize that the word upgrade has a counterpart, downgrade, but the word update has no counterpart downdate? Because progress only goes forward ...right?
The Bitcoin network has remained backwards compatible ever since Bitcoin's release on January 3, 2009.1 This is despite numerous attempts to fork the chain. This great feat of Bitcoin is recognized by many, segwit users included. But segwit nodes, while having maintained backwards compatibility, have also introduced new rules into the system. The real bitcoin does not recognize these new rules. What are the consequences of this, and how will any future fork wars play out? I foresee three possible outcomes.
The 1st possible outcome is the status quo is maintained, meaning that all future blocks in the current chain remain compatible with both segwit and trb nodes. Segwit coins and trb coins remain with their expected owners and the two networks coexist in symbiotic fashion.
The 2nd possible outcome is that at some point in the future a segwit-incompatible block is mined where the miner snags a segwit user's coin. At this moment we fork into two chains, trb-chain (with height h+1) and segwit-chain (with height h). Segwit nodes see trb-chain as invalid, and thus remain on segwit-chain. Trb nodes see both chains as valid, but switch to trb-chain owing to its greater height. If the trb-chain grows faster than the segwit-chain, the fork persists. If the segwit-chain manages to catch up and surpass the trb-chain, trb-nodes will reorg and adopt segwit-chain, putting us back in a post-hiccup version of outcome 1.2
The 3rd possible outcome is trb becomes economically irrelevant. Perhaps the segwit users/bitcoin core team manage to pull off a hard fork that wins in the market place, or trb nodes all go offline. Revisionist history wins, and the roots of Bitcoin fade away into the cosmos.
Given the information I have, all three of these scenarios seem equally likely. The first is the status quo, but it is in an unstable state while both trb and segwit nodes are online. The second scenario can happen at any moment, but it requires the active move of a miner, and it may require a coordinated effort of 51% of the hashing power. The third scenario is the ultimate objective of the enemy, and thus may come to fruition despite its negative consequence for everyone using bitcoin.
No matter how things play out, the best decision today is to move your coins out of "3" and "bc1" addresses and into a p2pkh address aka "1" address. Why would you put all your bitcoins at risk? To save a couple of mbtc on transaction fees?
- The first block with height 0 is hard coded into trb and is dated Jan 3, 2009. The second block, which is the first block not included in the source code, was mined on January 10, 2009. [↩]
- History has shown that miners like to SPV mine. This means they sometimes forego validating transactions in blocks mined by other pools in order to get a slight head start in mining the next block. So if the segwit mining cartel does not validate its blocks, it is possible that a solo miner could throw a wrench into the segwit system by mining just one non-segwit-compliant block. [↩]
Why would a hypothetical "hardening of the segshit softfork" PRB-fork stop merely at "perma-harden segshit" though?
The naive POV, "all forks to date resolved in the direction which'd benefit miners", doesn't quite hold, incidentally: hypothetically, e.g. a "tx fees start at 1btc" fork is possible -- and even "softly", at that; but not won (nor afaik happened at all) to date. nor, e.g. a "gift satoshi's hodl to miners" fork. worth considering why.)
For that matter, worth considering "why was segshit brought in as 'soft' fork to begin with?"
Incidentally, may be worth conducting a game-theoretical experiment: bake a fork-noad where 1btc of satoshi's hodl is "gifted" to the claimant of each mined block after $index, "while supplies last." Per the naive POV, "51%" will jump on it.
> Why would a hypothetical "hardening of the segshit softfork" PRB-fork stop merely at "perma-harden segshit" though?
No, i agree the hard forks would continue on and on. Afaik this is the case with Bitcoin Cash, it itself has a subfork BSV. The main aspect of the third outcome I propose is that trb nodes are no longer running, not that there is a hardfork.
> The naive POV, "all forks to date resolved in the direction which'd benefit miners", doesn't quite hold, incidentally: hypothetically, e.g. a "tx fees start at 1btc" fork is possible -- and even "softly", at that; but not won (nor afaik happened at all) to date. nor, e.g. a "gift satoshi's hodl to miners" fork. worth considering why.)
Well I would argue to say that "tx fees start at 1btc" does not work well because the miners believe that chain will be valueless, i.e. the miners will perhaps gain btc, but those btc will be worth less.
> For that matter, worth considering "why was segshit brought in as 'soft' fork to begin with?"
I believe this is precisely because attempts to hard fork failed through economic attack. It is not possible however at the current moment to dump trb coins on a separate segchain, because the segchain and trbchain are the same. So there's no ability to "crash the enemy's market".
> Incidentally, may be worth conducting a game-theoretical experiment: bake a fork-noad where 1btc of satoshi's hodl is "gifted" to the claimant of each mined block after $index, "while supplies last." Per the naive POV, "51%" will jump on it.
I don't think this will have any traction because it will be impossible to convince anyone that this chain has value, including the miners.
> The main aspect of the third outcome I propose is that trb nodes are no longer running
not clear to me that them running has much to do with preventing the segshit-hardfork to date, though.
> impossible to convince anyone that this chain has value, including the miners
aha.
> not possible however at the current moment to dump trb coins on a separate segchain, because the segchain and trbchain are the same
my contention is that if suddenly they could no longer be seen as 'the same', the hard-segshit fork would play out similarly to BCH. given as hard-segshit would be effectively the same proggy as the BCH client.
I'm ignorant of how the third possibility works. How could this mutually compatible mechanism strangle its infrastructure, without killing itself?
@Verisimilitude
The number of people who publicly run trb nodes is quite small. If the nodes were to all go offline, then bitcoin core would be able to tweak their code so that they issue a hard fork with what-would-be trb, and no one would notice.
I agree that the chance that prb pulls off a hardfork while there are people paying attention is low, given the numerous failed attempts already.
@whaack note that there'd be not two but three types of noad after the fork -- TRB, pre-fork-PRB, and fork-PRB.
... the other interesting IMHO aspect is that plenty of folks who currently not paying attention, would likely start if they were to smell payola. E.g. from my and over9000 other people's POV, "BCH" was a glorious phree gift of coin, and was worth paying attention to for precisely as long as it took to split off and liquidate the "gift".
> @whaack note that there'd be not two but three types of noad after the fork -- TRB, pre-fork-PRB, and fork-PRB.
I thought for a moment "is it possible to create a fork-PRB that is only a softfork to pre-fork-PRB but a hardfork for trb?" I think the answer is no, so yes you are right, good point.
> ... the other interesting IMHO aspect is that plenty of folks who currently not paying attention, would likely start if they were to smell payola. E.g. from my and over9000 other people's POV, "BCH" was a glorious phree gift of coin, and was worth paying attention to for precisely as long as it took to split off and liquidate the "gift".
If I understand correctly, this means ~ if trb-nodes mostly go offline, but then one day prb forks, people will be motivated to startup some trb-nodesagain so they can sell on the prb-fork and keep the trb-coin. If so, yes I agree.