A reason or excuse givento hide the real reason for something.
--Thunder Genesis Block(?)
Motivation
Bitcoin (BTC, the currency) in its current form can scale — enough to handle every txn in the world! It just needs the right combination of layer 2.
This post will introduce Thunder, a large-blockchain sidechain network. By “large-blockchain sidechain” I mean a sidechain network that is essentially the same as its mainchain network, but with a larger block size/sigops limit.
A. Today's 2nd floor
The Lightning Network offers some solutions, but if every user requires bytes on Layer 1, then the main scalability benefit of Layer 2 is lost. (1) Custodial solutions (as originally envisioned by Satoshi and Hal Finney in 2010) also work well and are user-friendly… but users have a responsibility to the custodian.
Below is a table comparing Thunder to these two more prominent Layer 2s (LN and Custody):
See here. 75/222=.337.
The main problem with custodial Bitcoin is that this strategy has already been tried with gold, and after a while people care less about the underlying gold and more about the custodian’s ledger (i.e. the custodian’s view on who has how much money).
Statechains are another layer 2 with very interesting and unique properties. Namely, they do not require layer 1 bytes to onboard every new user, but they do require that every UTXO used "in" the statechain be onboarded via layer 1. This is better than LN, but still problematic.
SNARKS do not help with scalability at all, because they do not solve the so-called "data availability problem". There is no way to use a SNARK to recover the sequence of events that led to its creation. There is also no way to audit a SNARK to ensure that it worked properly without having all the original data at hand. Therefore, SNARKS do not help with scalability and may only serve as an enhancement to SPV-level security.
B. New Framework
An old criticism, scaling by increasing the block size, is to run something like:
It shows that capacity increases are naive, unprincipled, and undisciplined, and that they degrade the quality of the entire network. In contrast, enforcing property rights (i.e. enforcing a 1MB block size limit) may seem harsh, but overall, this kind of "tough love" is the only way to build reliable, sustainable, high-quality systems.
That criticism is accurate, and I’m not trying to disprove it!
But I do want to change that a bit. Instead of having trains be "100% clean" vs "100% overcrowded," I'd rather people think of the same car with different sections: first class, business class, coach, etc. In that model, passengers have different experiences in many important ways, but they also have some things in common.
First/Business class is small pieces of “layer 1” — expensive but high quality; cheap nodes, reliable access to the blockchain, high txn fees.
Coach will be a big-block “scalability sidechain” for layer 2 — cheap to use; but more problematic full node experience, less decentralization.
But crucially, both “classes” can benefit from sharing the same plane. In the sidechain analogy, this is two chains sharing the 21 million coin limit, sharing hash power, and being interoperable (which means someone who normally flies first class can choose to downgrade to economy to save money, and someone who normally flies economy can choose to upgrade their experience by paying for first class). In a world without sidechains, people would have to fly planes where everyone only had one class.
Transactions in the real world come in all shapes and sizes. Not all transactions require the same level of trust, and not all transactions can afford the same fees. See also.
C. Power decentralization
A one-size-fits-all approach to decentralization actually makes Bitcoin vulnerable. Committing to a policy of “very decentralization” is a gamble. It’s a bet that says: We live in a hostile world.
If, on the other hand, the world is good, we lose the bet.
Decentralization is useful for powerful people like the de-government, the mafia, dictators, tech giants, cancel culture, etc. In order to get this valuable decentralization, Bitcoin must sacrifice other valuable things: ease of use, txn cost, engineering effort, etc.
So in a world of friendly “powerful people” promoting all cryptocurrencies, the advantage goes to the less decentralized coins (ETH, BSV, etc).
Worse, the “powerful” may realize this, and use it against us. At first, they could bide their time and let all cryptocurrencies flourish, thereby (via network effects) allowing the least decentralized coins to use their natural advantages to eventually displace the others, including BTC. Once decentralization is cleared from the crypto world, the “powerful” could then “tap” in and see what they can safely get away with (using network effects as an anchor). Once that’s done, they can slowly tighten the noose from there. See also.
If users could choose the level of decentralization they want (which is what Thunder allows), then the entire risk could be avoided. In Thunder-world, we don't need to worry about "losing" bets ("the world is good"). If instead, "the world is good", then it just means that a larger portion of BTC21M coins will be on less decentralized sidechains. If the world moves from good to mean, then the coin will move the network from less decentralized to more decentralized. It will never affect Bitcoin's competitiveness in the broader cryptocurrency market, and the first-layer mainchain will never "go down".
D. “Bitcoin vs. Banks”
The phrase “Bitcoin vs banks” is a common Bitcoin slogan.
But unless “Bitcoin” (in the broad sense) has a complex layered payments system — with many “layers” and large amounts of netting — it is unlikely to pose a serious challenge to the traditional banking system.
To me, "money" is payment-centric. This explains why laypeople always ask: "Bitcoin... but who accepts it?". Money is how we keep track of who owes whom. It's not a medium of exchange or a store of value, it's a method of payment.
Again, this isn’t to say that small-blockism is wrong. I am a small-blockist — Bitcoin should do everything in its power to maintain its “Swiss bank account in your pocket” qualities.
But unless Bitcoin has some way to scale to handle all of the world’s transactions, it will never reach its full potential.
First, let's ask: how many transactions are there?
How many transactions are we talking about? A.U.S.
We can see from the 2019 Federal Reserve Payments Study, Table B1, that the average “card” payment was $54 in 2018. 131.2 billion such payments were made.
We can also see from the 2018 FEDCPODCPC Survey, Figure 7, that cash payments account for about 40% of “card” (credit and debit card) payments by volume.
This means in US (131.2*1.40) = 183.68 billion payments (cards + cash) per year. Since there are 52,560 blocks per year, this equates to 3.5 million txns/block. If each txn is 250 bytes, this means a block space requirement of 875 million bytes, or 875MB.
We need to significantly exceed the "average rate" (transactions are not evenly distributed over 24 days - most are during daylight hours). However, the actual expected usage of the network (which determines bandwidth/storage/CPU requirements) is the average rate.
B.World
According to the World Payments Report (2018), Figure 1.1, non-cash txns were 482.6 billion/year in 2016; and showed an annual growth of 9.8%. (2)
At this rate, there will be 770 billion non-cash transactions per year in 2021, which equates to a TPS rate of just under 25,000 transactions per second. We can adjust this again by 40% to include cash transactions, which would bring us to 35,000 TPS.
Of course, this number will grow over time, but we can use it as a baseline for today.
How to achieve this level of Txn throughput? A. Sidechain team
Of course, using all of our second floors at once.
But here's what I'm thinking of: several large-block sidechains, added sequentially. We start with one sidechain - it might have a 10MB block size, and it's programmed to slowly go up to 1GB over 10 years.
If more capacity is needed, we can wait (10MB blocksize rises over time towards the ultimate goal of 1GB). But, more importantly, we can also add another sidechain at any time.
I call this strategy “Thunder” and each sidechain a “T-network”.
B. How it works
As I mentioned, we can add more Thunders in parallel over time.
Mainchain (Layer-1 SmallBlock Bitcoin)
|
--------|----------|------------|--------|--------|----------|---------|--------|------|--
Thunder Thunder.Asia T.Europe T.CN T.India T.Arabia T.Alt T.Africa T.USA
Time ---> 2023 2024 2028 2030 2034
For efficiency, there should be many more txns within Thunder than across Thunder. Therefore, it is obvious to imitate the banking network of the past and divide the network by geographical region. See: OCA.
How do we get from where we are now to a future with many large block chain sidechains?
It starts with the creation of a first big block sidechain. This sidechain eventually fills up. Therefore, a new second big block sidechain is needed.
Old users may not want to leave the network they're on, so generally I'd expect the second largest group to create a new network within a crowded old network (see below). So if the USA is an early adopter of Thunder, I'd expect them to stay on the "Thunder" network (the first and oldest), just like Americans have country code "+1" for their phones. Eventually, (hypothetically, in 2034, as shown above), the first network will probably become too crowded with non-Americans (even though there are many non-US networks), and Americans will want newer features, so a USA-centric network will be born late.
Note that every time a new network is created, transaction fees go down for everyone (e.g. when T. India was created, all Indian users quickly migrated there from Thunder, Thunder.Asia, and T.CN).
The question of “who has to leave and start their own network, and who stays on the old one” could turn into a ZZ problem. But this conflict will most likely resolve itself. First, the migrants could start over with a new blockchain, getting all the latest technological improvements (like switching from 4G to 5G). Second, there is a non-ZZ standard — the members of the old network least able to tolerate high fees will be the ones with an incentive to move on (and then they will take their trading partners with them). Thus, the process will likely be self-regulating.
C. Realism
This plan reflects the actual structure of today's monetary system. This is probably a good sign.
Thunder Thunder.Asia
\ /
\ /
\ /
Mainchain (Layer-1 Bitcoin), Smallblock
/ \
/ \
/ \
T.Europe T.CN
US Federal Reserve Bank of Japan
\ /
\ /
\ /
Bank of International Settlements
/ \
/ \
/ \
European Central Bank People's Bank of CN
“Looking at the map, it’s clear that the largest economies are the least open by this definition. But that’s natural: because they’re so big, most of their trade is internal.”
from here.
Above: A blackboard sketch of a banking network in the 1800s. Different local banks settled with each other at a central clearinghouse. From this video.
Above: Warcraft III server list (US East, US West, Europe, Asia). You can play on servers that match your location to reduce latency, increase the likelihood that players speak your language, play in your time zone, etc. Start here.
See also: Paying just wants to be free
Other interesting features of Thunder A. Automatic capacity management
When T.network txn fees grow too high, anyone can fix the problem by creating a new T.network. But if the sidechain is not truly needed, it will be unpopular and fail.
B. A permanent solution
The advantage of this approach is that it solves the scaling (or at least "capacity") issue once and for all.
In contrast (for example), BCH has to increase its block size through regular hard forks. This leads to many big problems. One problem is the risk of splits (such as what happened with BSV) or the risk of ZZ strategies (such as what happened with BitcoinABC's "IFP").
At the opposite extreme, MonochainBTC, which never hard forks, must hope that its current technical configuration will work forever, now and in the future. Alternatively, it must hope that it can always successfully centrally plan its way to victory (including the current central planners being able to select competent successors). Both of these hopes are unfounded (the world is too complex, and changes too fast and too chaotic).
C. Technical Debt/Overall Design Freedom
The new T. Networks does not have to be a soft fork of the existing T. Network. If desired, the new code fork can start completely from scratch.
For example, if we had Thunder in 2014, SegWit would probably have been coded as a "hard fork". This "incompatible" version of SegWit could never have been merged into Layer1 Bitcoin Core, but it could have easily been merged into whatever-Thunder-network-coming-line-in-2016 was. This would have been a big improvement in many ways: code review, code complexity, transparency to end users, potential for bugs, engineering time/effort required, etc.
D. Future-proofing/Hard Fork Desire/Competitive Development/Hardware
Since each new sidechain is a completely new piece of software, there is complete design freedom.
Someone who cares about scalability (like Roger Ver or the “Bitcoin Foundation”) could sponsor a competition to encourage new blockchain designs focused on scalability. The winner would be whoever produces the best performing software. We could even have “T. India. Roger Ver” and “T. India. Blockstream” — competing software. (In fact, they’re both already competing with each other.)
This could even be seen as a competitive response to altcoins that are committed to a strategy of regular upgrades via hard forks (like Monero/Zcash). Now “Bitcoin” can do the same (if “Bitcoin” means including all BTC sidechains).
Additionally, each new sidechain can be paired with its own custom hardware.
ECDSA signature verification... I can imagine people
writing hardware that did ten million per second.
-Gavin Andresen, to Greg Maxwell; Nov 2015
Above: Panel discussion - DevCore Draper University 2015, 7:54
In the past, both proponents and critics of “hardware scaling” have overlooked the most important distinction between “layer 1” and “layer 2.” To be resistant to censorship, layer 1 Bitcoin full node software must run on easily available hardware (especially hardware that is easily available for non-Bitcoin purposes). But this is not layer 2 software — layer 2 software can be part of a custom hardware-software pair (and therefore, it can be much more efficient).
See also:
Peter Rizun demonstrated hardware scaling. Andrew Stone demonstrated software processing of 256 MB blocks.
See Appendix 2 for some of my thoughts on what the next T.network might consist of.
Finally: One last very interesting benefit.
Security through geographic distribution
How well can the nations of the world coordinate? If two countries hate each other, then each country's T.network can be safely hidden within the jurisdiction of the rival country.
A. Introduction
To make the scheme effective it would be
important...to provide that banks in one
country be free to establish branches in
any of the others.
-F.A. Hayek, "Choice in Currency" (1976)
It's hard to imagine the Internet getting
segmented airtight. It would have to be a
country deliberately and totally cutting
itself off from the rest of the world.
Any node with access to both sides would
automatically flow the blockchain over...
It would only take one node to do it.
-Satoshi Nakamoto, "Re: Anonymity" (2010)
Above: here and here.
B. Robin ZZ Asylum
The network will be geographically distributed for greater efficiency.
This distribution may lead to an incredible and most unexpected benefit: T. Networks' circular ZZ "shelter".
Of course, large blockchain networks are more expensive to run. But fees are not the main disadvantage of large-scale blockchainism. Instead, the concern of large-scale blockchainism is that large nodes have to send/receive/process a lot of data, so it is more difficult to hide the physical location of the node. This in turn makes the node vulnerable to harassment and subordination to the local government.
For example:
Above: Commentary from the Samory Telegram group “This is Bitcoin.” Bitcoin is anti-Baojun, pro-“resistance and dissidents.”
Now, consider what it would look like in a Thunder-powered Bitcoin world when jurisdictions and service areas do not overlap.
The “people in Nigeria who are fighting A Sir Bao” would use the “T.Africa” network — after all, they live in Africa. The Nigerian government is powerful — perhaps powerful enough to go after everyone running a full node in Nigeria. But what about a node in Cameroon? Or a node in Egypt? Or a node in Morocco? A Nigerian citizen could spin up a node somewhere else and then scramble into it.
Moroccan law enforcement probably doesn't care why some crazy Nigerian dictator wants to stop some T.Africa payments. Will Egyptian sirs shut down their own payment network to help a foreign Nigerian sir? I doubt it.
Politicians are obsessed with their own country's political problems, but they pay little attention to those of their neighbors.
C. “At your service!”
But it gets better! Can't you imagine activists in the US and Europe running T.CN and T.Asia nodes? Not only can they run nodes, they can also run servers that quickly create more nodes. Maybe these people are recent refugees from Russia/CN; maybe they are just ZZ activists.
Plus there are always foreign companies. Amazon Web Services can always (indirectly) sell T.CN full nodes to CN people. They just need a ladder 😉 and some coins!
And, there are always foreign governments. If there was only one Bitcoin network, then all the authoritarian world governments might naturally unite against it; so they could more easily cooperate to destroy it. However, if there were many different networks that affected each country differently, some countries would become natural enemies of each other. The US government might run the T.Asia node purely to cause trouble for Vladimir Putin. Perhaps the Iranian government (always a victim of financial sanctions) would run all the nodes out of spite; or the London/New York Mayor's office (the financial capitals of the world) would run all the nodes as a public service.
Above: Game Civilization IV; your government can adopt "Liberate" citizens to make life difficult for the opponent's government. If many opponents adopt "Liberate", then you are essentially forced to adopt it as well. Start here.
D.IN Overview
My point is this: the main disadvantage of a large block node is that it is computationally expensive and therefore more susceptible to local government censorship. An unexpected benefit of having a large block node fleet is that local governments are actually fighting against the citizens in each jurisdiction who use the nodes.
(This is especially true of Drivechain’s blind merged mining. In a BMM, node operators “mine” and earn profits by offsetting the operating costs of the node. In general, these equilibrium profits will fall to zero (even with only two competitors, each attempting a BMM). However, if nodes are subjected to existential harassment, then the environment is no longer perfectly competitive. Some node operators will succumb to existential harassment, but others will easily ignore the harassment (giving them a comparative advantage and a profit opportunity).)
Add up/Conclusion A. How many T. Networks are needed?
In Appendix 2 below, I estimate that a representative T.networktxn can be shrunk to 197 bytes.
If all txns are 197 bytes, then 500MB worth of block space can accommodate 2,538,000 txns. At 1 block every 10 minutes, this would be 4,230 transactions per second. Above, we calculated a total global TPS of 35,000 in 2021. In other words, with just nine Thunder sidechains, Bitcoin could process every transaction in the world, non-custodial.
B. How much is the fee per T.NETWORK?
In Appendix 1 below, I estimate the upfront cost of a 1 GB Thunder node to be $6825.50 and the monthly cost to be $386.98.
Is this cost prohibitive or negligible? That is best decided by you, the reader.
That's roughly what Americans spend on a car - a few thousand pounds down payment and then a few hundred pounds a month.
Of course, it is small compared to running an exchange, a mining operation, hiring a software developer, or buying 2BTC (which is 1 millionth of the total supply). It is small compared to the USD status quo, because currently there is no way for us to "run a full USD node" (so, there, the cost is infinite). On the other hand, for a hobbyist, it is very high.
C. Why not consider total cost?
The total cost for the nine telecom networks is $61,429 upfront and $3,482 per month.
But each user only needs to verify their own payments (especially payments they received money from). Similar to the Lightning Network, users can safely ignore txns that don’t apply to them.
Users can stick to getting paid on their own network. That way, they only need to verify one T.network.
Appendix 1: USD cost for a 1 GB Blocksize node
Let's look at the requirements.
Note: I checked these prices in mid-2020, and of course they are likely to change over time. But regardless, I have included the hyperlinks I used in mid-2020. Hopefully they will remain accurate over time.
A. Storage
I mentioned earlier that sidechains can (unlike the mainchain) discard old history. Through clever UTXO commitments, it may be possible to discard block history older than 6 months.
Since there are 26,280 blocks every 6 months, a block size of 1 GB would produce a total storage requirement of 26.28 TB for block data, plus more for storing UTXO data and other databases.
$3,000 for a hard drive
B. Bandwidth
1 GB every ten minutes is 8000 bits/600 seconds, or 13.33 Mbps. Our requirements will be higher - we have to consider the inter-block time and precious upstream bandwidth.
Verizon Fios 1 Gbps service costs $215/month
C. Calculation
A typical 1MB block will contain about 2500 txns. So we can expect a 1GB block to contain 2.5 million txns.
Jameson Lopp tested node performance and found that one machine could sync Bitcoin Core from the genesis chain (January 3, 2009 - October 23, 2018) in 311 minutes. Most interestingly (for our purposes), this machine was clearly CPU-bound.
Blockchain.info reported a total of 350,934,692 txns during this period (January 3, 2009 to October 23, 2018).
Therefore: 350,934,692 txns / 311 minutes = 11,284,073.7 txns per 10 minutes. Again, block times vary widely, so we need to be able to handle occasional "bad luck", but this machine's CPU can do 4.514 times our baseline requirement (2.5 million txns per 10 minutes).
I can build a machine with twice the RAM (Jameson's) and a 15% faster CPU for $3205.24.
D. Electricity
The computer is rated at 1200W (that's 1.2kW). If we somehow needed 100% of that power, 24/7, then for 24 hours a day, we would consume 28.8 kWh. At $0.132/kWh, that makes $3.8/day, or $114/month.
If we increase it by 20%, it should be enough to cover the CPU and the huge hard disk array.
So, $136.8/month.
E.Total
If we add a 10% "fudge factor" (for installation, labor, unexpected items, etc.), then we have:
Prepaid $6825.50
$386.98/month
The true total cost of ownership will almost certainly be lower because we overestimated everything.
Appendix 2: Possibility of downloading T.Network A. SCHNORR/BLS
Schnorr signatures can be added natively (i.e., making all outputs Taproot-Script).
Or maybe: BLS signature
B. Smaller TXNS
If the sidechain is to emphasize scalability, then we might try to make txns as small as possible.
Satoshi's txns are actually a bit wasteful:
There are four "version bytes", allowing for billions of possible txn versions. However, of those billions, we only use three. Therefore, we can reduce those four bytes to one, saving three bytes.
The nLockTime field is usually not used. However, it consumes four bytes. We can specify that its presence or absence depends on a specific "version" value. Thus, four bytes can be saved in most cases.
Most transactions take 5 or fewer inputs and pay 5 or fewer outputs. However, two bytes are used to specify the input/output information. We can predefine some version types to always describe txns that take these "plain" forms (e.g. 1 input 2 output P2PKH). Thus, we can eliminate internal VarInts and even internal scripts.
If Thunder was going to focus on on-chain txns, it wouldn't need any functionality at all. Just the bare minimum to send txns.
For example, a "minimal" txn might look like this:
1 byte: version*
36 bytes: Input UTXO: TxID (32 bytes) + Position (4 bytes)
104 bytes: spend authorization
71 bytes: signature**
33 bytes: Compressed PubKey
28 bytes: output 1 -- value (8 bytes), Hash160 (20 bytes)
28 bytes: output 2 -- value (8 bytes), Hash160 (20 bytes)
See (*) and (**), below.
...197 bytes total.
A version will specify # inputs and outputs, in this case: (1,2). For 100 of the (now) 256 version types, we can specify txns with 1-10 inputs and 1-10 outputs.
** See here and here, these are now always 71 bytes or less. [If less, fill with zeros and let the interpreter redo if that fails.]
C. Other opportunities
Currently, returning a "memo" from the OP requires having an output with a value of 0 (i.e. 8 bytes consisting of only zeros). Instead, pre-define some version type as a type that always contains a "memo" field at a specific location. This would avoid wasting those 8 bytes.
When new features are added to Bitcoin Core as a “soft fork”, they tend to involve awkward flags or indicator bytes. But when the next Thunder network is ready to be created, these features can be folded into a new txn version, thus spending zero marginal bytes (and involving no awkwardness).
D. Accumulator/Fraud Proof
Not only can we save bytes, we can also improve the security of SPV. One important way is to eliminate Class 4 block defects through accumulators, as I describe here. This will allow Bitcoin to support fraud proofs. SPV nodes can be cheaply, reliably, and immediately warned if any block is invalid in any way. As a result, SPV nodes will have the same security as full nodes (3). This is ideal because (of course) on large block systems, most users will be running SPV nodes.
E. Simple plasticity repair
Bitcoin Core’s “SegWit” approach to fixing transaction malleability is (unfortunately) very weird and complicated. In contrast, a “hard fork” approach of just editing the transaction serialization function would be much cleaner.
F. Others
From the hard fork wishlist:
Byte order consistency (big endian)
Eliminate redundancy in variable-length integer encoding, possibly switching to a standard.
footnote
In fact, since Lightning requires Layer 1 bytes to onboard each new user, and requires periodic Layer 1 bytes for maintenance, it is only a “layer 2” in the sense of scalability. (The main advantage of the LN is not scalability at all, but instant trustless payments, which can be made without the mining process or the rest of the Bitcoin network.) ↩
That seems like a plausible number. There were 7.42 billion people in 2016, and only about 65% were adults. ~2B still live in extreme poverty, and many live in developing countries without bank accounts. ↩
This is not to say that the entire network can now only rely on SPV nodes (a mistake often articulated by LargeBlockers, and especially BSV-ers). There is no way around the data availability problem: someone has to “host” the blockchain’s data… we can’t all get it from someone else! (This is also why SNARKS are inferior as a scaling solution — they’re basically just opaque fraud proofs.)