The myth of the full validation node
There is a long-running false narrative of “full validating nodes.” The dishonesty that has been sold as a truth is that running the Bitcoin node software while not mining matters in any way to the security of the network. The inaccuracy promoted is that you can make any difference as a “validator” without being a miner.
First of all, we need to look at the Bitcoin white paper again. A node is defined in detail. In the definition, we see that a node must mine blocks.
If you are not creating blocks, that is you are not mining, then you are not accepting or validating anything. You are merely doing as miners say, and it is explained in the white paper, too.
We will start by exploring what a so-called “full validating node” will do, if a double spend has occurred; that is, if the majority of miners accept an alternative chain to what your node has originally accepted.
The issue in Bitcoin is not validating rules. It is validating transactions in blocks.
If you have a validation node that sees and accepts a transaction in Block 4 of the image, and the majority of miners see and accept a separate transaction in Block 2 that conflicts (i.e. a double spend), you do nothing as a non-mining system.
Let us say, Alice is running a non-mining node, and she has been duped into believing the false narrative of the “UASF full validating or non-mining node.” Alice has a transaction paid to her from Bob. Alice is a merchant. Bob has just created a transaction to pay Alice for a valuable exchange that is completed using Bitcoin. Alice does not know Bob, and Bob is in an overseas jurisdiction where it will be difficult for Alice to take action against Bob.
Alice hence does not trust a 0-conf transaction, and waits to see that her full validating UASF node sees Bob’s transaction in a block. She sees this at Block 4.
Bob is a skilled attacker, and the transaction was sufficiently large to allow the attack to be commercially valid as long as Alice trusts her UASF node. Bob is a small miner. He could control 25% of the system using a compromised mining pool. He is the dishonest miner noted in the Bitcoin white paper.
Bob has also attacked Alice’s node. He cannot do it for good, but needs to do it long enough so she sees the longer chain first. To do so, Bob acts as a man in the middle, and slows blocks from the honest chain. Such is an attack that only works for UASF (foolish) nodes.
In an SPV model, Alice will take a header from any miner as long as it matches the required PoW conditions. In such a scenario, defined in the original white paper, Bob loses.
In the UASF model, Alice needs to download a full block and verify it all over. At scale, doing so can take a long time for her block, and it is simple to subvert and delay. Let us say that Alice is on an old ISDN line, and Bob can flood it. Bob can make a small block where his transaction will be included but where, say, only 100 transactions are included in his block.
Let us say that in such a scenario, miners are accepting 10 GB right now. It takes Alice 16 to 20 minutes to validate a normal block from miners. She accepts Bob’s later block in under 30 seconds.
Bob can use the time differential; Alice now sees and validates Bob’s transaction in his Block 4 before the real valid one in Block 2, that all other miners process. So, Bob has sent Alice a double-spent transaction, and she sees it as valid. The rest of the network sees Block 4 as the attack.
Alice will obtain a block from the valid chain that beats Bob’s attack block in time, but it can be a long time. It could be hours or days. The miner network has validated and utterly rejected Bob’s block in short order, with his block having next to no chance of catching up after the 6th block period.
Eventually, Alice reverts to the same chain as of all other miners. But, as Bob sent a payment to himself that was included in Block 2 and double-spent the amount in Block 4, Alice now sees her validated wallet as empty. Bob managed to pull one over on her.
If Alice had used SPV and trusted the miners, the system described in the white paper, then she would have been safe.
Even on her old slow link, Alice would have received the header of Block 2 and rejected Bob’s transaction. She would have seen a different spend when she checked the merkle tree of the valid block. She would have seen a block header in mere seconds and how the input Bob signed to her was also double-spent to the network.
Bob does not need to do much to attack Alice in such a way, as long as he keeps her thinking that her node matters and that she needs to validate the entire block, that miners cannot be trusted. Such is the irony. In not trusting the competitive process that is Bitcoin, in thinking her UASF node matters, she becomes less secure.
Bob can partly flood Alice’s network — slowing transaction and block propagation to her.
You see, the attack is the UASF. The deception that has been allowed to creep into Bitcoin (or that pseudo-Bitcoin called BTC) is that non-mining nodes help in any way. They do not. The concept lowers your own personal security, and limits the usefulness of Bitcoin.
Bitcoin only works when it scales on-chain. The attack has been to convince a widely deceived “community” that Bitcoin is about socialism, about “decentralising everything.” Decentralisation is a tool to introduce competition. Nothing more, and it is a small part of the system.
It is not about rules
The rules of Bitcoin are “set in stone.” Soft forks and all of the changes make something that is not Bitcoin. You are not validating Bitcoin, you are validating the fork of the week, when you allow soft forks and the UASF model.
Mining is not about changing the rules. The rules of Bitcoin were set in stone at version 0.1.0. It is a sound protocol, and much much more of the work that went into creating Bitcoin was designing rather than coding.
Even now, all the issues raised have been things I previously considered and planned for.
Bitcoin has had many trying to hijack it. The narrative of the “validating node” IS the attack. It is a slow and insidious one that is designed to slowly alter Bitcoin. In it, people start thinking that a slow migration from what was defined in the white paper to a SWIFT-like accounting system is an improvement. It is what Core have done.
The irony is that not one of the main core developers was ever known as a security and risk expert, before they became self-aggrandised as one. And yet, they have been selling how secure the alterations they have made to Bitcoin are.
The attack is the UASF. Bitcoin was secure and in SV remains so.
Over the next 12 months, I will be documenting at least 100 ways in which BTC can be subverted, before I get to the final one that, with the introduction of SegWit, cannot be fixed.
Bitcoin, as it was defined in the white paper, as a protocol was secure. It had code issues, overflows, and bugs, but the protocol was sound. In BTC, it is not.
All of the real changes to BTC have been about subverting the key controls in Bitcoin. They have all been about making Bitcoin something that cannot scale, that cannot function.
SV will be returned to the original protocol. It is close now, and will be closer as we move forward.