Blockchain Meandering

In its pure form, the Bitcoin blockchain is not only peer-to-peer, it's "peer-to-all-peers". So it suffers even more from the weakness of P2P systems - scalability, i.e. exponential traffic increase as it grows. The proposals I've seen (lightweight client, larger blockchain size) are linear patches which shift the exponential

In its pure form, the Bitcoin blockchain is not only peer-to-peer, it's "peer-to-all-peers". So it suffers even more from the weakness of P2P systems - scalability, i.e. exponential traffic increase as it grows. The proposals I've seen (lightweight client, larger blockchain size) are linear patches which shift the exponential curve slightly further into the future. They don't negate the real issue. That first graph is theory...

but this graph is reality:


There's other linear patches we can do. Like everyone else, I originally focused on scalability of blockchain size and calculation cycles. So I started porting the blockchain SQL schema to a graph database, as a performance experiment. We could also substitute MQTT for the HTTP protocol.

But then I realized these still only shift the point of failure a little further into the future.

Here's a simple model of P2P scalability versus a centralized (mediator) model. Centralized systems exist for a reason, they reduce net transactions, i.e. they're more efficient. By adding a management node, total transaction cost shrinks 33% and that's at a very small scale:

As near as I can determine, as of today (Oct 18, 2015), Bitcoin has 2 or 3 million real users. While researching scalability problems, I came across this analysis:

http://hashingit.com/analysis/33-7-transactions-per-second

... the last time we could hit 7 TPS was sometime in 2011. Right now we're lucky to be able to achieve much over 3.2 TPS; it also means that we're at about 30% of the total capacity of the network! In fact on several individual days we were at 40% of the total capacity of the network.

... Once we start to hit 100% even for relatively short times then that will start to affect the speed with which transactions find their way into the blockchain, especially as the 10 minutes between blocks is only a mean, not a guarantee.

What this tells me is that Bitcoin isn't capable of being a global currency (perhaps not even a national currency) and may not even scale another 10-fold (30 million users).

But perhaps "global currency" shouldn't be a goal. To illustrate, let's look at the Euro. Imagine if you harness a donkey, a race horse, a turtle, a cat and a dog to pull a wagon. It's not going to work very well or efficiently, even if they cooperate.

So we can imagine scalability as a function of consensus:

We can dial in a range of consensus to achieve higher scalability which is the idea behind the light clients, Open Transactions and Trustbits. But most financial transactions are local (similar to the Internet. People care most about what affects them locally), so we can imagine a system of Bitcoin derivatives, set to a scalability and mining algorithm which is impedance-mapped to each country's inertia:

where the great majority of traffic occurs within a local bitcoin network and consensus could range from pure P2P for all participants to a small set of central banks (like the 12 Federal Reserve banks in the US).

Now we only need a national scalability (although China and India could be a problem):

Sweden - 10 million
Germany - 80 million
Chile - 18 million
Mexico - 155 million
Vietnam - 90 million

Most likely the Mexican bitcoin consensus would be more centralized than Sweden's, possibly a couple thousand miner nodes, etc.

Now we have two configurable parameters for a digital currency framework - mining algorithm and degree of consensus. Mathematically, these are probably quite predictable, i.e. transparent and would be easy to trade on, in other words, a predictable currency exchange. We'd probably want to translate degree of consensus into some kind of risk factor.