Is Satoshi Nakamoto Being Proven Right About Multiple Clients? – Trustnodes

Is Satoshi Nakamoto Being Proven Right About Multiple Clients?


A decade of experience in blockchain tech is beginning to gather a body of data that can be analyzed to reach conclusions where there are differences of views.

A significant such difference is multiple clients. In bitcoin, Blockstream managed to get miners to sign a document that binded them to run only Bitcoin Core.

Why on earth they chose to do so isn’t too clear, but ethereum has taken a different approach in initially launching multiple clients that ended up with a duopoly of Geth and Parity.

One can now say that duopoly did not work out very well with Parity currently in the process of being handed over to the “community.”

Why did it not work? Many reasons but the main one is probably natural incentives. If you’re working for Geth for example you naturally want miners, business, and everyone, to run Geth, or Parity if you’re working for Parity, or let’s abstract this and say Mynode.

At the beginning mynode and yournode share the same goal and therefore are friends, but if there is a bug that maybe comes from mynode, you’ll probably want to point out that it was mynode’s fault and therefore people should use yournode.

That might sound like stating facts, but mynode devs would probably not be very happy about yournode saying all this, so maybe they’ll point out things about yournode.

Step by step as time passes we go from what initially was one team, albeit working on different clients but kind of the same code/project, to two teams that are barely on speaking terms.

That’s the nature of competition, and what they are competing over is ultimately money. Indirectly in a way, but also fairly directly in as far as if your client is or is perceived to be better, then you have more nodes, users, etc, more say on what code goes through, and ultimately more funding.

In competition there are two approaches. You race to go faster, higher, stronger, ignoring the competition in a way. Or you race to escape the bear, that being the parable where you don’t have to be able to run faster than the bear, you just have to run faster than the next guy.

Obviously we all like the people that take the higher, faster, stronger approach, but they are not necessarily the ones that win. The trippers as one might call them, the ones that throw an obstacle for example to the guy behind them who is about to overtake them, might win instead.

As such one might logically conclude that minimizing competition can in some instances be far better than facilitating it.

The Coordination Problem

If one wants to, it is probably possible to reduce everything and every design to one of facilitating coordination or the ability to more efficiently organize.

It is also probable ideas are the most powerful coordinating tool, and therefore stand above row power, or money, or indeed armies.

Ideas are subject to that dictum that it isn’t the strongest or the most intelligent that survive, but the one most adaptable to change.

That clash between an idea that coordinates and the need to adapt to change is probably a good explainer of many problems.

Habit is a good illustrator of it. It is difficult to change because it automates coordinating problems like what’s the first thing you do when you get up.

Time being very limited, you certainly don’t want to spend much of it, if any, every morning on deciding whether to have breakfast, go for a run, brush your teeth instead, or whatever else.

If the habit is running, then to form it meets resistance because if you’re changing things all the time then you’re not automating many decisions through habit.

For the same reason once this running habit is formed, you meet resistance if you decide to not go for a run by feeling uncomfortable.

The point of this being to point out why two teams might not necessarily be better as they might not necessarily be on the same page and thus might cause coordination problems which are ultimately addressed by the two teams splitting.

Ideological Redundancy

The inefficiencies of two teams doing the same thing might have been the least of Nakamoto’s worries when he made this comment a decade ago:

“I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.”

That’s pretty strong words and it seems to be for a very good reason as experience shows so far because it appears every-time there are two prominent teams, there’s a chain-split of sorts.

That’s because mynode devs and yournode devs might have different ideas about what code to put through. So eventually there will be some argument because both want their way of doing things, leading to a breakdown in coordination due to no good decision making mechanism.

Hence hierarchy. Two teams can be better than one if they are under one management which can step in, but if there is no one to have the final word then a lot more time will be spent on solving coordination problems than on building.

That however goes against the idea there should be two or more clients so that no one dictates or captures the network, but experience might be showing that suggestion to be far too naive and reality might be indicating it is actually the opposite.

It may in fact be the lack of a final word that facilitates capturing, whether within a client or between clients, with this problem between the need to coordinate and the desire for autonomy, or decentralized decision making, being a very ancient one.

The best illustration is perhaps also the best argument for multiple clients. That being if one has a bug and the other doesn’t, then the network can still keep running.

That ignores the much more complex reality of why one client had a bug to begin with, and the other didn’t. Could it be that resources were spread so thin that if they weren’t there wouldn’t be such bug? Might it be that yournode was happy to let mynode keep running with this bug even though perhaps they knew about it? Would it be that the bug would be addressed way faster if the resources were in one team? Presuming a cross-client decision needs to be taken, would consensus be reached faster, or at all, if it was one group instead of two?

The answers may well depend on circumstances, but generally it clearly appears to be the case that multiple clients translates to multiple networks.

The Hayek Way

In its intellectual foundations arguably this space runs on the ideas of Hayek as espoused in the denationalization of money. Ideas that are general and abstract and therefore are being fleshed out through experience.

In his time even computers were not quite a thing yet so he imagined there could be centralized companies issuing private market money in a competition with each other that tends towards maintaining the value of money as relatively stable whereby one unit buys you an apple today and still does so, no more nor less, in a century.

Bitcoin has a very specific monetary policy in a complex design that is revealing considerable information on the nature of money, but Nakamoto pointed out that people should create their own network if they want things like a name service.

So we now have all these different networks that do all these different things that are subject to the judgment of the market.

Meaning decentralization is more this competition between different projects, rather than within a project.

From that it becomes quite clear why Nakamoto considered scalability not a problem at all, even if it translates to datacentre nodes.

To him it wasn’t a problem because perhaps he though good management would not come from within the network necessarily, but in the competition between the networks.

Economies of scale would have naturally led him to think the network itself would grow to be fairly centralized, with the statement that “the core design was set in stone for the rest of its lifetime” suggesting he clearly thought you can’t have two nodes with different parameters on the same network, and thus you can’t quite have competition.

You’d instead have a design enforced by certain incentives that continues to be enforced even if certain components – like devs or miners or prominent businesses – become centralized. With the decentralization within the network being the test of whether these different components can coordinate together to act against the users.

Where it is less a matter of maliciousness or undue enforcement from outside the network, and more a matter of “better,” different interests between these components create friction and schism, with the design thus enforcing the ultimate decentralization: multiple networks.

Where this jungle like prism falls is in largely ignoring the effects of this competition on let’s say mothers.

The idea here is basically a ruthless fight of titans, a war of market forces, that adds steroids to that dictum of those most adaptable to change survive, not the strongest or the smartest.

As such you’d think what this analysis proposes (has led us to) is a complete disregard for starving babies who should eat cake if their parents were too busy to keep up with the deteriorating bad management of a certain network, coin.

Like the plunge of the Russian Rubble, or the Iranian Rial, or currently the financial collapse in Lebanon, or the bankruptcy of Greece and Detroit, or last century’s depression in the United States, or indeed – though one step removed – the breaking of the Bank of England after it joined the European exchange mechanism.

This thus being how things are, not how they are being proposed. Experience instead tells us what is being proposed is a bit different, and it is different probably because of habit.

That experience being… we’ll take two. When BCH split from bitcoin, it started off from $50 at the low and reached $5,000 at the high. Bitcoin went not from about $2,000 to $200, but to $20,000.

When ethereum roared in the flippening, bitcoin roared more. When ETC rose, ethereum went parabolic.

It is not thus the case that an instant shift occurs, if one occurs at all. It instead appears to be the case that a gradual play of competitive forces settles on satisfying different interests to the added benefit of all interests.

Making it the opposite of titans waring over burning houses, because perhaps these titans can not quite war.

If we take the ruble for example, to metaphorically burn all the houses within that geography you force the government there to devalue through sanctions or whatever mechanism. In the case of Lebanon by the government just stealing their money.

The mothers here have no choice, no one is asking them, no one is even talking to them. But in the crypto space they can just chose to ignore something, or diversify a bit, or even move, with the combined decision of all asset holders presumably concluding to a response to events that is in the interest of all asset holders.

Thus making the competition between different projects far too gentle, certainly compared to national monetary competition between countries where feedback isn’t quite decentralized to the level of even the mother.

So concluding with this analysis that has led us quite far from where we began, one can perhaps say that the need to coordinate in a way that accommodates market feedback/autonomy might suggest the most successful project will be the one that can best balance hierarchical centralization with decentralized input.

Editorial Copyrights

Comments (2)

  1. A faceless currency wars with nothing. Sounds perfect.
    Who created BTC?

  2. The problem is government, when it comes to money there try to make people feel like there are the only source of controlling money. Whereas the DAO gives no full right for that if a proper management is being designed
    in a decentralized input ☝️

Leave a Reply to Socrate page Cancel Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>