In November 2023, the number of Bitcoin on-chain transactions increased by 62% month-on-month (MoM), mainly due to the recovery of Ordinals and BRC-20. The total USD value of Bitcoin transferred in November exceeded $147 billion, a significant increase of 21% from the previous month. This growth can be mainly attributed to the appreciation of BTC price in USD, but BTC trading volume in the spot market also increased by 18% month-on-month, while futures trading volume decreased by 1% month-on-month respectively.
Since the rise of Ordinals in January 2023, the Bitcoin development community has seen a significant resurgence in exploring new fungible token protocols, scaling solutions, and smart contract implementations. Overall, the post-Ordinals Bitcoin development landscape has expanded and is working harder than at any time in years to enhance on-chain and off-chain application use cases. This note will highlight seven major developments and recommendations for Bitcoin in Q4 2023. These developments highlight a renewed commitment from Bitcoin ecosystem developers to expand Bitcoin’s adoption and support use cases.
Technical Development BitVM What is BitVM: BitVM implements expressive smart contracts on Bitcoin. Given the nature of Bitcoin’s design, executing smart contracts directly on Bitcoin is slow and expensive. With BitVM, smart contracts are executed off-chain, and participants can only use the code directly on Bitcoin in the event of a dispute, leveraging Bitcoin’s native script to enforce the contract rules. BitVM operates in a similar way to the optimistic rollups used in the Ethereum ecosystem, with elements such as fraud proofs and challenge-response protocols. BitVM contracts are structured to have two parties agree on a sequence of pre-signed transactions that lead to an event. Similar to optimistic rollups, these types of contracts assume that you don’t cheat, but if you do, the honest party has a chance to challenge the cheater. Crucially, BitVM does not require upgrading Bitcoin’s Layer 1 blockchain. BitVM only uses primitives that are already understood in Bitcoin, such as hashlocks, timelocks, and Tapscript. Why it matters: Bitcoin is often criticized for its lack of innovation and ability to compete directly with other more general Layer 1s like Ethereum and Solana. Bitcoin has always prioritized layer-by-layer expansion over trying to extend the functionality of the base layer. The Lightning Network is an example of a high-performance, payments-centric network built on top of Bitcoin. With BitVM, more complex computations can be performed on layers built on top of Bitcoin, continuing to scale Bitcoin through layers rather than upgrading the core protocol.
Taproot Assets Launches on MainnetWhat is the Taproot Assets Protocol: Lightning Labs, a blockchain development company that builds software for the Bitcoin Lightning Network, has released a new protocol for issuing stablecoins and other assets on the Lightning Network. The Taproot Assets Protocol (formerly known as TARO) enables developers to issue, send, and receive Bitcoin-based assets. Lightning Labs has been proposing and working on ways to issue assets on the Lightning Network for years, and this mainnet launch is a major milestone. Taproot Assets are created by entering arbitrary data into a Taproot Script (Tapscript). Tapscript is a scripting language used to enable a variety of new transaction types during the Taproot upgrade. Taproot assets use Taptree, a Merkle tree data structure, to store token data in Taproot outputs. All Taproot assets are issued on-chain through standard Taproot transactions at the base layer. Although Taproot assets are issued and settled on the Bitcoin base layer, Lightning Labs specifically designed Taproot assets to be compatible with the Lightning Network. The functionality of Taproot assets is enabled by a modified version of the Partially Signed Bitcoin Transaction (PSBT), which is also used to trade Ordinals and BRC-20, called Virtual Partially Signed Bitcoin Transaction (vPSBT). This mechanism is a way to trade Taproot assets in a trustless, peer-to-peer manner on the Lightning Network.
Why it matters: Taproot Assets will provide an efficient way to create fungible tokens on Bitcoin. In April 2023, Ordinals developers created a new fungible token standard called BRC-20. This token standard uses inscription technology to allow users to attach arbitrary data to a single sat, the smallest unit of Bitcoin. The advent of BRC-20 proves that there is demand for NFTs on Bitcoin, despite the notoriously inefficient BRC-20 standard. With the official launch of Taproot Assets on October 18, 2023, NFTs on Bitcoin have a chance to flourish on the Lightning Network. The benefits of having NFTs on the Lightning Network include reducing network congestion on Bitcoin's native chain. Overall, Taproot Assets is a promising solution to introduce NFTs on Bitcoin and get more users on board with the Lightning Network.
OP_CAT Proposal
What is the OP_CAT proposal: Bitcoin researcher Ethan Heilman submitted a Bitcoin Improvement Proposal (BIP) to the Bitcoin-Dev mailing list proposing to add the OP_CAT opcode to the Bitcoin scripting language. This opcode will enable developers to build and evaluate Merkle trees and other hash data structures in Tapscript, a native scripting language used to enable new transaction types during the Taproot upgrade process. OP_CAT is not a new idea. Bitcoin developers previously removed opcodes from Bitcoin scripts because it could build data-intensive scripts that taxed Bitcoin node computing resources. However, since the Taproot upgrade introduces a size limit for Taproot scripts (520 bytes), OP_CAT will be a useful tool for developers without incurring excessive computational overhead for node operators. Why it matters: Before the Taproot upgrade in November 2021, Bitcoin relied entirely on Bitcoin Script for programmability. However, the Taproot upgrade significantly expands Bitcoin’s transaction programmability capabilities. Enabling OP_CAT will further enhance Bitcoin’s programmability by removing previously imposed limitations, creating new opportunities for different use cases.
OP_TXHASH Draft Proposal What is the OP_TXHASH Draft Proposal: Bitcoin Core developer Steven Roose has proposed a BIP that focuses on the benefits of implementing two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, to the Bitcoin Script language. The OP_TXHASH opcode will directly compete with two of the leading contract proposals in Bitcoin today, BIP-118 and BIP-119. A contract is a pre-determined spending condition imposed on a Bitcoin transaction. For example, a user could create a contract that ensures that a transaction recipient can only spend BTC sent to their address after 200 blocks. Why it matters: Enabling contracts could be the impetus for Bitcoin’s next major upgrade. TXHASH is one of the leading BIPs that developers hope to activate in 1-2 years. TXHASH allows for customizable transaction fields in Bitcoin transactions, providing a more adaptable way to express contracts. This flexibility enables users to adjust transaction fees, a critical feature when dealing with uncertain and fluctuating fee rates that other contract proposals like BIP-119 do not support. Additionally, when combined with other BIPs like OP_CAT, OP_TXHASH has the potential to replicate the functionality of BIP-118, another leading contract proposal currently being evaluated by the Bitcoin community.
Lightning Timeout Trees Proposal What is the Lightning Timeout Trees Proposal: The Lightning Network is Bitcoin’s primary layer 2 that has seen widespread adoption over the past few years. A key barrier to further adoption is that users using the Lightning Network need to initiate at least one on-chain Bitcoin transaction in order to move funds off-chain. This limitation limits the number of users who can move assets off-chain, especially when on-chain transaction fees are high. A long-explored solution is a concept called “channel factories” that would allow multiple users to join the Lightning Network in a single Bitcoin transaction. The implementation of channel factories has the potential to significantly lower the barrier to entry for the Lightning Network by reducing the cost of opening Lightning channels between multiple users. Why it matters: While the theory of Bitcoin has been around for years, its scripting limitations have made it difficult for anyone to come up with a convincing and secure solution to enable channel factories. However, John Law’s “Lightning Timeout Trees” proposal may have found a solution using covenants, which are spending conditions on BTC transaction outputs. The proposal introduces the concept of a coordinator (or Lightning Service Provider – LSP) who would oversee the opening and closing of user channels. By using covenants, the coordinator would be restricted from spending a user’s BTC without proper authorization. While the proposal is not without limitations, it is the first channel factory architecture to utilize covenants, a powerful mechanism for adding spending conditions on BTC that is becoming increasingly popular among Bitcoin developers for a variety of use cases including BTC custody (see BIP 345).
Updated Musig2 Proposal What is the MuSig2 proposal: MuSig2 is an upgraded version of MuSig1, a multi-signature scheme on Bitcoin that enables privacy and scalability. MuSig allows multiple parties to control a private key with their own keys. A shared private key does not look like an on-chain multi-signature transaction, thus leaving a minimal on-chain footprint. MuSig1 is an advancement based on Schnorr signatures that offers significant enhancements over Bitcoin's traditional multi-signature scheme that relies on ECDSA. MuSig2 (BIP-327) is an improved iteration of MuSig1, providing superior security, efficiency and privacy features by operating as a two-round multi-signature scheme, requiring only two rounds of communication between signers to generate valid signatures instead of Three rounds. In October, Bitcoin Core developer Andrew Chow proposed two new BIPs focused on MuSig2 development. The proposed BIPs are MuSig2-PSBT and MuSig2-Descriptor. Why it matters: MuSig2-PSBT is a standards-track BIP that will enable a private multi-signature scheme for partially signed Bitcoin transactions (PSBT). This advancement will benefit Ordinals and BRC-20 users and markets, which use PSBT to facilitate the sale of assets, in addition to other users. Integrating MuSig2 into PSBT will overall help hide these types of on-chain transactions by making multi-signature transactions look like single-signature transactions. The second BIP, MuSig2-descriptors, is an informational BIP that will help wallet providers implement MuSig2-PSBT by providing a way to describe transaction outputs controlled by MuSig2 wallets. It is worth noting that the BIP for MuSig2-PSBT is still under preliminary review and needs to be assigned a BIP number, so the BIP will not be ready for shipping in the short term (6-12 months).
BIP-324 – V2 Transports What is BIP-324: BIP-324 is a privacy-oriented improvement to Bitcoin’s P2P layer. This layer on Bitcoin facilitates the transfer of data between Bitcoin nodes. The Bitcoin P2P layer acts as a highway for data, although much of that data is in plaintext and is vulnerable to many types of attacks. Potential attackers may employ passive methods, such as monitoring node activity to gather information about IP addresses and transaction origins, or active techniques, including intercepting data transmitted by nodes and tampering with it, such as censorship. These attacks are known as MITM (man-in-the-middle) attacks. BIP-324, formerly known as BIP-151, advocates for encryption of data on Bitcoin’s P2P layer to increase resistance to both passive and active attacks on Bitcoin.
Why it matters: The latest version of Bitcoin core (v0.26) adds support for version 2 encrypted P2P transfers as specified in BIP-324. The feature is disabled by default, but allows anyone to turn it on and benefit from the added protection. This is a major step forward for P2P-level privacy on Bitcoin, marking the first time a BIP has been activated on Bitcoin since 2021 (although BIP-324 does not require a soft fork).
