Galaxy: Bitcoin Technical Development in Q4 2023 from Seven Major Themes

Translation: Song Xue, Golden Finance

Abstract:

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

BitVM white paper release
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 on-chain transaction volume of Bitcoin increased by 62% compared to the previous month, mainly due to the recovery of Ordinals and BRC-20. The total value of Bitcoin transfers in November exceeded $147 billion, a significant increase of 21% from the previous month. This growth is mainly attributed to the appreciation of BTC price in USD, but the spot market BTC trading volume also increased by 18% month-on-month, while the futures trading volume decreased by 1% respectively.

Bitcoin monthly data indicators

Since the rise of Ordinals in January 2023, the Bitcoin development community has seen a significant resurgence in exploring new alternative token protocols, scaling solutions, and smart contract implementations. Overall, the post-Ordinals Bitcoin development landscape has expanded and is working harder than ever to enhance on-chain and off-chain application use cases. This article will focus on the seven major developments and proposals for Bitcoin in the fourth quarter of 2023. These developments highlight the new commitment of Bitcoin ecosystem developers to expand the range of Bitcoin applications and support use cases.

Technical Developments

BitVM

What is BitVM: BitVM enables expressive smart contracts on Bitcoin. Given the nature of Bitcoin's design, executing smart contracts directly on Bitcoin is both slow and expensive. With BitVM, smart contracts are executed off-chain, and participants can only use the code on Bitcoin directly in case of disputes, utilizing Bitcoin's native scripts to enforce contract rules. The operation of BitVM is similar to optimistic rollups used in the Ethereum ecosystem, including elements such as fraud proofs and challenge-response protocols.

The structure of BitVM contracts is to reach consensus between two parties on pre-signed transaction sequences that lead to events. Similar to optimistic rollups, these types of contracts assume that you do not cheat, but if you do, the honest party has the opportunity to challenge the cheater. Importantly, BitVM does not require upgrading Bitcoin's Layer 1 blockchain. BitVM only uses primitives already understood in Bitcoin, such as hash locks, time locks, and Tapscript.

Why it's important: Bitcoin has often been criticized for its lack of innovation and its ability to directly compete with more general Layer 1 solutions like Ethereum and Solana. Bitcoin has always prioritized layered scaling rather than 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, centered around payments. With BitVM, more complex computations can be executed on layers built on top of Bitcoin, continuing to scale Bitcoin through layering rather than upgrading the core protocol.

Taproot Assets Launch on 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 (previously known as TARO) enables developers to issue, send, and receive assets based on Bitcoin. For years, Lightning Labs has been proposing and working on ways to issue assets on the Lightning Network, and the mainnet release is a significant milestone.

Taproot Assets are created by inputting arbitrary data into the main root script (Tapscript). Tapscript is a scripting language used to enable various new transaction types in the Taproot upgrade process. Taproot assets store token data in Taproot outputs using Taptree, a Merkle tree data structure. All Taproot assets are issued and settled 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), also used for trading Ordinals and BRC-20, called virtual partially signed Bitcoin transactions (vPSBT). This mechanism is a way to trade Taproot assets in a trustless, peer-to-peer manner on the Lightning Network.

Why it's important: Taproot Assets will provide an effective way to create alternative tokens on Bitcoin. In April 2023, Ordinals developers created a new alternative token standard called BRC-20. This token standard uses encryption 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, despite the inefficiency of the BRC-20 standard. 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 owning NFTs on the Lightning Network include reducing network congestion on the Bitcoin native chain.

Overall, Taproot Assets is a promising solution that can introduce NFTs on Bitcoin and attract more users to 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 script 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 in the Taproot upgrade process.

OP_CAT is not a new idea. Bitcoin developers previously removed opcodes from the Bitcoin script because it could build data-intensive scripts, increasing the computational burden on Bitcoin nodes. However, due to the size limit of Taproot scripts (520 bytes) introduced by the Taproot upgrade, OP_CAT will be a useful tool for developers and will not impose excessive computational overhead on node operators.

Why it's important: Before the Taproot upgrade in November 2021, Bitcoin relied entirely on Bitcoin scripts to achieve programmability. However, the Taproot upgrade significantly expanded Bitcoin's transaction programmability capabilities. Enabling OP_CAT will eliminate previous restrictions, further enhancing Bitcoin's programmability and creating new opportunities for different use cases.

Draft Proposal for OP_TXHASH

OP_TXHASH Proposal Draft

What is the OP_TXHASH proposal: Bitcoin core developer Steven Roose has proposed a BIP focusing on the benefits of implementing two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY, in the Bitcoin script language. The OP_TXHASH opcode will directly compete with two major covenant proposals for Bitcoin today, BIP-118 and BIP-119. Covenants are pre-determined spending conditions imposed on Bitcoin transactions. For example, a user can create a covenant to ensure that the recipient of a transaction can only spend the BTC sent to their address after 200 blocks.

Why it's important: Enabling covenants could be a driving force for the next major upgrade of Bitcoin. TXHASH is one of the leading BIPs, with developers hoping to activate it within 1-2 years. TXHASH allows for custom transaction fields in Bitcoin transactions, providing a more adaptable way to express covenants. This flexibility allows users to adjust transaction fees, a key feature when dealing with uncertain and fluctuating fees, which is not supported by other covenant proposals such as BIP-119. Additionally, when combined with other BIPs like OP_CAT, OP_TXHASH has the potential to replicate the functionality of BIP-118, another leading covenant proposal currently being evaluated by the Bitcoin community.

Lightning Timeout Trees Proposal

What is the Lightning Timeout Trees proposal: The Lightning Network is the primary Layer 2 solution for Bitcoin, widely adopted over the past few years. A key barrier to further adoption is that users need to initiate at least one on-chain Bitcoin transaction when using the Lightning Network to move funds off-chain. This limitation restricts 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," 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 barrier to entry for the Lightning Network by reducing the cost of opening Lightning channels between multiple users.

Why it's important: While the theory of Bitcoin has existed for years, its script limitations have made it difficult for anyone to come up with a convincing and secure solution to enable channel factories. However, John Lo's "Lightning Timeout Trees" proposal may have found a solution using covenants (i.e., spending conditions on BTC transaction outputs). The proposal introduces the concept of a coordinator (or Lightning Service Provider - LSP), who will oversee the opening and closing of user channels. By using covenants, 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 utilize covenants, a powerful mechanism for adding spending conditions on BTC that is 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 upgrade to MuSig1, a multi-signature scheme on Bitcoin that achieves privacy and scalability. MuSig allows multiple parties to control a private key with their respective keys. The shared private key does not look like a multi-signature transaction on-chain, leaving the smallest on-chain footprint. MuSig1 is an advancement based on Schnorr signatures, offering significant enhancements compared to traditional multi-signature schemes on Bitcoin that rely on ECDSA.

MuSig2 (BIP-327) is an improved iteration of MuSig1, providing superior security, efficiency, and privacy features by running as a two-round multi-signature scheme, requiring only two rounds of communication between signers to generate 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's important: MuSig2-PSBT is a standard track BIP that will enable private multi-signature schemes for partially signed Bitcoin transactions (PSBT). This advancement will benefit Ordinals and BRC-20 users and markets, among others, who use PSBT to facilitate asset sales. Integrating MuSig2 into PSBT overall will 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 method to describe transaction outputs controlled by MuSig2 wallets. It is worth noting that the BIP for MuSig2-PSBT is still in preliminary review and requires assignment of a BIP number, so the BIP will not be ready for deployment in the short term (6-12 months).

BIP-324 – V2 Transport

What is BIP-324: BIP-324 is a privacy-focused improvement for the Bitcoin P2P layer. This layer on Bitcoin facilitates data transmission between Bitcoin nodes. The Bitcoin P2P layer acts as a high-speed highway for data, although most of the data is plaintext information, susceptible to various types of attacks. Potential attackers may employ passive methods, such as monitoring node activity to gather information about IP addresses and transaction sources, or active techniques, including intercepting and tampering with data transmitted by 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 to passive and active attacks on Bitcoin.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。