Satoshi and the Byzantine Generals

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:

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:

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:

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:

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.

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.

Related posts:

You know how all those sales and thought leaders always tell you that you’ll work 80% of the time for 20% of the profit? Or, some sort of sentiment along those lines? Well, this rule is similar…

Using Gulp 3 for many years, it’s been a while since I started thinking about refreshing my development workflow. At least, I read the doc. The more you read it, the more you realize it will be very…

In preparation for the launch of the first Forest Knight pre-season, we made some changes to how the arena ranking system works, how matchmaking is done, and how a win/loss affects trophies. In this…