Your Full Node Is Impotent

As we know, a soft fork is a change to the consensus rules which narrows the rules such that all transactions and blocks valid under the soft-fork will also be seen as valid to preexisting clients.  Another way of saying this, is to say that a soft fork is a change to the consensus rules which existing full nodes cannot detect / will always accept as valid.

To initiate a soft fork requires near-unanimous miner consensus. Once miners are in agreement (collusion) on the soft fork, they are able to implement the change without permission, or even the awareness of, any other actor in the system. Practically speaking this means that full nodes are vulnerable to any soft-forked changes implemented by hostile miners.

Let's take a case in point. A hypothetical user, let's call him "Greg," has studied the Bitcoin code and found something fascinating about it. Among the consensus rules is this line of code:

static const unsigned int MAX_BLOCK_SIZE = 1000000;

Aha! One of the rules of this system is that blocks can never be larger than 1MB. Greg realises that if he and his peers do not change this consensus rule, miners will never be able to build a block larger than 1MB in size, permanently limiting the rate of chain growth.

For Greg this is very important - as far as he's concerned, it's as important as the 21M coin limit - so Greg happily installs and runs the code knowing that no evil miners will ever be able to bloat the chain with blocks larger than 1MB.

Along comes Greg's arch-enemy, let's call him "Pieter," who codes up a sideblock hack called "Separated Witness" or Sepwit, and sells it to the miners. They all start running Sepwit, which enables permission for blocks larger than 1MB via soft fork. Pieter is clever, and knows that Greg will never accept blocks larger than 1MB - this limitation is the reason he agreed to run the code in the first place - so Pieter cleverly codes Sepwit to detect when old clients are requesting blocks and serves old clients a hacked, incomplete block that appears complete, but is missing critical validation data (signatures). Pieter privately convinces miners and some other major exchanges to run Sepwit, and they start mining blocks larger than 1MB.

Now, if Greg knew about this, he'd instantly freak out and sell all his Bitcoin, because his stake in Bitcoin was contingent on the existence of this specific consensus rule. Although Greg is running a fullnode which validates that every block adheres to every rule Greg deems critical, he's none the wiser that the other participants of the system are breaking his all-important rule. When Greg asks for blocks, these other participants just lie to Greg and send him a mutant block with signatures removed, instructing his client not to bother with signature validation at all. As far as Greg is concerned, the rules of the system have never changed and everyone else is playing by the same rules as him. He confidently pats himself on the back for running a full node that validates that every block produced by miners is under 1MB.

It's clear in this example that Greg's "full node" is not offering him even one iota of protection against "malicious big block miners." A soft fork changes the consensus rules in ways that full nodes cannot detect. Greg's full node is validating... bupkis. From Greg's point of view, Sepwit isn't an upgrade, it's an exploit, first breaking the rules, then lying to him about it.

So let's first all acknowledge that soft-forks provide clear demonstration that nonmining full nodes cannot ensure miner honesty. So how can miners be kept honest?

It is clear that the only line of defense against malicious miners is found here:

> To initiate a soft fork requires near-unanimous miner consensus.

The only way to prevent a change in the consensus rules is to mine an opposing chain. If a change is soft-forked into the system, then nonminer nodes are impotent to the change. To prevent the change, you must mine.

This is why Satoshi repeated the same concept over and over in the white paper:

> The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

What's the lesson learned here?

The only thing that can stop a dishonest miner with hashpower is an honest miner with more hashpower.

__

This article was originally posted on yours.org before that site's owner had a mental breakdown and turned his site into a dysfunctional ghost town. It was then reposted on honest.cash before that owner decided to give up as well. Third time's a charm!

if you like my content and would like to see more of it for free here at read.cash please consider a tip!  thank you!