Blog > Bitcoin & Blockchain Tech

Satoshi and the Byzantine Generals

By Craig Wright | 24 Mar 2020 | Bitcoin & Blockchain Tech

Before I launched Bitcoin, I had been discussing how the proposed system would work. [1]

Many people have failed to read my white paper and assumed that Bitcoin is a voting system that allows rules by consensus where every individual has a vote. The white paper says:

If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.

It does not say “one-computer-one-vote”, as each CPU does not represent an individual. It doesn’t represent nodes running as users on the network. The confusion stems from a radically misaligned understanding of the Byzantine generals problem.

Bitcoin does not give every ‘user node’ on the network a vote. Bitcoin nodes are generals. Generals form a small group of individuals who are easily detected and whose actions are easily attributed. Generals are not privates. For each general in the network, there will potentially be millions of privates. In other words, for each node on the network, there will potentially be millions of users. The only way to become a node on the Bitcoin network is to solve block puzzles. It is not the attempt to solve block puzzles, it is to actively solve block puzzles. If you are a Raspberry Pi user, and you never solve block puzzles, you are not a node on the Bitcoin network. Bitcoin and the forks of Bitcoin (the BTC, BCH, and other systems) [2] are all controlled through the actions of at most 10 miners, which are the nodes. Where a miner has multiple access and egress points, they maintain their existence as a single node.

So, where you have a miner running multiple ingress and egress points, they are but a single node. I explained in the early years of Bitcoin:

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate. [3]

To ensure that there is no misunderstanding of what I said, note that it is the creation of server farms that will service the network. As such, a group of commercial nodes, that may have ingress and egress points feeding an internal distributed node structure and could even be globally decentralised across the world, is owned by a corporation and acting as a single node. In time, they will be the future processing facilities for banks and commercial activities around the world. There may only be 100 miners globally, that is, 100 nodes, but they may have millions of machines:

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN. [4]

And so it comes that miners, or nodes, are generals. Users can utilise the network using simplified payment verification (SPV) and maintain the ability to verify and validate transactions over the network. They only require the header to each block. Luckily, nobody understood what I said, leaving me free to patent the only way we can scale Bitcoin:

The design outlines a lightweight client that does not need the full block chain. In the design PDF it’s called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can’t generate blocks. It does not need to trust a node to verify payments, it can still verify them itself. [4]

What Is a General?

If we go back and look at the original Chinese generals problem, you will start to see that what matters is not the number of computers but rather the pooled computer power controlled by a single entity that needs to coordinate with other entities. Each general controls an army in the consensus and distribution problem. The flaw in the understanding that many people have lies in treating each general as an equal, as if they each had one vote. But the generals do not have a single vote. Each general votes based on the size of their army. It is not a case of needing, say, three out of five generals to prove that they are loyal in the scenario and problem, but rather one of pooling and proving the relative strength of each general.

For instance, one general may control 100,000 men, while four others may control 40,000 each. Here, there is a total of 260,000 men in the combined army. If the general with 100,000 men gains support from one of the other generals, the two form the controlling force. Here, two generals can have more combined power than the other three and win. What we see is not a consensus based solely on the number of individuals. It lies not in running up individual IP addresses or having individuals vote. If such were the case and the three generals opposed the general with 100,000 men, then the three generals would win, even with a smaller force. The solution here is not based on democratic voting, it is based upon demonstrated resources.

Bitcoin, in fact, any blockchain-based system, is anti the vote by the masses. There is no way to create rules by consensus across individuals in any blockchain. Bitcoin was never designed as a demagoguery, it is designed as a commercial system where the nodes, the generals, are visible and the amount of resources they invest and the level of their effectiveness may be publicly validated.

The entire purpose of solving the Byzantine generals problem lies in finding a solution for reliable computing systems. It is not about voting, democracy, or the creation of rules by consensus. If people bothered reading any of the source material in our post-wiki world, they would understand that the problem concerned ensuring that computer systems could be created on a distributed basis in a manner that would enable them to handle malfunctions. Bitcoin is distributed to enable reliability. There is no distributed consensus dictating the rule of the system. In fact, such a myth covers the deception promoted by a few disingenuous developers, who are running a partnership they seek to hide through fraudulent claims that they are decentralised. Groups such as Bitcoin Core and Bitcoin ABC — neither of which has anything to do with Bitcoin anymore — are intentionally deceiving investors, while acting as central issuing parties and controllers over the network.

We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement. [5]

When Leslie Lamport defined the original problem, that I sought to solve through Bitcoin, he simplified the scenario by not explaining the fractions of the army maintained by each general. In distributed computation problems, where a variety of components function on a problem that is distributed across multiple nodes, it is not essential that each node is equal. Likewise, in the Byzantine generals problem, each general may not have the same size of division in the army. Lamport simplified the problem by treating each general as commanding an equal number of troops. Such is one specific version of the problem, that is far simpler to solve. With Bitcoin, we cope with a more difficult version of the problem; we do not even know, in advance, how many troops each general commands, nor the strength of the troops. We solve such a problem in a game-theoretic manner: we test the capabilities of each general and the strength of the division they control.

Each general would be capable of lying about their individual strength.

In a distributed computation problem, reliable computing solutions are not about the number of systems but rather the individual capabilities of each system. The scenario is not based on one-computer-one-CPU. Each computer will have a different number of CPUs.

Leslie Lamport failed to understand that game-theoretic signalling systems provide the solution. Bitcoin mining is analogous to the peacock’s tail. The more resources, the longer the tail, each general can afford to waste while remaining alive, the more they may demonstrate fitness. Voting as defined by Lamport [5] is not the vote by individual but the effectiveness of components. When Leslie Lamport released his paper in 1982, the majority of distributed reliable systems would have utilised the same or similar chips. It was not foreseen that a distributed computation problem would grow towards the scale that exists upon the Internet today, and so the more complex version of the Byzantine generals problem, that I would go on to solve in Bitcoin, had never even been attempted in his solutions.

Proof-of-work is not proof of how many people agree. Rather, it reflects how much total computation is expended:

After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time. [1]

The proof-of-work chain was developed to ensure synchronisation across a global distributed database. The synchronisation between nodes (miners) allows for the simultaneous solution to the “global view problem”, which users would otherwise face running SPV.

In my original communications to the Cryptography Mailing List [1], I did not portray the problem as Lamport’s simplified version of it, with each general having the same size of division as another. I said that a majority of CPU power was needed, which is not the same as an equal number of generals. It is the majority of CPU power. In Bitcoin, nodes are generals. They are miners. The users are not nodes on the Bitcoin network, and do not create validated blocks. There is no two-step process in Bitcoin where users verify the actions of miners, as would wrongly be implied by some:

Without a consensus method, ‘non-mining nodes’ have no say. It is irrelevant whether you like it or not; Bitcoin, any blockchain-based system does not create rules by consensus, but it allows the vote exclusively made by such nodes that solve blocks, ones with skin in the game.

Notes

[1] See: https://www.metzdowd.com/pipermail/cryptography/2008-November/014849.html (accessed 20 March, 2020).

[2] Note that Bitcoin does not ‘fork’ into alternative systems. The BTC and BCH systems are passing off as Bitcoin in order to defraud investors. The only version of Bitcoin is BSV, which was launched in 2009.

[3] See: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 (accessed 20 March, 2020).

[4] See: https://bitcointalk.org/index.php?topic=286.msg2947#msg2947 (accessed 20 March, 2020).

[5] See: http://lamport.azurewebsites.net/pubs/byz.pdf (accessed 20 March, 2020).