Previous: Using Bitcoin
Welcome to the technical stage of our journey through the fascinating world of Bitcoin, where trust is no longer dependent on intermediaries like banks or corporations. In this eye-opening adventure, we will unravel the inner workings of the Bitcoin network and discover how it sends, receives, and secures our precious bitcoins through our wallets. On our journey, we will see the cryptography technologies of SHA-256 hashes and ECDSA key pairs that underpin Bitcoin in action. Then, from mining and the blockchain to nodes, mempools, and UTXOs, we will unlock the secrets of the most secure public network on the planet. We will also discover the Lightning network and explore how Bitcoin can scale to handle billions of users. And if that’s not enough, we’ll uncover the thrilling history of Bitcoin forks to discover why, sometimes, small and slow is best.
So, get ready to embark on a journey of discovery, and let’s explore the revolutionary world of Bitcoin together! We will begin by looking at the structure of the network.
The distributed peer-to-peer network
The first thing to know about Bitcoin is that it runs on a distributed peer-to-peer network. The peers on this network are called nodes. There are several types of nodes, but I will return to that. It is also crucial that the Bitcoin code that runs the nodes is open source. Open source means anybody can use, modify, copy, or run a node. Nobody’s permission is required to copy, compete or participate. It is straightforward for a moderately skilled programmer to recreate clones of the Bitcoin software, perhaps with a few simple modifications. However, as we will see near the end of this chapter, this has been done many times without much success because to compete with a peer-to-peer network like Bitcoin, you need the support of tens of thousands of node operators – just to get started.
The more critical thing open source allows is that expert programmers can pour over the code to verify its correctness. Bugs can be found more quickly, and potential flaws can be discussed and avoided. Proposed upgrades can be studied, approved, and tested before they are made official and used to change the network. The even more critical thing about being open source is that when people can subject the code to scrutiny, they can trust it.
One of the most remarkable things about the Bitcoin code is its reliability, although it has had minor downtime in the early days. Bitcoin hadn’t stopped running until March 2013, when newer versions of the node software accidentally caused a divergence into two versions of the blockchain by disagreeing with older versions about whether a particular block was valid. This is known as a fork. Like a fork in the road, the two blockchains, each with supporting nodes, went in separate directions creating different, disparate versions of the Bitcoin blockchain. More on forks as we proceed. However, the problem was fixed the same day.
Other bugs in the code have been discovered and fixed, often just in time. The most recent and notable bug found in 2018 was a potentially exploitable flaw but was fixed before it was publicly known. An early bug discovered in 2010 allowed billions of bitcoins to be created. The extra bitcoins were promptly erased, and the bug was fixed in about 5 hours.
The point worth emphasizing is that these bugs could only be resolved with the consent and cooperation of the node operators – after all, they are running the software with the bugs. If some or all of the node operators had wanted to continue with the fork or the extra billions of bitcoins, they could have done so. Therefore, the health, strength, and state of the Bitcoin network depend upon a majority consensus. The node operators did not want the extra billions of bitcoin and did not wish to continue with the accidental fork. This property of overwhelming consensus being required for any change to be possible is a massive part of Bitcoin’s strength—more on this idea when we discuss the block size wars.
The bugs are not inconsequential, but it is a testament to the skill first of Satoshi and later all the contributors to the Bitcoin code that Bitcoin still runs today. It is also true that Bitcoin has been lucky too. The longer Bitcoin survives and the more refined, widespread, and secure the network is, the more viable and valuable our bitcoin will be.
Although modification of the Bitcoin code is trivial for a programmer, if a Bitcoin node wishes to participate and be accepted in the Bitcoin Network, there are rules and protocols it must abide by, or the other nodes will exclude it. For example, feel free to download the Bitcoin code, modify it to play the Star-Spangled Banner, and flash the screen red, white, and blue, and you will have no problem participating in the network. However, modify the source code to change just one of the consensus rules, which verifies a transaction, and you will be discovered as a fraud and excluded from the network.
Sending a transaction
A transaction to send some bitcoin from wallet x to wallet y would be prepared on wallet x. Wallet x will then cryptographically sign the transaction with the bitcoin owner’s private key and send the transaction’s signature, along with the transaction itself and the public key, to the nearest known node on the network. We can visualize this as follows:
Send the signed transaction to the node.
Note that wallet x and wallet y might or might not be nodes themselves. In the early days of Bitcoin, all nodes were wallets and vice versa. Soon, SPV or simple payment verification wallets were released, allowing users to connect to other people’s nodes without running their own. SPV wallets are most common today and best represented in the preceding image. Exodus and Muun are SPV wallets.
Verifying and propagating transactions
Notice from the next image that a node implements multiple tasks. After receiving the transaction, it relays it to other nodes and verifies it using the Bitcoin consensus rules. Note that all the nodes that receive the relayed transaction also relay the transaction to other nodes and verify the transaction against the same consensus rules. As all nodes relay to other nodes, each transaction propagates over thousands of discerning nodes. This next image adds in the relaying/propagation and verifying steps.
Nodes relaying and verifying a transaction
The preceding image shows that the transaction is immediately discarded if any consensus rules are unmet. Also, and we will go into more depth shortly, the node uses other data along with the rules to verify the transaction. Perhaps the most significant rules are:
- Does the bitcoin being spent belong to the public key being supplied?
- Does the signature accompanying the transaction verify that the owner of the private key signed the transaction?
If yes is answered to both and many more questions, the transaction is considered valid and added to an area of the node called the mempool or memory pool –a database on the node where it will await processing. Let’s keep going.
The mempool, the UTXO database, and the blockchain
The mempool maintains a list of transactions waiting to be processed. Furthermore, each node has a list of bitcoins (and fractions of bitcoins) and which addresses they belong to in a part of the node called the UTXO database. Using the mempool, the node can verify if the wallet is trying to send two conflicting transactions at once. Using the UTXO database, it can verify the ownership of the bitcoin.
UTXO stands for unspent transaction outputs. UTXOs are simply the record of all bitcoin that somebody owns. These can be whole bitcoin or tiny fractions of a bitcoin. It is crucial to realize that the UTXO database is where the Bitcoin wallet software, like Exodus or Muun, looks for all the pieces of Bitcoin the user owns. The wallet software doesn’t typically show all the pieces of bitcoin, just the balance. Some advanced wallets like the Samourai wallet and Sparrow wallet show the individual UTXOs (pieces) to the user, but most don’t because most users don’t care. Let’s add more parts to our diagram to visualize the mempool and the UTXO database.
The Mempool and UTXO database
Furthermore, the preceding image shows a blockchain. The blockchain is a history of every transaction made on the Bitcoin network, back to Satoshi’s first transaction in January 2009. Remembering that this setup is replicated tens of thousands of times across the peer-to-peer network is vital.
Things will soon get a little deeper, so let’s recap before we move on.
A quick recap so far
The node receives a transaction from a wallet and checks that the transaction is genuine by using the public key to verify that both the owner of the bitcoin and the signer of the transaction who is sending the bitcoin are the same. The node can be confident that the transaction is genuine by checking the signature with the public key and, therefore, must have been signed by the private key. The ownership verification is done by checking the bitcoin ownership list in the UTXO database. It is worth noting that when a node first joins the network or comes back online after some downtime, it doesn’t just verify new transactions. It verifies every transaction using the blockchain, a record of every transaction divided into blocks – more soon.
As mentioned previously, the code that runs the nodes on the network is open-source and freely available. Anyone can run a node, and there are tens of thousands of nodes at the time of writing. Individual nodes pass the transaction to the whole network, verifying the transaction as legitimate. If the transaction is illegitimate, it is discarded; if it is legitimate, it is placed in an area of memory on the node called the mempool. A node uses data from the UTXO database and the blockchain to make these decisions. As more and more transactions are made, they are either discarded (if illegitimate) or put into the mempool (if legitimate). We will get to what happens to all the legitimate transactions in the mempool soon. But, first, there is a potential problem.
Double spending: The problem with distributed peer-to-peer currency networks
The big problem that arises is the problem of double spending. We saw in Chapter 3 when looking at pre-bitcoin technologies, that previously, the only way to 100% verify every transaction was to centralize the process. Unfortunately, centralization defeats the entire purpose of Bitcoin, so let’s explore the double spending problem to understand it and see how Satoshi solved it.
Picture your bank account with a $10 balance. To keep things simple, assume you can never go overdrawn. If you have two cheques and give them to two different people, and both cheques were written to pay $10 to the recipient, both cheques would be checked by a central entity before crediting the payee. When it credits that lucky first payee, it will debit your account down to zero.
Therefore, one of the cheque recipients will be disappointed and not receive their $10 because the bank will honor the first one it receives and reject the second one because you have no money. But in the bank situation, the problem of overspending/double spending is solved by having a centralized authority that oversees everything. We don’t want that.
With Bitcoin, you could send two transactions of your entire wallet balance, paying two different recipients, to two different nodes. The transaction would be valid with each node, but you don’t have enough bitcoin to pay both. This problem is known as double-spending. Each node implicitly checks for a double spend because, after the first spend, the UTXO is removed from the UTXO database and placed in the mempool. It wouldn’t find the UTXO for the second transaction, and it would reject it, but each node does not check all the other nodes. With tens of thousands of nodes, it would take too long. Therefore, one transaction could be sent to one node and another to a geographically disparate node, and both transactions could end up in a mempool somewhere on the network.
As we have seen, your bank account solves the problem by subtracting the balance and then refusing to honor payments when your balance gets to zero. However, this is only possible because a centralized authority handles every transaction. So how can we avoid the double spending problem while allowing transactions in a fully decentralized, trustless system without the impossible task of checking every mempool against every other mempool looking for double spending?
Like with the bank, the problem is solved by only accepting the first use of the bitcoin balance, represented by a unique UTXO in the UTXO database. But who gets to decide which recipient of a doubly (or more) spent UTXO will be accepted? It’s a race, and whichever transaction wins the race gets processed – added to the blockchain. Let’s explore mining.
The transaction that is mined and added to the blockchain first is the genuine one, and the mining process guarantees that a UTXO (the bitcoin) can only be spent once. This means that, like with two cheques presented to a bank, one of the recipients will be disappointed. Here is what happens.
Approximately every ten minutes, special purpose nodes on the network known as miners select transactions from the mempool and put them together ready for mining. Miners will almost certainly run a regular node and a mining node, so they will be sure that all the transactions they choose to mine are legitimate and do not contain a double spend. Note that a different miner elsewhere on the planet referring to another node might have a transaction attempting to double-spend the same UTXO. As we will see, however, only one of the miners, and therefore, one of the transactions can be successful.
Satoshi chose the word mining because it is analogous to mining for precious metal, perhaps gold. When you mine for gold, you might have to take many swipes of the pickaxe before you find any gold, and it is possible to mine for some time without finding any gold. However, if you do find some gold, it is proof that you have been mining consistently. It is proof of your work.
However, if gold is abundant around the planet for anyone to pick up as they please, it would not be precious because they wouldn’t pay for it if they could pick it up in the garden or the street. So, with this in mind, let’s get back to Bitcoin mining, specifically.
The list of thoroughly checked and rechecked transactions and some additional data is called a block. Note that miners are spread worldwide and connect to different nodes. As a result, some miners will have different versions of the doubly spent transaction. The following image updates our picture of the Bitcoin transaction process by illustrating that miners get a list of transactions from the mempool and begin the race to create a new block from those transactions.
Miners mine a block of transactions.
Next, we will see precisely what is involved with mining a block, and then we will see what happens to the block of mined transactions.
Mining a block
Mining is the process of accepting transactions to be placed in a block on the blockchain. Soon we will see how the miner might strike gold metaphorically and why they are so keen to participate in the process.
As we have said, when transactions are added to the mempool by the Bitcoin nodes, they are only checked against the blockchain and the UTXO database for validity. They are not rechecked for every transaction against all the nodes’ mempools. It would take too long, and even if they did, how would they choose which were valid when a double spend was detected? They couldn’t know.
The solution is that if only one transaction out of the double-spent UTXO is processed, then all will be well. It will be like the bank accepting the first and rejecting the second cheque. The mining details we will go into next, but to finish the double spending explanation, all you need to know is that mining is a race to solve a mathematical problem. The race is won by the transaction selected by the miner with the most computing power and a bit of luck. Once a miner chooses a transaction and wins the race to create a new block, other attempts to spend the same UTXO (bitcoin) will fail.
So, if you want to be sure that the bitcoin someone sent you is yours and you aren’t being scammed with an attempted double spend, wait until the block has been mined and the transaction validated. Your wallet will tell you when this has occurred. It will be about ten minutes –the approximate time it takes to mine a block and add your transaction to the blockchain.
When a new block is successfully mined, it is first validated by every node in case the miner is trying to cheat. Then all the transactions included in the block are removed from the mempool, and then, and this is the good bit, the UTXO database is updated with all the new owners. Remember, the UTXO database is where all the wallets look to see what their user owns. Therefore, at this point, the new bitcoin owner sees the bitcoin as a confirmed transaction in their wallet.
As you might remember from Chapter 4, when we sent and received some bitcoin between our wallets, the bitcoin showed up almost instantly but was labeled as unconfirmed. This is because the wallet software reads the mempool to see incoming transactions and the UTXO database to see confirmed transactions. So if it’s in the mempool, it is probably on its way, but if the UTXO is also attached to a different transaction in a different mempool and that other mempool is mined first and added to a block, the first transaction will be invalid because it will no longer refer to a valid UTXO in the UTXO database.
You can view the contents of the mempool here: https://mempool.space/. Click on the green block at the top of the screen to see the visual representation of all the transactions in the mempool waiting to be mined. Remember, this image only represents the mempool on one node. Other nodes might have different mempool contents, including attempted double-spends.
Bitcoin mempool visualized
Each square represents a unique transaction in the node’s mempool. The larger the square the more bitcoins being sent. I hovered over the largest transaction, and it was for 15.75 bitcoins. On the left, you can see data about the fees, and above the mempool visualization, you can see previously mined blocks to the right of the current green mempool. You can also click on these blocks to view their transactions and fee data. Notice that the blocks are numbered. At the time of writing, block number 767063 had just been mined. You can view every block, including all the transactions, right back to block zero mined by Satoshi in 2009.
You can view the contents of the entire blockchain more easily here: https://www.blockchain.com/explorer?currency=BTC. Then, scroll down the page a little, find the VIEW ALL BLOCKS button, and click it to view a list of every block.
View all blocks
Click on any block number in the Height column to view its contents. The term block height is used because the blocks are visualized as stacked on top of each other. If you explore one of the blocks by clicking on the block number, you will see data about the block itself, followed by every transaction in that block. This data will take dozens of pages. This next image shows just some of the data about the block.
The data in a block
We can see in the preceding image that it was mined by a collaborative pool of Bitcoin miners collectively known as AntPool. There was a 6.25 bitcoin block reward worth over $106,000. It contained 2871 transactions accounting for more than 7,858 transacted bitcoins. We can also see the hash/fingerprint of the block and more data if we scroll down. The block hash, the block reward, and much more will be explained in the following sections as we dive deeper into mining.
You can view a graphical representation of the UTXO database here: https://utxo-stats.com/. The UTXO Stats website is not especially useful but is a great visualization. If you hover over each tiny orange dot, it represents all the UTXOs from a given block. Finally, you can click to go to the blockchain.com website (that we viewed previously) to explore more deeply.
We need to explore the mining race in more detail because all we have discussed so far likely raises more questions than it answers. First, let’s update our mental picture of what we learned with an image. I have added that wallet x is also viewing the UTXO database to see the UTXOs representing the bitcoin it owns and connected both wallets to the mempool, which they constantly scan to watch for incoming transactions waiting to be confirmed. To be extra precise, the nature of the diagram means the connections from wallet x and wallet y may pass close by to each other, but they are never directly connected. Bitcoin is peer-to-peer, but this refers to the nodes, not a direct connection between each wallet. Furthermore, it is most likely that wallet x and y will each be connected to a different physical node, albeit with an identical copy of the blockchain and UTXO database, and sometimes but not always, a different variation of the mempool.
Miners compete to choose the next block.
In the preceding image, the nodes don’t blindly accept the block. Instead, they recheck every transaction, then, if satisfied, delete confirmed transactions from the mempool and update the new bitcoin owners in the UTXO database. This allows all the wallets to give the good news to the users, in our example, wallet y.
Let’s answer some more commonly asked questions about mining, and then we will get into more detail about mining.
Why miners participate
Of course, the motivation is financial. The block reward or the Coinbase reward is the bitcoin that a miner receives if it wins the mining race for a block. It is worth mentioning that the Coinbase reward has nothing to do with the Coinbase centralized exchange. In the preceding discussion, we saw that the AntPool group of miners received 6.25 bitcoin to share among their members.
Let’s go into still more detail about mining.
Mining in more detail
We have seen a Bitcoin transaction between two wallets but the whole mining process we have skipped over. We know it’s a race between miners and that miners receive some bitcoin for their trouble when they win. But apart from adjudicating on double spending, what’s the point? First, it will help to visualize a block of transactions. Look at the following block contents, and then we can discuss it.
- Block number(height) 767225
- Timestamp 12th December 2022 12:09:56
- Nonce 4534534 (tip: this is important)
- The block hash/fingerprint (tip for readers! – this is important)
- The previous block hash/fingerprint
Block body (transactions)
- Transaction 1: Wallet x pays wallet y 1 bitcoin
- Transaction 2: Bob’s wallet pays Jim’s wallet 3 bitcoin
- More transactions go here, probably thousands more
The block header content is more complex than listed above. As we have seen, transactions in the block body would contain real bitcoin addresses, signatures, and amounts, formatted much more realistically than “Bob’s wallet pays Jim’s wallet 3 bitcoin.” Still, this simple representation will serve our future learning for now.
Observe the area of data at the top of the block. This is known as the header. It contains information such as the block number, a time stamp, and numerical data called a nonce. Underneath the header are the transactions selected from the mempool by the miner. Perhaps the single most interesting piece of data is the nonce – this means “number once.”
In the UK, the word nonce has another and rather unfortunate meaning. I leave it up to the reader if they wish to explore the following link to the Urban Dictionary.
This link should not be followed at work or with young children looking over your shoulder. https://www.urbandictionary.com/define.php?term=Nonce
To successfully mine a block, all the miners across the Bitcoin network compete to be the first to find a hash/fingerprint for the block – including all the transactions and the header, like we did for Jane Austin’s Pride and Prejudice. But we got that hash instantly. So this seems like it will be a short race. Let’s continue, and things will become more apparent.
Also, note that the header includes the hash from the previous block so that the current block is permanently connected to that previous block, which in turn, is connected to the block before that, and so on all the way back to block zero; Hence, blockchain. This connection will be explored further soon – back to the current block’s hash. You might be asking yourself; I thought hashing was quick. This is true, but miners must keep hashing until they get a numerical hash within a specified range before any other miners.
We know from Chapter 3 that hashing some data only takes a tiny amount of time and computing power. We also learned that hashing is deterministic and that if you rehash identical data, you always get the same result. However, the slightest change to the data would produce a wildly different output because of the avalanche effect. This is where the nonce comes in (“number once,” not the English thing).
Therefore, the miner must continuously hash the block of transactions, including the header, while constantly varying the nonce until they get a hash result within the target range. The target range is a number lower than a protocol-defined value. The value chosen is deliberately chosen to be very unlikely and therefore likely require many hashes, trillions!
The miner can keep trying to get new hash values while keeping the block of data the same by varying the value of the nonce. This works because of the SHA-256 property that guarantees a significant change in the hash even with a tiny change in the data being hashed (Remember the period in Pride and Prejudice).
We can now solidify this mining concept with a mining simulation app.
Demonstrating mining a block
Visit the following website, and we will play at being a miner with a simplified block but using the same concepts using a varying nonce to find a hash below a set target. This simulation requires finding a hash with a number with four leading zeroes. Visit https://andersbrownworth.com/blockchain/block.
On the Website, you will see a simplified representation of a block waiting to be mined. Notice there is a Block: field representing a block number, a Nonce: field, and an empty Data: field when you first visit the page. However, I have filled in some oversimplified text to represent some transactions. Finally, there is a Hash: field and a Mine button to commence mining. Notice that because I altered the block’s content when I added the transactions, the overall color is red because the hash does not fall below the target of four leading zeroes.
A simplified block waiting to be mined
Try entering different numbers in the Nonce: field and notice you get a completely new hash, although most likely, it will not come in under the target doing this manually. Press the Mine button, and the application will continually increment (add 1) to the value in the Nonce: field until the hash comes in under the target value. This could take a second or many seconds. Mine took about 10 seconds. This next image shows that my simplified block with simplified transactions has been mined.
A simplified block has been mined.
The preceding image shows the four leading zeroes on the hash, confirming that the target was met. Note that if you try to change any detail from any block field, it will instantly recalculate the hash and invalidate the entire block.
As mentioned, once a miner finds a valid hash, the block is submitted to the network of nodes, where each node checks every transaction and the properties of the block itself. Then, the nodes re-check the transactions to ensure the miners haven’t added an invalid transaction. Also, depending upon which miner wins the race, some transactions might be included in the block that was not in all the versions of the mempool. It’s OK if a node doesn’t have the transaction in the mempool. Likely, the transaction didn’t reach that node in time, but the UTXO must be in the UTXO database, and the signature from the transaction must be verifiable by the public key. A node can reject a block if it suspects foul play. If enough nodes reject a block, it must be re-mined – most likely with different contents.
Some of the checks are as follows:
- The hash from the previous block is present in the current block
- The hash of the block can be traced back to block zero. I.e., the miner has not tried to enter an invalid hash from a previous block to change the history of transactions.
- The public key verifies the signature on every transaction
- The miner collected the correct Coinbase reward
- If the UTXO being spent originated as a Coinbase reward, it must be 100 blocks old before it can be spent – I.e., miners can’t spend their rewards until 100 further valid blocks have cemented their participation. So a miner can’t somehow commit a fraudulent block, buy a Lamborghini, and then be discovered as fraudulent.
- The block is within the required size limit
- The bitcoin script that describes the transaction must conform to several rules concerning size and format. Script is the technical term for formatting instructions and data representing a transaction.
Notice the first check in my abbreviated list of checks each node will make. The hash from the previous block is present in the current block. This means that once a block has been mined and another block has been placed, you would need to mine two blocks if you wanted to fake or change a transaction. Also, note that the second rule states that the block hashes must link back to the Genesis block (block zero mined by Satoshi). The hash for the genesis block is 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, and you can verify this if you want to on the block explorer website here: https://www.blockchain.com/explorer/blocks/btc/0.
This next image shows the genesis block on https://blockchain.com. In the image, I have highlighted the truncated hash. If you visit the website, you can click the hash to view it fully.
The bitcoin genesis block
Also, note that in the simulation we just did, the hash from the previous block is not part of the calculation. Next, we will explore mining further to clarify how each new block enhances the security and immutability of the preceding block by including the hash from the previous block and creating the blockchain.
Demonstrating the blockchain
At this point in the explanation, the transactions have been collected and verified, added to a block, secured by proof of work, and finally added to the blockchain for eternity.
Let’s look at how the Bitcoin blockchain stores and, just as importantly, verifies the integrity of the blocks themselves, as opposed to the individual transactions in a block, on the blockchain. Of course, we already know this is done using the block hashes, so let’s see this in action.
Visit https://andersbrownworth.com/blockchain/blockchain, and we will explore the blockchain functionality. Notice that we are now shown multiple simplified blocks, and each block also has a Prev: (previous) field, which contains the previous hash. For example, I have entered pretend transactions into the first three blocks in the following image. Notice that all the blocks are colored red, indicating that none are valid/mined.
Three unmined blocks
Let’s run a test. First, press the Mine button on block 1, then the Mine button on block 2. Observe in the following image that not only has the target hash value been reached in each block, but also the hash value from block 1 is contained in the Prev: field of block 2.
Hash from block 1 contained in block 2
Now mine the third block. Again, notice that the hash from block 2 is contained in the Prev: field of block 3. Directly change any detail, no matter how small, in block 1. For example, I changed the amount Paul sent to Mary from 1 bitcoin to 2. In the following image, all three blocks are invalid again.
All three blocks are invalid.
This shows that it is tough to change once a block is added to the blockchain. It is nearly impossible to change it unless you take over most of the network. When this happens, it is called a 51% attack because the person changing a transaction must control and maintain at least 51% of the network.
What is vital to be aware of is that all the full nodes hold the blockchain. So if something happens to one or even hundreds of the nodes, then there are tens of thousands more constantly verifying and storing the immutable blockchain.
The network checks mining difficulty every 2016 blocks, which equals approximately two weeks at ten minutes per block. If more time than an average of ten minutes is taken, then the difficulty is reduced. If less than ten minutes on average, then the difficulty is increased. To be clear, making the mining harder requires more, and making it easier requires fewer leading zeroes in the hash. Using this system, the network and the mining process adjust to account for the miners’ amount of hashing power. If miners join the network or upgrade to more powerful mining computers, the difficulty will eventually increase; if the opposite happens, the difficulty will reduce.
The Bitcoin Halving
Another related concept to difficulty is the so-called Bitcoin Halving event. I mentioned previously in the section Fiat vs Bitcoin: Introduction to TradingView and Bitcoin volatility, the Bitcoin halving is a pre-programmed event enacted by all the nodes in the Bitcoin network that reduces the reward miners receive for each block they mine. This reduction happens approximately every four years or, precisely, after the network has processed 210,000 blocks.
When the Bitcoin network was created, the reward for mining a new block was 50 BTC. In 2012, the first halving event occurred, reducing the mining reward to 25 BTC. In 2016, the second halving event took place, reducing the reward to 12.5 BTC, and the most recent halving event happened in May 2020, bringing the reward down to 6.25 BTC. In 2024, the reward will be reduced to 3.125 BTC per block.
The purpose of halving is to control the supply of bitcoin and prevent too much inflation. However, as the mining reward decreases, creating new bitcoins becomes more computationally demanding and expensive, ultimately limiting the total number of circulating bitcoins to 21 million.
Bitcoin halving events have historically been associated with increases in the price of bitcoin, as the reduction in the mining reward reduces the selling pressure on the market, leading to a potential increase in demand and price. However, this is not a guarantee and is subject to many other factors that can affect the price of bitcoin.
At the start of Bitcoin in 2009, a single computer could easily mine a block in ten minutes. Satoshi’s laptop was, at first, the only miner. This is obviously very insecure, but it didn’t matter because bitcoin was worthless (at least financially), and nobody was trying to hack the network. As the network grew, miners got more powerful. Now mining farms are enormous warehouses full of thousands of ASICs (Application Specific Integrated Circuits) or mining pools that individual miners connect to and share the block reward and fees. This image shows just one of many globally distributed mining farms.
A modern mining farm
You must match this setup or take over half of it to corrupt the Bitcoin network! Not a simple task. You would then need to pick a transaction to corrupt or add one that benefits you and win the mining race. Now let’s think about this a little more deeply. Remember that after winning the mining race, tens of thousands of nodes will scrutinize the block, including checking that the public key can verify all the transaction signatures. This means that you would need to own the private key to any transactions you want to mess with. Hmm.
Therefore, the most harmful thing you could do is stop a payment you have made. Of course, it could be a valuable payment for a home, car, or container ship of gold. But the resulting blockchain will show that the payment has not been made, and you will have transparently stolen something! Admittedly, your average police department would struggle to comprehend the crime. However, you might as well commit a robbery (not financial or legal advice); there would be potentially less evidence! And consider, if you have that much mining power, why not put it to legitimate use and earn a Coinbase reward from time to time?
Satoshi seems to have covered everything. Could Bitcoin be the secure, decentralized money to solve the problems discussed in Chapter 2 and usurp the greedy, controlling, ideological institutions we discuss in the afterword? Let’s keep exploring for a little longer. While on security, let’s keep digging and discuss a little deeper into the topic.
The astute reader will see another possible way to break the Bitcoin network. What if the mathematics of the cryptography itself was hacked or somehow flawed? Suppose something was imperfect inside those black box functions we discussed in Chapter 3. In fact, there are already more secure cryptographic functions than SHA-256. For example, SHA-512 is used by the Ethereum network and is twice as safe as SHA-256. Assuming consensus among node operators, Bitcoin could easily upgrade to SHA-512. It hasn’t to date because the trade-off between security and speed is considered right. But one day, if the consensus changed, Bitcoin could be made more secure very quickly. SHA-512, like SHA-256, is a black box, a function, and programmatically simple to swap between.
One potential doomsday scenario for Bitcoin is a cryptographic attack with a quantum computer. Quantum computing is a type of computing that uses the principles of quantum mechanics to perform calculations. Unlike regular computers, which use binary bits to represent information as either 0 or 1, quantum computers use quantum bits or qubits, which can represent both 0 and 1 simultaneously. This superposition property allows quantum computers to perform specific calculations faster than today’s computers. By faster, I mean orders of magnitude more quickly. Additionally, quantum computers can leverage the property of entanglement, where the state of one qubit is dependent on the state of another, to solve particular problems, including cryptographic calculations, in a simultaneous/parallel manner.
The state of quantum computing is still in its early stages of development. Still, researchers have built quantum computers with just a few qubits that can perform simple calculations, and some have demonstrated basic error correction. Unfortunately, it is centralized, disreputable tech companies like Google that are investing most heavily in quantum technology.
Simplified, this means that quantum computers are currently viable and, in the future, a potential threat, but complex software for quantum computers is not ready – but it is coming.
Furthermore, if Bitcoin is vulnerable to quantum technology, the entire banking system, transport and power infrastructure, and the Internet will be just as vulnerable. Suppose a malicious organization got a quantum computer capable of attacking Bitcoin. In that case, it is unlikely that the Bitcoin network would be the first target – assuming the enemy actors discussed in the afterword don’t get the tech first and use it against their competitor – Bitcoin.
However, a considerable amount of research has already gone into quantum resistance. Much of this research has been conducted by another crypto company, the Algorand Foundation, creators of the Algorand network. We will talk about Algorand later in the book. So, the bases are covered, although only time will tell for sure.
We have discussed UTXOs, and how they are virtually synonymous with the actual bitcoin we see in our wallets. When you open your bitcoin wallet and see an amount of bitcoin, it gives the impression of being a value like in a bank account. We have discussed that this isn’t really what is happening. Bitcoin has no concept of accounts. Bitcoin indeed uses addresses, roughly synonymous with account numbers. However, the Bitcoin wallet software reads the UTXO database on a node, collects all the UTXOs (fragments of bitcoin), and shows us a total. Although UTXOs are often fragments of a bitcoin, they can also be multiple bitcoins. The best analogy to understand this phenomenon is to think of your Bitcoin wallet as a purse with notes and coins of all sizes but an LCD screen on the outside, which always shows you the exact total of all the coins and notes.
In short, your private key and all the addresses derived from it control access to bitcoin fragments and perhaps whole bitcoins, maybe even multiple bitcoins. Your wallet shows you the total and allows you to spend it without concern for the UTXO-based complexities. You can explore more advanced wallets like Samourai and Sparrow to see the individual UTXOs and choose which ones to spend or categorize UTXOs with labels. Most Bitcoin users don’t care about such details, so most wallet software hides the details.
As we have learned, the number of transactions per second is limited for security and smooth operation. Transaction fees are calculated in satoshis per byte. Satoshis is usually shortened to just sats. You can pay a higher fee to guarantee your transaction will go into the next block. If, however, you are sending some bitcoin to your savings wallet, you may not be bothered if it takes a few extra blocks to be confirmed.
The bytes used depend upon the complexity of the transaction. The number of bytes of data required for a transaction will also depend upon the fragmentation of the UTXOs representing the bitcoin in your wallet. Think about walking into a shop to buy something for $50 and handing over a $50 note. Compare this to walking into the same shop to pay for the same item with a big heavy bag of quarters. The retailer might even refuse to serve you. With Bitcoin, your transaction will cost more if you use many bitcoin fragments (UTXOs) rather than one bitcoin or one chunk of the correct size or above.
Most bitcoin wallets will manage the ideal fee for you. However, if you want to play with advanced options for how much you pay, you can play with the Samourai Wallet, as one example.
You can explore dynamic bitcoin statistics, including fee-based data, at https://bitcoin.clarkmoody.com/dashboard/, as shown in this next image.
Clarkmoody bitcoin stats
In the preceding image, the Fee Estimates table shows the cost in sats per byte you will likely have to pay to get your transaction through in each time frame. Note that most wallets will calculate and choose for you. Some will allow you simple options like “slow,” “medium,” or “fast,” and the advanced wallets will let you choose exactly what you want to pay.
The Transaction Fees table shows the average over the previous 2027 blocks. Note that the above statistics are dynamic and likely different when reading this. Visit the website to see the live statistics and many more as well.
Is Bitcoin too slow?
If a ten-minute block time sounds too long for a trivial transaction like a candy bar, then there are two ways of looking at the problem. The first way of looking at the problem is that for some transactions, yes, it could be faster, but there is a solution we will discuss shortly.
The second way of looking at it is to consider a scenario. Will the retailer worry about the potential failure of a candy bar transaction, and how often will the purchaser try and scam the retailer anyway for a free candy bar? The answer to the questions is probably not, and rarely, but the real solution to Bitcoin’s 10-minute block time (and, as we will see, limited block size) lies in the next section, The Lightning network. But if you sell a sports car to a stranger, you will want to wait until the transaction is confirmed and perhaps a block or two more for good measure before giving him the keys.
The lightning network
Visa can process more than 600 million transactions daily and handle as many as 6000 transactions per second. This is, as we will see, far more than Bitcoin. Visa, however, will only collate the transactions it receives and then present the total amount to be settled to the banks at the end of a period, usually the trading day. The banks may, and typically do, take even more time to make the funds available to the recipient and may decide not to honor some transactions. This means that despite the massive throughput, Visa is relatively slow to reach a final settlement. Furthermore, the banks or Visa may reverse transactions days, weeks, or months later. It goes without saying at this point that the whole point of Bitcoin is to get away from the fiat system and all its centralized entities like Visa, but is Bitcoin good enough?
Bitcoin processes “only” between 7 and 8 transactions per second (TPS), although the final settlement in 99% of transactions is just 10 minutes. I say 99% are settled in 10 minutes because, as alluded to when discussing mining, occasionally, a block is re-mined. Also, occasionally, there is a temporary fork in the blockchain where groups of nodes disagree about which blocks are valid. These issues automatically resolve once one version of the blockchain is longer than the other, and all nodes will revert to accepting the longest as the natural/canonical blockchain.
The Bitcoin performance might suffice as a long-term store of value for the global community, but there is no way it even comes close to allowing the whole planet to make all its transactions.
From a purely technical perspective, increasing the TPS is a simple matter. For example, Bitcoin Cash, not to be confused with Bitcoin, has already done this and boasts a TPS of 116. Consider increasing the Bitcoin block size (currently 1MB) and reducing the block time (now 10 minutes). Say multiply the block size by 100 (needing 100 MB per block), reduce the block time to 1 minute, and hey presto, you have 7000 transactions per second – more than Visa on a regular day. Problem solved? But Bitcoin Cash has a tiny adoption compared to Bitcoin, but why?
As we will see in the later section, Bitcoin evolution: Forks and block size wars, there are compelling arguments as to why Bitcoin should not be scaled this way, and we will get to them soon. So, what can be done? This is why the lightning network is being developed.
The lightning network was devised in 2015 and is still in development. It went live in early 2018. It is a peer-to-peer network connected to the bitcoin network, better visualized as running on top of it. It facilitates ultra-low-cost, vast-scale, near-instant transactions.
As Bitcoin is the original network, we refer to it as layer 1. As the Lightning network is connected on top of the Bitcoin network, we can refer to it as a layer 2 network. This next image helps visualize this idea.
Lightning on top of Bitcoin visualized.
The lightning network handles transactions but only occasionally finalizes/settles the transactions on layer 1 as indicated by the occasional blue connection between the black Lightning nodes and the orange depicted regular Bitcoin nodes we have already discussed. Multiple, dozens, hundreds, or thousands of layer 2 (Lightning Network) transactions can be handled in a single layer 1 (Bitcoin network) transaction.
You can open a connection with a friend, retailer, or anyone else on the Lightning network. This will trigger a transaction on layer 1, an on-chain (regular) transaction. When discussing financial interactions on the Bitcoin network, we usually refer to a transaction, but we tend to say payment on the Lightning network.
The connection can be visualized as a separate cryptographically signed ledger kept by the lightning network. The connection can be closed and settled on layer 1 by either party at any time. The connection is known as a payment channel. We can also visualize each person holding a copy of the off-chain transaction’s ledger; no real-time network connection is required. You are connected because you share a transaction, but that is all. Consider it like you might be connected to a friend on social media. Still, there is no actual network connection – you share that you both want to be friends, which gives mutually agreed to consent to the social media network to facilitate interactions between you.
This connection or payment channel is facilitated by a time-locked, multi-signature transaction that funds a new shared Bitcoin address between the two parties of the transaction. So, for example, if you send funds on the Lightning network, you will fund this new address; if you are receiving funds, you can access this address without funding it. Then, either party can close the channel, and an actual, on-chain bitcoin transaction will complete the transaction.
But neither party will need to close the channel. The strength of the Lightning network comes from more and more peers keeping channels open. The Lightning network keeps track of who owns what and facilitates sending/spending without the expense and delay of a “real” Bitcoin transaction.
This doesn’t sound very easy, perhaps to the extent that it puts you off using it, but the complexity is hidden. All you see in your Muun (or other Lightning-enabled) wallet is how much bitcoin you have and a list of the Bitcoin transactions and Lightning payments you have participated in. Although there are indeed hardcore and enthusiast wallets, you could even run a Bitcoin and Lightning node, and then you would be exposed to the complexity.
In El Salvador, bitcoin is legal tender. All the payments are facilitated through the Strike app, which runs on the Lightning network. Users can seamlessly switch between Bitcoin transactions, Lightning payments, and buying and selling Bitcoin into/from US dollars.
And from this point on, any transactions between these two parties can happen, almost for nothing, almost instantly, on layer 2.
So, do you need to pay to open a channel with everyone you want to transact with? No, because the lightning network facilitates payments between peers connected to any other peer. It does this using the open channels between the intermediate peers, connecting the transacting peers. Everything is guaranteed cryptographically. None of the intermediate peers is exposed to risk, so no trust is required.
You can transact with a retailer, and the transaction could go through a payment channel set up by your worst sworn enemy – it won’t matter; mathematics takes care of trust.
Once the Lightning network has enough capacity and liquidity, you can open one channel and transact with anyone on the whole planet. Once you can transact with anyone you want to, there would rarely be a need to close a channel to “get your bitcoin/change back” because why would you need to as anything you would want to do with your bitcoin can be done on the Lightning network; so why not leave some of your bitcoin on the lightning network.
No matter who transacts with whom, the correct balance will always be guaranteed for each participant through an intricate collection of multi-signature transactions, which can be considered cryptographically guaranteed IOUs. Many centralized exchanges will likely offer services via the Lightning network. In that case, it is easy to imagine that, eventually, everyone will be connected to everyone else. At the time of writing, Crypto.com, Robin Hood, BitPay, and Kraken centralized exchanges offer Lightning network integration.
However, as we learned with the Muun wallet, it is a hot wallet, so you wouldn’t want to keep your life’s savings in it. On the other hand, Lightning wallets can only be hot, so there would be occasions, perhaps monthly when you received your wages via the Lightening network; you might pay your bills, then close the channel and transfer some of the remaining bitcoin to your savings in a cold/hardware wallet.
This may, from my description, appear to involve some complexity. However, most of the complexity can be hidden from the user. For example, a wallet app can show you your bitcoin balance and allow you to transact on either network seamlessly – hiding most of the intricacies from the user.
So, the Lightning network can be equated to the Visa network on top of bitcoin, except that it is peer-to-peer, decentralized, censorship-resistant, much cheaper, irreversible payments, and more private.
The biggest current drawback for the Lightning Network is liquidity. Liquidity in this context refers to the availability of enough bitcoin to complete a transaction. If a network of peers is connected, but the value of their open channels is lower than that of a transaction you want to complete, the transaction will fail. This problem, however, will likely diminish and become a thing of the past as network adoption grows. Anyway, if you were going to send a significant amount of bitcoin, you would likely want to use the layer 1 (real) Bitcoin network for security, albeit slower, and automatic layer 1 settlement.
Having said about liquidity problems and my previous diagram showed the lightning network as a tiny bunch of around a dozen nodes; you should take a look at this next image from https://explorer.acinq.co/ showing a live map of the Lightning network that currently has nearly 12,000 nodes and 85,000 payment channels holding about 5000 bitcoins in liquidity.
If the discussion on the Lightning network is a little overwhelming, consider the Lightning thing as an intricate system of everchanging IOUs that never need to be called upon because your IOUs will be accepted as real money by anyone you want to transact with. This sounds like the barter system from Chapter 1, only we can trust anyone on the planet, or perhaps beyond, because of the cryptographic underpinnings.
We now have censorship resistance, inflation resistance, virtually private, and incredibly fast transactions. Do you see the potential for cryptocurrency to begin to solve some of the problems we discussed in chapters 1 and 2? I hope so, and we haven’t even mentioned programmable money, immutable smart contracts, and all the other cryptocurrency networks.
Some Bitcoin enthusiasts think that Bitcoin is the only cryptocurrency that is needed. It may well be that one day the Lightning network will be perfect, and there will be lots of services like lending, borrowing, and saving built into it: but it’s not there yet.
The Strike app
The Strike is only available in select regions at the time of writing, but it is worth mentioning because it has some unique features. It allows you to send fiat currencies, including US dollars, to other currencies in the selected regions. Strike provides its service by converting fiat currency into bitcoin, sending it on the lightning network, and then converting it back to the required currency. Note that Strike does not let you hold your private keys, and you must do KYC to use it. However, the fees are much lower than wiring money or even PayPal; they can’t take your bitcoin if they suspect you of spreading misinformation (see the afterword), and I guess that over time, the need to convert to dollars will diminish; after all, if you can do anything you want with Bitcoin, cheaper, faster, safer – why bother with those grubby fiat currencies. Therefore, Strike is not an app to store your life savings but could be a valuable option to keep your spending money, perhaps like a regular cash wallet.
There has been much to take in about Bitcoin and Lightning. I have simplified the whole thing, and there is always more to learn, but we know enough to move on.
Bitcoin evolution: Forks and block size wars
In 2009 when Bitcoin mined its first block, the maximum block size was 32MB. However, this was not so much a design choice by Satoshi Nakamoto as a simple hack in the code to avoid crashing the Bitcoin nodes. In 2010 Satoshi explicitly limited the block size to 1MB. This was a clear choice by Bitcoin’s creator. Nakamoto often sought feedback during the creation and early evolution of Bitcoin. He didn’t with the 1MB block size limit.
The arguments for a bigger block size are that more transactions are better. It was also thought that the restriction to 1MB and a de facto 6 transactions per second stopped the adoption of Bitcoin, especially from retailers. The argument goes that if you can give retailers Visa-like transaction speeds, with all Bitcoin’s other advantages, everyone will want to use Bitcoin.
The main argument against increasing the block size is that If blocks are too large, more powerful computers are needed to verify the blocks, especially if the larger blocks are combined with shorter block times. In addition, if the blocks are larger, as the blockchain grows, more storage is required to run a full node on the network. Furthermore, the more transactions there are in a shorter time frame, the less fully the transactions are likely to propagate the network leading to more block conflicts, causing more transactions to be re-mined as miners fight to have the winning chain when the blockchain forks. The former problem decreases decentralization by reducing the ease of running a node. The latter problem slows down the network, at least partially removing the benefit of any speed increase that might be gained.
You can run a Bitcoin node on a Raspberry PI computer for around $100. The result of increasing the block size or decreasing the block time is that there will be fewer nodes on the network. As a result, it would become less decentralized, less secure, more open to attacks like 51% attacks, and harder for ordinary folk who don’t own powerful computers to participate in running a node – the key to Bitcoin’s decentralization.
The argument against bigger blocks and faster block times isn’t so much that it is a bad idea in its entirety, just that it is bad for Bitcoin because Bitcoin is about decentralization and security, and these “upgrades” would be to the detriment. Furthermore, as Lightning network adoption and liquidity increase, even the perceived benefit becomes irrelevant. On the other hand, Litecoin, as we will see, upgrades the block time and size, which could be argued to be a success—more on Litecoin in chapter 9.
Gavin Andresen, sometimes seen as Satoshi’s replacement, supported increasing the block size. He proposed a project called Bitcoin XT, where the block size would double every two years. The idea was that as adoption grew, so would the block size, and in theory, so would the affordability of computing resources, making the cost to run a node still affordable to regular users.
Satoshi Nakamoto was claimed as a supporter on both sides of the argument, but he made one conclusive comment. However, some think the comment was faked by hacking Satoshi’s account on the Bitcoin forums. The statement is interesting, however, and somewhat compelling, at least to me.
Satoshi, or someone, said, “Bitcoin was designed to be protected from the influence of charismatic leaders, even if their name is Gavin Andresen, Barack Obama, or Satoshi Nakamoto…”. Nakamoto (or someone) strongly implied that the seemingly cumbersome need for agreement between node operators, miners, and the community was one of Bitcoin’s intentional and critical features. This does not necessarily mean Satoshi was for small blocks, although it is true that deliberately inhibiting change made small blocks more likely.
In some ways, this unwillingness to change could be seen as a fault of Bitcoin, but it is also a guarantee that it can’t be hijacked for nefarious purposes. No overwhelming consensus equals no change.
At the time of writing, December 2022, Ethereum has recently changed from proof of work to proof of stake consensus. There are arguments that it is less secure and decentralized because Ethereum nodes now require significant investment in money, machine, and skill. While it is also possible to argue the exact opposite of this, it is telling that the change happened because it was supported by Ethereum’s charismatic leader, not because there was an overwhelming consensus. In fact, the entire Ethereum proof-of-work mining community was programmatically excluded from participation. Proof of stake or PoS will be explained in Chapter 7.
Perhaps Ethereum will become more secure than Bitcoin and more decentralized, but perhaps it won’t. Instead, maybe it is the beginning of centralized control by the rich and powerful, and governments. For example, in September 2022, the Securities and Exchanges Commission of the United States government claimed in a legal filing that “[the]Ethereum blockchain, which is clustered more densely in the United States than in any other country…. As a result, … transactions took place in the United States.”
The significance of this is enormous. The US government is claiming jurisdiction over the second-biggest crypto network. Furthermore, just a month before this, another branch of the US government, the Office of Foreign Assets Control (OFAC), announced that a dApp called Tornado Cash on the Ethereum blockchain was sanctioned. Other significant dApps and node operators quickly moved to comply, blocking wallets that had transacted with the Tornado Cash dApp. Today, a considerable percentage, around 70%, of nodes will not handle transactions for wallets that OFAC doesn’t want them to. It doesn’t completely wreck the network because the censored wallets must wait until one of the 30% non-censoring nodes wins a block and includes their transaction. But what happens if OFAC goes further? DApps are decentralized applications that run on blockchains like Ethereum and others. They enable the execution of smart contracts, which are computer programs that users can use to lend, borrow, play games, mint NFTs, etc. DApps and smart contracts will be fully explained in Chapter 7, back to Bitcoin. So, Bitcoin might have a small block size, but perhaps that’s a good thing after all.
At the time of editing (February 2023), a new block size-related issue – NFTs on Bitcoin has arisen. A protocol has been developed to name every Satoshi, yes, each 100 million per Bitcoin, enabling users to attach a digital file to it and store it on the blockchain. This topic is too in-depth to cover properly, but perhaps I will include it in the next edition. Anyway, these NFTs, called Ordinals, have the potential to use up block space, making transactions more expensive. I have not decided if I think Ordinals are an overall benefit, although they are a very clever idea and interesting too. Either way, the miners and the node operators will work it out.
Eventually, a compromise that satisfied many but not all was found regarding the block wars. It proposed a backward-compatible upgrade called SegWit, where specific data from the block would be stored outside it.
This meant almost double the transactions per block and, most importantly to many, no hard fork. Furthermore, this upgrade also enabled compatibility with the Lightning network, further suppressing, but not silencing, the clamor for bigger blocks.
The technical difference between a hard and a soft fork is essential. In the context of Bitcoin, a fork is a split in the blockchain network that occurs when two or more blocks are created simultaneously. This split can happen for various reasons, including changes to the Bitcoin protocol or disagreements among the community on how the network should operate.
The main difference between a hard fork and a soft fork in Bitcoin is the level of compatibility between the new and old versions of the blockchain.
A hard fork is a permanent divergence in the blockchain where new rules are implemented, and the latest version is incompatible with the old version. This means that nodes running the old version cannot validate transactions on the new version and vice versa. This implies that two sets of nodes support two versions of the identical blockchain, but the two versions will diverge, and if unresolved, the result is two different cryptocurrencies.
On the other hand, a soft fork is a temporary divergence in the blockchain where new rules are implemented, but the new version remains compatible with the old version. This means that nodes running the old version can still validate transactions on the new version, but nodes running the new version may reject transactions from the old version. Soft forks are less contentious than hard ones because they are less likely to split the network and can be reversed if necessary. A temporary soft separation can also be when two opposing blocks are mined simultaneously. The network continues until the next block is mined, and whichever fork adds that next block becomes the canonical (real) blockchain.
However, even though a compromise had been found to the block wars, and eventually 95% of the miners voted to accept the SegWit changes, Bitcoin moves slowly, and the desire to increase the block size remained with some before SegWit was implemented, there was more block size drama.
If you are wondering where the term SegWit comes from, it stands for segregated witness. So it was the transaction signatures (the witnesses) were separated (segregated) from the rest of the data in the block.
A controversial character named Craig Wright, a prominent “big blocker,” claimed he was Satoshi Nakamoto. Very significantly, Gavin Andresen claimed he had seen cryptographic proof that Wright had mined the genesis block of Bitcoin. However, it is unclear why this proof could not be shared with the whole world, and for several other reasons, too, Wright was seen as a fraud by most.
In August 2017, Bitcoin Cash, with the support of Wright, Chinese hardware manufacturers Bitmain, and big companies, including centralized exchange Coinbase, was hard forked from the Bitcoin blockchain.
As an aside, if you find this history as intriguing as I do, it is probably because there is a feeling that this is more important than the story of a bunch of computer code on a network. Something genuinely globally historical has been unfolding over the past decade. If you want to know more about the block wars (this section is a small and incomplete account), you can read “The Block Wars,” available on Amazon.
Despite a successful launch, infighting quickly ensued, and in November 2018, another split (a hard fork of Bitcoin Cash) occurred, and Bitcoin SV (Satoshi’s Vision (allegedly)) was created.
Today, neither Bitcoin Cash nor Bitcoin SV has anything like the support or recognition of Bitcoin. And ironically, neither has ever mined a full block of transactions, and Bitcoin is widely seen as the only truly, user-controlled cryptocurrency. So if the government has a problem with Bitcoin, whose door will they kick down? I am not saying Bitcoin is unstoppable; merely it is probably the best chance humanity has of having self-sovereign money.
Bitcoin will certainly have challenges in the future, including regulatory challenges. The latest is a media and competitor fuelled attack on proof of work mining because of the amount of electricity it consumes. Undoubtedly, Bitcoin consumes a vast amount of electricity, but the actual argument should be, is it worth it?
Bitcoin maximalist is a term bitcoin enthusiasts see as a badge of honor and some as derogatory. Sometimes I think about Satoshi’s genius idea and the system’s beauty, and I might be a maximalist myself. However, the arguments about whether this is good or valid could easily take a whole book. So rather than try and engage in such a contentious and drawn-out argument, I will mention one single argument against the maximalist position and perhaps expose myself as a fake maximalist and maybe a mere enthusiast:
There is so much that Bitcoin can’t do, at least not yet, and why does Bitcoin have to do everything anyway? OK, that was two. If you had a Lamborghini, you wouldn’t pull the caravan with it – right?
There are maximalists on other chains too. I prefer to talk about these people as fans, enthusiasts, or, more simply, community members. Ethereum certainly has die-hard fans, as does Cardano, Cosmos, and Polkadot.
In 2017 the World Economic Forum WEF published an article claiming that by 2020 Bitcoin will consume more power than the rest of the world. It wasn’t an off-the-cuff sentence in the broader article. It specifically aimed at comparing Bitcoin to Visa without mentioning the differences (apart from energy).
Have no doubt; the organizations we will discuss in the afterword don’t just want to control you. They want to destroy the things that might prevent that control. You can see the article I referred to here: https://www.weforum.org/agenda/2017/12/bitcoin-consume-more-power-than-world-2020/.
A good takeaway from this chapter is that there are many ways to lose some or all of your money with cryptocurrency, but the Bitcoin protocol failing or being stopped somehow is the least likely way. Another takeaway might be that Bitcoin could eventually come to nothing – but it might change the world – perhaps it has already.
Previous: Using Bitcoin