Depuis le genesis block jusqu'à Taproot
Bitcoin, où en sommes-nous ? Un point de vue technique
Contexte
Auteur
Date
TL;DR
Taproot
The Lightning Network
Reminder:
Bitcoin has undergone several evolutions since its creation. Although the protocol is not known for its ability to evolve quickly, its historical updates have brought significant improvements, remarkably in terms of scalability, with the SegWit update, as well as privacy, with the Taproot update.
In addition to making the network more efficient, Bitcoin’s developments have allowed for more complex use cases, especially with relation to layer 2 infrastructures such as the Lightning Network, enabling the creation of a crypto-native, scalable payment system.
To date, Bitcoin is dramatically different from what it was at launch, since for example 85% of transactions are now based on SegWit’s specifications. Therefore, when talking about Bitcoin, it is crucial to take these changes into consideration: as a matter of fact, describing the network today as it was originally designed consists in a rather gross mistake, often made by media and polemists of different kinds.
It is the purpose of this article to analyze Bitcoin’s main developments and explore their impact in shaping the future of the network. Section 1 provides an overview of main evolutions concerning addresses’ format; Section 2 focuses on Taproot; Section 3 deals with the Lightning Network.
Disclaimer: as this article aims at focusing on the ongoing development around Bitcoin, and SegWit has already been widely adopted by the network, this update is not dealt with in details. Nevertheless, it is worth to remind that SegWit improved Bitcoin scalability and reduced fees by increasing block space and changing block structure. Furthermore, it modified some features of the network in order to allow a more secure use of the Lightning Network. To learn more about SegWit, see here.
The address changes
Bitcoin addresses are scripts allowing to lock and unlock bitcoins for spending. As Bitcoin has evolved, new address formats have appeared to take advantage of the network's new features. Below is a brief explanation of the main ones:
There are 2 versions of this format: the original P2PK (Pay to Public Key) and the new P2PKH (Pay to Public Key Hash). The P2PK format allows to pay (or more precisely to block/unblock) bitcoins with/to a corresponding public key. This address format was quickly replaced by the P2PKH format, which is the most commonly known nowadays.
P2PKH allows to block/unblock bitcoins with/to the hash of the public key. In comparison to P2PK, P2PKH brings several improvements, remarkably as it reduces the number of characters for a given address, thus ensuring a more efficient use of block space.
With P2SH, an address is no longer a hash of the public key but rather corresponds to the hash of a script. This represents a major enhancement as, before P2SH, complex scripts were not standardized on Bitcoin. This script allows to add conditions for spending bitcoins, such as multi-signature requirements. Sending bitcoins from a P2SH address is about 30% cheaper than from a legacy address (P2PKH).
This format changes the information transmitted in the transaction since blocks have a new format (see SegWit for more details). Transactions from P2WPKH (Pay to Witness Public Key Hash) addresses thus allow to furtherly reduce transaction fees (about -15% compared to P2SH) because signatures data are filled separately in the block.
P2TR (Pay to Taproot) addresses significantly reduce the weight of complex transactions (including MultiSig) thanks to the integration of Schnorr signatures (more explanation in the following section on Taproot). This signature format also improves the confidentiality of transactions (see section on Taproot). However, for simple transactions, SegWit addresses are slightly less expensive.
Compatibility between different address formats
Bitcoin updates are backwards compatible, and it is possible, for instance, to send or receive Bitcoins between SegWit and legacy addresses. However, the compatibility between these addresses depends not only on the Bitcoin network, but also on different wallet implementations. Some wallets do not allow to send or receive funds from different address formats (e.g. zxchanges).
Taproot
Taproot is a Bitcoin update implemented in November 2021 and encompassing several features. It builds on the SegWit update to improve privacy and reduce fees for more complex transactions on Bitcoin. It achieves this goal by leveraging a new implementation of Bitcoin scripts, as well as Schnorr signatures, which improve Bitcoin’s cryptography.
The Taproot update consists of three Bitcoin Improvement Proposals (BIPs): BIP 341 (Taproot), BIP 340 (Schnorr) and BIP 342 (Tapscript).
Schnorr (BIP 340)
Since its launch, Bitcoin has used ECDSA (Elliptic Curve Digital Signature Algorithm) signatures to secure its functioning. Taproot brings a new digital signature model to Bitcoin, called Schnorr signatures, which have several advantages over ECDSA in terms of storage space, computational efficiency, and privacy.
In fact, Schnorr's signatures are not new as they have been around since the 1990s and have been in the public domain since the end of the patent in 2008. However, although their advantages were already commonly known, until their implementation on Bitcoin Schnorr’s signatures had not become popular. Among other reasons, this explains why it took some time before considering them as a viable alternative to the more proven and robust ECDSA to secure the Bitcoin network.
The mathematical properties of Schnorr signatures differ from ECDSA. Indeed, Schnorr signatures are linear, and thus easier to aggregate and verify in a grouped manner. In other words, it is now possible to combine several signatures into one and verify a single signature rather than making several signatures, storing them, and verifying them in the case, for example, of a MultiSig transaction. This type of signature thus significantly improves the performance of complex transactions requiring multiple signers, resulting in less expensive operations. Moreover, by combining signatures, it is no longer possible to differentiate a MultiSig transaction from a simple one, which improves confidentiality. For example, by abiding to Taproot specifications, the creation of a Lightning Network channel (see section 2), which is a transaction requiring several signers, no longer differs from a classic transaction. Furthermore, signature aggregation allows signatures to be verified simultaneously in the same block, which considerably reduces the workload of Bitcoin nodes.
Taproot (BIP 341)
This proposal, also called "SegWit version 1 spending rules", inherits the previous SegWit update’s specifications and adds new standards. It defines how Bitcoin scripts should interact with Schnorr signatures and incorporates a new Merkle tree structure called Merkelized Alternative Script Trees (MAST), allowing multiple scripts to be encapsulated in a Merkle tree. This makes it possible to structure the various expenses conditions while benefiting from the verification mechanism of Merkle trees. Thus, one can verify that different conditions belong to the tree without revealing its entire content. For instance, we can spend bitcoins using a 2-of-2 multisig without revealing to the network that these same bitcoins could be spent by one person after a period of timelock. MAST therefore brings more privacy to Bitcoin since all the spending conditions of the scripts do not need to be revealed to make a spend.
Taproot also creates a new type of script called Pay-to-Taproot (P2TR), allowing to lock bitcoins in different ways: either associated with a simple public key, or associated with a tree of other scripts (MAST). In practice, P2TR addresses are a single Schnorr public key that is the aggregation of the recipient's (the owner/user of the P2TR address) public key 1 and the public key formed by the root of the MAST tree (see figure below).
Pay-to-Taproot spending possibilities (source: River)
This new format allows bitcoins to be spent in multiple ways from the same address, combining P2SH and P2PK functionalities while making the results of transactions look the same. This is how Taproot brings more privacy to Bitcoin transactions. The flexibility of this format also paves the way for a standardization of address types and transactions on Bitcoin that are still usage-specific to this day.
Tapscript (BIP 342)
Tapscript is an update to Bitcoin Script, Bitcoin's programming language. It adds functionalities related to Schnorr signatures and P2TR via new operations (opcodes).
In addition, Tapscript removes limitations related to the complexity of scripts:
Tapscript is therefore designed to improve the flexibility of P2TR scripts and to allow more sophisticated uses in the future.
Taproot adoption
The Taproot update has been well received by miners as in May 2021 90% of them were in favor of its activation. It was then activated on the Bitcoin mainnet on November 12, 2021 (block 709 632). However, the adoption of Taproot has been very slow, as currently, 9 months after its release, there are only about 0.5% of Taproot transactions. To put this figure in perspective, the previous major update Segwit reached 50% of transactions 2 years after its introduction and currently stands at 85% (after 5 years). As a possible explanation, Taproot might not yet be seen as necessary since, to date, there is a very limited number of complex transactions being processed on Bitcoin. However, it must be underlined that Taproot dramatically increases network flexibility, privacy and performance for complex transactions, paving the way for future innovations. For example, Taro, a protocol enabled by Taproot, will allow the creation (tokenization) of real-world assets, such as stablecoins, on Bitcoin and its native layer 2, the Lightning Network.
Lightning Network
What is the Lightning Network
In blockchain-based payment systems, transactions are verified and stored by all full nodes. This model brings the advantage of strong resiliency but is generally limited in terms of scalability, thus failing to provide a credible alternative to traditional payment networks. The Lightning Network (LN) proposes to solve this issue by bringing more scalability to Bitcoin.
The LN is a layer 2 of Bitcoin, processing transactions that are not directly recorded on the Bitcoin network. In other words, the LN modifies the way transactions are published on the primary Bitcoin network to improve scalability.
Like Bitcoin, LN is a decentralized network composed of several nodes. However, these nodes do not broadcast transactions to the entire network. They communicate individually with the nodes to which they are connected through payment channels.
LN payment channels are a kind of payment ledger between two nodes that allows bitcoins to be exchanged and only record final balances on Bitcoin (layer 1), when payment channels are closed.
The spider net of payment channels between different nodes constitutes the Lightning network. This set of interconnections allows payments to be made between parties that do not have direct open channels, by passing through intermediate nodes on the network. This way, liquidity moves through the different channels like across communicating vessels.
In short, the LN ensures the possibility of exchanging value without a trusted intermediary and at a much lower cost since only the opening and closing transactions of the channel are published on Bitcoin and require the payment of fees.
Trust and security in the Lightning Network
The creation of a Lightning channel is a Bitcoin transaction using a specific Bitcoin script with the following features:
Once the channel-opening transaction is completed, both users can exchange bitcoins (within the pre-defined maximum limits) at no cost since they are no longer performing on-chain transactions and only need an internet connection. Transactions on the LN are in fact Bitcoin’s transactions that are not published on the blockchain. Each exchange on the LN is co-signed and allows any user to close the channel by publishing the last transaction, and therefore the update of the two parts’ balances, on Bitcoin.
The LN has an anti-cheating mechanism based on the properties of HTLC. To allow users to exchange bitcoins without the risk of fraud, transactions are designed to be completed after a time limit (the timelock). In addition, HTLC enables the use of conditions: a user X can thus spend bitcoins only if they prove to know a certain password. Hence, if a user tries to close the channel fraudulently, meaning by publishing a wrong final balance on the layer 1 network, the transaction is blocked for a given time, which allows the other user to acknowledge the fraud. In addition, if the victim has the time to notice the attack, they can revoke the transaction by proving with the corresponding password that the operation is fraudulent, and then punish the fraud by slashing all the channel balance. Indeed, when a new transaction is issued on the LN, the payer and the payee share a new password, allowing to revoke the previous transaction. It is therefore possible to revoke all previous states of the channel with the corresponding password and only the last transaction (the right one) in the channel is irrevocable. However not all transactions are fraudulent, and the channel can be closed in different way. It can be close unilaterally if one user wants to recover its fund on Bitcoin and the other is disconnected, or users can also agree to close the channel by signing a last transaction on Bitcoin to reduce fees and delay compared to a unilateral closure.
The security mechanism also works between multiple channels. For example, if Alice wants to pay Bob and they are only connected through Joe's node, Alice will have to pay Joe and Joe will have to pay Bob. This operation requires ensuring that Joe will pay Bob to avoid middleman fraud. This assurance is provided by the HTLC. To receive payment, Bob will provide Alice with the hash of a password. Alice will make a payment that will be directed to Joe, if he communicates the password that allowed to generate Bob's hash. To recover this password Joe will make a transaction to Bob with the same condition. So, to recover the payment Bob must communicate his password to Joe and, in the same way, Joe communicates the password to Alice. If the passwords are not transmitted to validate the transactions, the payments will be cancelled after a given time. This operation differs from blockchain transactions in that it is not possible to receive a payment passively: in other words, an Internet connection and the generation of a password are required for any transaction to be completed. This can be compared with the mechanism on Eftpos terminals that require internet for accepting payments.
Lightning Network challenges
Unlike exchanges between two directly connected nodes, going through intermediary channels may imply costs to remunerate the middlemen. The fees are specific to each channel and can take the form of a fixed fee or a share of the exchanged quantity.
One of the challenges to efficiently transfer value on the LN is to find the cheapest path (with sufficient liquidity) between the different existing channels. This routing problem is a crucial element for the proper functioning of the LN, and depends on the network topology. The calculation corresponds to the NP-complete travelling salesman problem, which is known to be difficult to solve.
While it is simple to solve this problem with a few nodes on the network, it becomes exponentially more complex as the number of nodes increases, and the adoption of LN as a payment system grows. Since it is the payment issuer that must calculate the routing to make transactions, it could be difficult in the long run to make a transaction at the best price from a user device like a smartphone. However, there are specfic algorithms to address this problem and the possibility of using an intermediary to perform the calculation also offers an alternative.
Another challenge is the adoption of the Lightning Network as a global payment system. Currently the LN can only process exchanges in bitcoins, which considering the asset’s volatility represents a major limit for day-to-day payments. Demand for stablecoins has been steadily increasing over the past years and, looking forward, stablecoins’ adoption on Bitcoin seems necessary for the protocol to establish itself as a serious alternative to legacy payment systems. Until today, using stablecoins on the LN was only possible by leveraging centralized, custodial solutions such as Bitcoin Beach Wallet. However, thanks to the recent launch of the Taro (Taproot Asset Representation Overlay) protocol, currently in alpha version, it will soon be possible to natively create and exchange stablecoins on the LN. Indeed, Taro enables the representation of real-world assets on Bitcoin by means of Pay-To- Taproot transactions that encapsulate multiple scripts and asset metadata in a tree structure. Therefore, Taro has the potential to significantly foster the use of the Lightning Network at large scale.
Conclusion
In conclusion, Bitcoin is now a much more efficient network than it was in the beginning. It offers brand new features as well as an improved functioning for those features available from day 0. For a sum up of just some of the remarkable evolutions of the network, it is worth to mention:
Most importantly, Bitcoin's value proposition has been strengthened by giving the network the tools to become an efficient payment system with the Lightning Network. The latest Taproot update does move to this direction as it optimizes the integration of the Lightning Network both in terms of privacy and scalability. In addition, Taproot increases Bitcoin flexibility, thus fostering future innovation on the network. For example, thanks to Taproot, the newly launched Taro protocole will allow the creation of stablecoins natively on Bitcoin and on the LN.
Initiatives also exist to try and create other use cases on Bitcoin, especially by enabling secure general-purpose computations. It is the case, for instance, of RGB, which seeks to bring smart contracts to Bitcoin via external client-side executions. Other projects aim at allowing Bitcoin to verify proofs of execution of general-purpose layer 2. If the protocol continues to evolve, these projects may one day provide new use cases for Bitcoin, furtherly strengthening its original, minimalistic, and yet so powerful value proposition.
Sources
Addresses comparison
Bitcoin address formats and performance comparison | FixedFloat
Transaction size calculator | Bitcoin Optech (bitcoinops.org)
Segwit
https://river.com/learn/what-is-segwit/
https://en.wikipedia.org/wiki/SegWit
Taproot
https://river.com/learn/what-is-taproot/
https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures
https://medium.com/interdax/what-is-tapscript-and-how-will-it-benefit-bitcoin-96fbb43a7169
Schnorr: https://bips.dev/340/ Taproot: https://bips.dev/341/ Tapscript: https://bips.dev/342/
Taro - Builder's Guide (lightning.engineering)
Lightning Network
https://blog.bitmex.com/the-lightning-network/