Galaxy: Analyzing Bitcoin Technology Development in Q4 2023 from Seven Major Themes

Written by: Gabe Parker, Guillaume Girard

Compiled by: Song Xue, Golden Finance

Abstract:

This article focuses on significant technical developments in the Bitcoin ecosystem that occurred in October and November 2023. We cover the following seven topics:

• Release of the BitVM white paper
• Launch of Taproot Assets on the mainnet
• OP_CAT proposal
• OP_TXHASH proposal
• Lightning Timeout Trees proposal
• MuSig2-PSBT proposal
• BIP-324 proposal

Introduction

In November 2023, the number of on-chain Bitcoin transactions increased by 62% month-over-month (MoM), primarily due to the resurgence of Ordinals and BRC-20. The total dollar value of Bitcoin transfers in November exceeded $147 billion, marking a significant 21% increase from the previous month. This growth is mainly attributed to the appreciation of BTC prices in USD, but the trading volume of BTC in the spot market also increased by 18% MoM, while futures trading volume decreased by 1% MoM.

Bitcoin Monthly Data Metrics

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 developers are working harder than ever to enhance on-chain and off-chain application use cases. This report will focus on seven major developments and proposals for Bitcoin in the fourth quarter of 2023. These developments highlight the commitment of Bitcoin ecosystem developers to expand the application scope and support use cases for Bitcoin.

Technical Developments

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 costly. With BitVM, smart contracts are executed off-chain, and participants can only directly use the code on Bitcoin in the event of a dispute, leveraging Bitcoin's native script to enforce contract rules. BitVM operates similarly to optimistic rollups used in the Ethereum ecosystem, incorporating elements like fraud proofs and challenge-response protocols.

The structure of a BitVM contract allows two parties to agree on a pre-signed sequence of transactions that lead to an event. Similar to optimistic rollups, these types of contracts assume you are not cheating, but if you do cheat, the honest party has the opportunity to challenge the cheater. Crucially, BitVM does not require upgrades to Bitcoin's Layer 1 blockchain. BitVM only uses primitives already understood in Bitcoin, such as hash locks, time locks, and Tapscript.

Why it matters: Bitcoin is often criticized for its lack of innovation and its inability to compete directly with other more versatile Layer 1s like Ethereum and Solana. Bitcoin has always prioritized layered scaling over attempting to expand the functionality of the base layer. The Lightning Network is an example of a high-performance network built on top of Bitcoin that focuses on payments. With BitVM, more complex computations can be executed on layers built on Bitcoin, continuing to scale Bitcoin through layers rather than upgrading the core protocol.

Launch of Taproot Assets on the Mainnet

What is the Taproot Assets protocol: Lightning Labs, a blockchain development company building 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. For years, Lightning Labs has been proposing and working on ways to issue assets on the Lightning Network, and this mainnet launch is a significant milestone.

Taproot Assets are created by inputting arbitrary data into the main root script (Tapscript). Tapscript is a scripting language that enables various 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 has specifically designed Taproot Assets to be compatible with the Lightning Network. The functionality of Taproot Assets is achieved through an improved version of partially signed Bitcoin transactions (PSBT), which is also used for trading Ordinals and BRC-20, called virtual partially signed Bitcoin transactions (vPSBT). This mechanism provides a way to trade Taproot Assets on the Lightning Network in a trustless peer-to-peer manner.

Why it matters: Taproot Assets will provide an effective 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, allowing users to attach arbitrary data to a single sat (the smallest unit of Bitcoin). The emergence of BRC-20 demonstrates the demand for NFTs on Bitcoin, although the inefficiency of the BRC-20 standard is well-known. With the official release of Taproot Assets on October 18, 2023, NFTs on Bitcoin have the opportunity to thrive on the Lightning Network. The benefits of having NFTs on the Lightning Network include reduced network congestion on the Bitcoin native chain.

Overall, Taproot Assets represent a promising solution for introducing NFTs on Bitcoin and bringing more users onto the Lightning Network.

OP_CAT Proposal

What is the OPCAT proposal: Bitcoin researcher Ethan Heilman submitted a Bitcoin Improvement Proposal (BIP) to the Bitcoin-Dev mailing list, suggesting the addition of the OPCAT opcode to the Bitcoin scripting language. This opcode would enable developers to build and evaluate Merkle trees and other hash data structures in Tapscript, which is a native scripting language that enables new transaction types during the Taproot upgrade.

OPCAT is not a new idea. Bitcoin developers previously removed the opcode from Bitcoin script because it could construct data-intensive scripts, thereby increasing the computational burden on Bitcoin nodes. However, since the Taproot upgrade introduced a size limit for Taproot scripts (520 bytes), OPCAT will become a useful tool for developers without imposing excessive computational overhead on 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 expanded Bitcoin's transaction programmability capabilities. Enabling OP_CAT will eliminate previously imposed limitations, further enhancing Bitcoin's programmability and creating new opportunities for different use cases.

OP_TXHASH Proposal Draft

What is the OPTXHASH proposal draft: Bitcoin core developer Steven Roose proposed a BIP focusing on the benefits of implementing two new opcodes, OPTXHASH and OPCHECKTXHASHVERIFY, in the Bitcoin scripting language. The OPTXHASH opcode will directly compete with two major contract proposals in today's Bitcoin, BIP-118 and BIP-119. Contracts impose predetermined spending conditions on Bitcoin transactions. For example, a user can create a contract that ensures the transaction recipient can only spend the BTC sent to their address after 200 blocks.

Why it matters: Enabling contracts could drive the next major upgrade for Bitcoin. TXHASH is one of the leading BIPs that developers hope to activate within 1-2 years. TXHASH allows customization of transaction fields in Bitcoin transactions, providing a more adaptive way to express contracts. This flexibility enables users to adjust transaction fees, which is a critical feature when dealing with uncertain and volatile rates, something that other contract proposals like BIP-119 do not support. Additionally, when combined with other BIPs like OPCAT, OPTXHASH 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 solution and has seen widespread adoption over the past few years. A key barrier to further adoption is that users need to initiate at least one on-chain Bitcoin transaction to move funds off-chain when using the Lightning Network. This limitation restricts the number of users who can migrate assets off-chain, especially in situations where on-chain transaction fees are high.

A long-explored solution is the concept of a "Channel Factory," which allows multiple users to join the Lightning Network in a single Bitcoin transaction. The implementation of Channel Factories has the potential to significantly lower the entry barrier to the Lightning Network by reducing the cost of opening Lightning channels among multiple users.

Why it matters: Although the theory of Bitcoin has existed for years, its scripting limitations have made it difficult for anyone to come up with a compelling and secure solution to enable Channel Factories. However, John Law's "Lightning Timeout Trees" proposal may have found a solution using contracts (i.e., spending conditions on BTC transaction outputs). This proposal introduces the concept of a coordinator (or Lightning Service Provider - LSP) that will oversee the opening and closing of user channels. By using contracts, the coordinator will be restricted from spending users' BTC without proper authorization. While the proposal is not without limitations, it is the first Channel Factory architecture to leverage contracts, which are a powerful mechanism for adding spending conditions on BTC, increasingly popular among Bitcoin developers for various use cases, including BTC custody (see BIP 345).

Updated MuSig2 Proposal

What is the MuSig2 proposal: MuSig2 is an upgraded version of MuSig1, which is a multi-signature scheme on Bitcoin that achieves privacy and scalability. MuSig allows multiple parties to control a single private key with their respective keys. The shared private key does not appear as an on-chain multi-signature transaction, leaving a minimal on-chain footprint. MuSig1 is an advancement based on Schnorr signatures, offering significant enhancements compared to traditional Bitcoin multi-signature schemes that rely on ECDSA.

MuSig2 (BIP-327) is an improved iteration of MuSig1 that operates as a two-round multi-signature scheme, providing superior security, efficiency, and privacy features, requiring only two rounds of communication between signers to produce a valid signature instead of three. In October, Bitcoin Core developer Andrew Chow proposed two new BIPs focused on MuSig2 development. The proposed BIPs are MuSig2-PSBT and MuSig2-descriptors.

Why it matters: MuSig2-PSBT is a standard track BIP that will enable private multi-signature schemes for partially signed Bitcoin transactions (PSBT). This advancement will benefit not only other users but also Ordinals and BRC-20 users and markets that use PSBT to facilitate asset sales. Integrating MuSig2 into PSBT overall will help obscure these types of on-chain transactions by making multi-signature transactions appear like single-signature transactions. The second BIP, MuSig2-descriptors, is an informational BIP that will assist wallet providers in implementing MuSig2-PSBT by providing a method for describing transaction outputs controlled by MuSig2 wallets. Notably, the BIP for MuSig2-PSBT is still under preliminary review and requires a BIP number assignment, so this BIP will not be ready for delivery in the short term (6-12 months).

BIP-324 -- V2 Transmission

What is BIP-324: BIP-324 is a privacy-focused improvement to the Bitcoin P2P layer. This layer facilitates data transmission between Bitcoin nodes. The Bitcoin P2P layer acts as a highway for data, although most of the data is in plaintext and vulnerable to various types of attacks. Potential attackers may adopt passive methods, such as monitoring node activity to gather information about IP addresses and transaction sources, or they may employ active techniques, including intercepting and tampering with the data transmitted between nodes. These attacks are known as MITM (man-in-the-middle) attacks. BIP-324, previously known as BIP-151, advocates for encrypting data on the Bitcoin P2P layer to enhance resistance against passive and active attacks on Bitcoin.

Why it matters: The latest version of Bitcoin Core (v0.26) adds support for version 2 encrypted P2P transmission specified in BIP-324. This feature is disabled by default but allows anyone to enable it and benefit from the additional protection. This is an important step for privacy at the Bitcoin P2P level, marking the first activation of a BIP on Bitcoin since 2021 (although BIP-324 does not require a soft fork).