Much like the discussion of “decentralization,” there is a sliding scale on identifying exactly what “censorship resistance” means. Bitcoin is indeed resistant to censorship, but it is also deliberately flexible under stress, and designed as a tool to enforce the truth—even when the truth is extremely unpopular.
The thing that secures transaction finality, in Bitcoin, is the game theory and economics of block building. As time goes on, it becomes increasingly expensive to reorganize the ledger, and so the costs versus the benefits of doing such a reorganization make it increasingly unprofitable to reverse a transaction over time, but it is by no means impossible. Fundamentally, reassigning an output on the ledger is just a small change in code, but what makes bitcoin resist arbitrary changes is the economics of coordinating the change on the entire distributed ledger—which requires social cooperation and cost.
Therefore, it is fair to call Bitcoin generally resistant to censorship, but unfair to refer to it as “immutable,” which is a common word used in Bitcoin conversations. That being said, there is a right way to amend the ledger, and there are wrong ways too. Bitcoin is a universal ledger of triple-entry accounting to ascertain global truths, so it is important that all changes are hashed and secured by proof of work—not just arbitrarily rolled back.
Where did this discussion of immutability come from?
The small blockers, of course! Given that BTC advocates do not see the value of frictionless global payments or increased integrity of data, digital identity solutions or data as a form of money, they had to re-engineer Bitcoin in their own image with a key, differentiating superlative. They chose immutability because it plays nicely with their desire for governance by sybils running what they call “a full node.” The nature of these nodes has been covered elsewhere, but the small blockers believe that wide distribution of the ledger is a feature to bolster this immutability. Curiously, the only things these nodes contribute in an adversarial environment is to split off of the network and carry on the ledger with essentially no hash power, but they pretend their nodes are powerful anyways. These “nodes” can also serve as a sort of alert system, maybe, but they are far less powerful than the original bitcoin alert system. More on that later.
The curious thing is that, fundamentally, many bitcoiners are aware of bitcoin’s imperfection in this regard. When Binance was robbed in 2019 of 7000 BTC (about $40,000,000 at the time), Binance CEO, Changpeng Zhao (CZ) reached out to Core Developer Jeremy Rubin under the assumption that a few lines of code could be pushed to all nodes to initiate a rollback of the blockchain and return the stolen funds. CZ even filmed a video message about it at the time because it was such a controversial topic.
Of course, there was confusion among all of the people who had been led to believe that BTC is immutable, but CZ was right! A BTC developer could absolutely act as a sort of fiduciary and make the decision to push out a new version of the node software and ask that the nodes run the new version which puts the stolen funds back into CZ’s wallet. This is technically a rollback, and not the right way to handle things.
But it has happened before!
In 2013, BTC software was updated from version 0.7 to 0.8 which debuted with a chain-splitting bug. Again, acting as sorts of organizing and centralized fiduciaries over the BTC blockchain, Pieter Wuille and Luke Dash Jr overruled Gavin Andresen’s warnings against orphaning the longest chain with the most proof of work simply because they could, but Pieter (who would later become a founding executive at the Mastercard-owned Blockstream Corporation) insisted that it would be best to centrally organize the orphaning of Bitcoin in order to choose the shorter, more valid chain—possibly even triggering a taxable airdrop event with the rollback. But, at the time, users were largely unaware of the power of the Bitcoin Core developers, and they simply trusted the actions of these custodians over the decision-making of the chain.
Note the authoritative tone they took against the miners in their communication logs:
Pieter Wuille: “All old miners will stick to their own chain regardless of the mining power behind the other”
Luke Dashjr: “and the sooner we decide on #1, the fewer it loses”
Pieter Wuille: “Even with 90% of mining power on 0.8, all merchants on an old client will be vulnerable.”
Luke Dashjr: “If we hardfork, all Bitcoin service providers have an emergency situation”
Pieter Wuille: “and we _cannot_ get every bitcoin user in the world to now instantly switch to 0.8 so no, we need to rollback to the 0.7 chain”
Using the official Bitcoin Alert Key which Satoshi had programmed into the protocol so that the stewards of the database could alert the contracted miners, the Core developers made contact with every miner and listening node on the network—demanding that they roll back the chain, downgrade to version 0.7, orphan the longest chain with the most proof of work, and make the unilateral decision to censor every single transaction that had occurred on version 0.8. Furthermore, this removed the block rewards that honest nodes had mined on the longest chain, and showed clearly that the miners of 2013’s Bitcoin era had lost any ability they were granted in their unilateral contract with Satoshi: the issuer who gave them the sole responsibility to enforce the economic rules of Bitcoin in return for receiving the diminishing block reward subsidy.
Gavin Andresen lamented, “the 0.8 fork is longer, yes? So majority hashpower is 0.8… first rule of bitcoin: majority hashpower wins.”
But that would not be the case. Despite the massive losses, “BTC Guild” one of the largest mining pools at the time, realized that the developers had forced them into a corner because of their lack of cooperative coordination at the node level – leaving a power vacuum of which the developers took full advantage.
So, in a move which would remove rewards from honest nodes, orphan Bitcoin and replace it with a new chain, making it Bitcoin in name only, Wuille ratified his sovereignty in the developers’ throne room of choice: BitcoinTalk, to explain why network-wide decisions to roll back bitcoin without means of arbitration were justified.
What is the right way to reorganize Bitcoin?
Bitcoin is fundamentally a timestamping machine for global truths. As we have seen, the Core developers are content to unilaterally take sovereignty over the chain, rob the honest nodes, reorganize blocks at will and orphan bitcoin in favor of the shorter chain. But the right way to handle a re-assignment of users’ holdings must be more systematic including a permanent trail of evidence on chain. Satoshi actually advocated for this using an alchemist’s analogy about gold becoming lead and then being turned back to gold again. He explained the use of bitcoin to coordinate an alert across the network to freeze a UTXO and return it to the rightful owner in the event of a theft. In theory, this could apply to accidental loss of coins too.
In 2010, Satoshi Nakamoto was having a discussion about the right way to handle the risk of theft in the situation of a sale with time delay for shipping. Under the assumption that bitcoin transactions were irreversible, the developers were discussing escrow systems and the need for trusted setups, but Satoshi brought up Bitcoin’s possibility to freeze and return a transaction as a deterrent for theft, stating:
Imagine someone stole something from you. You can’t get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it’ll be useless to them, although you still lose it too? If they give it back, you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.
It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about “money burning” for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.
So Satoshi seemed content with the notion that rather than introduce a trusted escrow set up, it would make more sense to have honest nodes able to coordinate to act as fiduciaries over the state of the network in cases where there was a provable theft. Once something was properly judged by the courts, nodes could reassign UTXOs with proof of work to make victimized users whole again by amending the blockchain records the way any other bookkeeper would in a double-entry accounting method.
This method has a few key strengths:
1: The entire series of events would be recorded. This is in contrast to the BTC Core method of developers rolling back the chain by fiat decree and censoring the history of missing blocks completely.
2: Bitcoin becomes less interesting to thieves, but more interesting for creative users and large investors. Since there would then be the assumption of a systematic arbitration process between users, courts and honest nodes, an extra layer of confidence in the usefulness of the chain would emerge, so rather than just being reorganized arbitrarily and chaotically, users would have recourse and nodes would have accountability—ushering in a new era utility with bitcoin.
3: Companies which lack the technical knowledge to care for private keys can have greater access to bitcoin, knowing that if they make a mistake, a block can be mined which could return funds which were mishandled or stolen.
Why hasn’t this been discussed before?
Actually it has! The discussion largely centered on the existence of the alert key, and whether or not its holders were a threat to Bitcoin’s assumed immutability. Well, of course they were because bitcoin was designed with the assumption that special circumstances could exist to coordinate a reassignment of UTXOs as we saw in 2013’s orphaning and replacement of bitcoin, and a similar event in 2010 which was organized by Satoshi himself due to a malicious exploitation of a catastrophic inflation bug by a clever (and still unknown) hacker.
In 2016, The BTC developers retired the Bitcoin Alert Key and deprecated its feature set after many years of bickering about whether or not it should have ever existed at all. Even though it was used during emergencies, it was viewed as a threat to the reengineering of bitcoin into becoming an unstoppable, irreversible network of slow and expensive transactions.
Therefore, with a whimper, one of the fundamental features of Bitcoin was eliminated, and it became harder for nodes to be able to coordinate on chain.
This has also made it harder to coordinate for “freeze and return” events, and it puts even more control into the hands of de facto leadership of the blockchain, which is not good for anyone—especially when the rules always seem up for debate with the developer intelligentsia. This is why CZ found it reasonable to call on the BTC developers to give him his money back, and it’s why nearly every blockchain carries some risk of developer capture until honest nodes truly take on their role as steadfast enforcers of the protocol in these sticky situations.
New to blockchain? Check out CoinGeek’s Blockchain for Beginners section, the ultimate resource guide to learn more about blockchain technology.