Building on Bitcoin — Latest Developments
Why not build on Ethereum etc.?
In my last article, “Why Proof-of-Stake Doesn’t Work”, I went over some of the main reasons why the new engine driving Ethereum defeats its own purpose by pegging the security of the network to the price of the token it produces. Without going into too much detail, here’s the general summary: There’s a fallacy called “assuming the conclusion” first described by Aristotle in which a line of reasoning assumes its conclusion in its premise. For instance: “Green is the best colour because it’s the greenest of all colours.” It presupposes that green is best, which is also the conclusion of the entire thing. Similarly, the logic of Ethereum’s code is a demonstration of this same fallacy: “ETH has value because Ethereum is secure, and Ethereum is secure because ETH has value.” I recommend reading the full article, however, as this is the most barebones explanation possible of why Ethereum sucks.
Why build on Bitcoin?
Gunpowder was originally considered a medicine, and its weaponisation was never considered. Why? Because its inventor was originally tasked with developing a novel medicine and stumbled upon gunpowder instead. It’s often the case that inventions happen by accident or their use cases turn out to be much wider than originally anticipated. So, it’s safe to assume that Bitcoin, an invention that’s only now entering its teen years, will also end up being used in many more ways than initially anticipated. In just the last few years alone, Bitcoin has seen upgrades that are expanding its functionality manifold. Here’s a brief list of some of the biggest upgrades Bitcoin has seen over the years and a brief explanation of how they were achieved.
Increasing Decentralisation & Efficiency: SegWit
In August of 2017, one major update occurred that would change the future of Bitcoin forever: SegWit. Where transactions used to contain their signatures in a section called “witness”, making them quite large. SegWit segregated that witness data to be stored in a separate, dedicated section. This update increased the number of transactions that could fit into a single block before it reached its 1MB size limit. It also allowed for the use of a different type of digital signature algorithm called “schnorr”, which I will mention later. It also fixed an annoying problem in Bitcoin known as “transaction malleability”, which allowed nodes to alter transaction IDs, creating more than one valid version of the same transaction. This is a huge problem since transactions are organised in a chain, so you can’t be certain that your transaction output is valid unless its input is finalised. Transaction malleability also prevented some functionality in Bitcoin. For example, suppose Alice and Bob want to enter an agreement where Alice will fund a ‘joint ownership’ (aka: multi-signature) contract from which both of their signatures are required to send funds. Alice writes and signs a withdrawal transaction (called a ‘commitment transaction’) to withdraw her funds after some time — in case Bob goes awol or refuses to cooperate — but doesn’t yet broadcast the transaction to the Bitcoin network. Now, they can exchange more of these signed transactions off-chain to avoid transaction fees and waiting times before eventually settling the final balance on the blockchain. With transaction malleability, this wouldn’t be possible; should Bob manage to alter the transaction ID of the funding transaction on chain, it would make the withdrawal transaction invalid (the funding transaction it references would no longer exist on the blockchain since Bob changed its ID), and Alice wouldn’t be able to withdraw her funds. SegWit fixed transaction malleability by removing transaction signatures from the input of the function that determines the transaction ID. So, just a relatively small upgrade in SegWit opened up the functionality of Bitcoin a lot… which leads me to the next upgrade.
Lightning.
The Lightning network is probably the most substantial upgrade to Bitcoin’s functionality thus far, and it is essentially an expanded version of the arrangement between Bob and Alice. Explained simply, it’s a network of people participating in these joint-ownership addresses, sending copies of valid transactions between each other (like cheques) as payments before broadcasting the final state of balances to the blockchain. Using signed transactions as payment themselves while reserving the right to broadcast them to the blockchain allows you to avoid paying full transaction fees with each transaction. Because either party can redeem these “cheques” at any time, they still benefit from the security of the Bitcoin blockchain. It’s like opening a bar tab, where the amount one party owes another is just recorded, and then the sum is ‘officially’ settled at the end, meaning you can buy as many beers as you’d like but will only have to pay transaction fees once. This drastically reduces transaction fees for smaller transactions and exponentially increases the number of transactions that can occur per second. These two issues, transactions per second and transaction fees, are the two main barriers to scalability. The lightning network has immensely expanded the scalability of Bitcoin and made it both possible and easy to pay for coffee with it (as I often do!).
Taproot
Remember that digital signature algorithm I mentioned earlier called ‘Schnorr’? Well, the ability to use these signatures has birthed one of the most recent upgrades to Bitcoin: Taproot. Taproot (and Schnorr signatures alongside it) went live in November 2021 and brought huge upgrades to Bitcoin functionality and privacy. Before Taproot, smart contracts on Bitcoin, such as time-locks and multi-signatures, were quite data intensive and required the entire network to be savvy to their use since the condition of the contract had to be written to the blockchain. This allowed blockchain analysis companies to gain lots of information about the nature of wallets, transactions etc., which reduced privacy. With Taproot, it’s now possible to create smart contracts containing up to 2128 conditions! That’s a very big number, meaning very complex contracts, at least comparatively speaking. That must be very data-intensive, though, right? To write all those conditions (scripts) to the blockchain? That’s the cool part, none of the contract conditions ever have to be written to the blockchain. Only when spending the bitcoin stored in one of these contracts do the conditions have to be revealed, and even then, only the condition you satisfied must be revealed. This means that all transactions to Taproot addresses look the same on the blockchain, which eliminates the ability of analysis companies to tell if a transaction is to a multi-signature, single-signature, time-lock address or even a complex contract address with millions of conditions. They all look exactly the same! It’s impossible to tell if a transaction is funding a Lightning channel since it uses a two-out-of-two multi-signature contract, which is indistinguishable from a standard address on Taproot. All this while drastically expanding the functionality of Bitcoin, increasing its efficiency, decentralisation and privacy. How this is made possible can only be described as cryptographic wizardry, so I won’t even try to explain here… but it works!
Taro
Yet again, a previous invention is leading to further possibilities and wider use cases… in the case of Taro, whether those use cases are good or not, I don’t know, but with Bitcoin’s track record, I wouldn’t like to doubt its implications as a foundation for future awesomeness. Taro has expanded upon the functionality of Taproot by developing a protocol that leverages the possible complexity of Taproot contracts in conjunction with the developments of the Lightning network to allow digital assets to be issued on the Bitcoin blockchain and transacted over the Lightning network… pretty cool, huh? This one is a little harder to explain without getting super technical, so I’ll just absolutely butcher it by attempting to give a non-techy explanation of something in which each piece of information requires technical context to make any sense, so bear with me. Okay, so… remember when I said that transactions to all Taproot addresses and contracts look exactly the same? Well, that’s because all the information on the possible conditions of Taproot contracts isn’t stored within the transaction but is verifiable by it. What does that mean? Although you cannot see a Taproot transaction (in which someone is sending bitcoin to a taproot address) and determine what conditions must be satisfied (if any) by its recipient to spend that bitcoin, you can verify to everyone else that a given condition is included if you already know it. This is done in — sort of — the same way that you verify that a signature was made with the owner of a certain private key. This is how recipients prove to the Bitcoin network that they have satisfied a condition of the contract when spending since, in doing so, they also prove that the condition is included in the contract — you can’t verify that you have satisfied a random requirement to spend bitcoin that’s locked in a contract, you also have to prove that that condition you satisfied was in the contract, to begin with. Essentially, the address of a Taproot contract is determined by the conditions to unlock it by a one-way function, and this is done in such a way that you can verify the existence of one condition without revealing the rest, so long as you know the condition. Still with me? Now, these conditions — code — can contain “extra data”, and if that data happened to be a token, then we could technically issue these tokens within Taproot transactions, and participants could verify their tokens’ existence to one another without ever having to actually store them on the Bitcoin blockchain. ANDDDD… since it’s possible for participants to verify the existence of their tokens in Taproot addresses, they can transfer signed transactions that contain them over the Lightning network without ever congesting the Bitcoin blockchain or being subject to its fees… damn. Inventions…
Inventions
This article has left you with more questions than answers, but hopefully, it has left you certain of one thing: Bitcoin is not a finished product, and just because something is impossible today doesn’t mean it will be impossible tomorrow. Just as gunpowder was originally used as medicine, many of Bitcoin’s original use cases may be seen as silly years from now, but the underlying core of the invention — the convertibility of energy to scarcity and, therefore, security — will likely lay the foundation for immense innovation over time, the likes of which nobody today could predict, as predicting it would be the same as inventing it.
So, build on Bitcoin.
