On-chain trading volume surged by 62% in November, taking stock of seven important developments in BTC technology

Source/galaxy

Compiler/Nick

Summary

This article highlights the important technological developments that took place in the BTC ecosystem in October and November 2023. The following seven topics are covered:

BitVM white paper released

Taproot Assets is launched on the mainnet

OP_CAT proposal

OP_TXHASH proposals

Lightning Timeout Trees proposal

MuSig2-PSBT proposal

BIP-324 Proposal

Introduction

In November 2023, the number of on-chain transactions on BTC increased by 62% month-on-month, mainly due to the resurgence of Ordinals and BRC-20. The total value of dollars transferred BTC November exceeded $147 billion, a significant increase of 21% from the previous month. This increase was largely due to higher prices in BTC, but BTC volume in the spot market also increased by 18% QoQ, while futures volume decreased by 1% QoQ, respectively.

Since the rise of Ordinals in January 2023, the BTC development community has seen a significant resurgence in exploring new fungible token protocols, scaling solutions, and smart contract implementations. Overall, the post-Ordinals BTC 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 article will highlight seven key developments and recommendations for the Q4 2023 BTC. These developments highlight the new commitment of BTC ecosystem developers to expand the reach of BTC applications and support use cases.

Technological development

BitVM

BitVM Definition: BitVM implements expressive smart contracts on BTC. Given the BTC design, executing smart contracts directly on BTC is slow and expensive. With BitVM, smart contracts are executed off-chain, and participants can only use the code on the BTC directly in the event of a dispute, utilizing BTC native scripts to enforce contract rules. BitVM operates similarly to the optimistic rollups used in the ETH Fang ecosystem, with elements such as fraud proofs and challenge-response protocols.

The BitVM contract is structured in such a way that two parties agree on a pre-signed sequence of transactions that lead to the event. Similar to optimistic rollups, if there is a cheater, the honest party has the opportunity to challenge the cheater. Crucially, BitVM does not need to upgrade BTC Layer 1 blockchain. BitVM only uses primitives that are already understood in the BTC, such as hashlocks, timelocks, and taps.

Importance: BTC are often criticized for their lack of innovation and ability to compete directly with other, more versatile Layer 1s like ETH and Solana. BTC always prioritize tiered scaling rather than trying to extend the capabilities of the base layer. The Lightning Network is an example of a high-performance, payment-centric network built on BTC. With BitVM, more complex calculations can be performed on layers built on top of BTC, allowing you to continue to scale BTC through tiering instead of upgrading core protocols.

Taproot Assets Launches on Mainnet

Taproot Assets Definition: Lightning Labs, a blockchain development company that builds software for the BTC 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 BTC-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 significant milestone.

Taproot Assets are created by inputting arbitrary data into a Taproot script (Tap). Tap is a scripting language that enables a variety of new transaction types during the Taproot upgrade process. The Taproot asset uses Taptree, a Merkle tree data structure, to store token data in the Taproot output. All Taproot assets are issued on-chain through standard Taproot transactions at the base layer. Although Taproot assets are issued and settled on BTC base layer, Lightning Labs specifically designed Taproot assets to be compatible with the Lightning Network. The functionality of the Taproot asset is achieved through an improved version of the Partially Signed BTC Transaction (PSBT), which is also used to trade Ordinals and BRC-20, known as Virtual Partially Signed BTC Transaction (vPSBT). The mechanism is 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 efficient way to create fungible tokens on BTC. In April 2023, Ordinals developers created a new fungible token standard called BRC-20. The token standard uses inscription technology that allows users to attach arbitrary data to a single SAT, the smallest unit of BTC. The emergence of BRC-20 is a testament to the need for NFTs on BTC, although the BRC-20 standard is notoriously inefficient. With the official launch of Taproot Assets on October 18, 2023, NFTs on BTC have a chance to thrive on the Lightning Network. The benefits of owning NFTs on the Lightning Network include reducing network congestion on BTC native chains. Overall, Taproot Assets is a promising solution to introduce NFTs on BTC and get more users on the Lightning Network.

OP_CAT Proposal

OP_CAT Proposal Definition: BTC researcher Ethan Heilman submitted a BTC Improvement Proposal (BIP) to the Bitcoin-Dev mailing list, suggesting the addition of OP_CAT opcodes to BTC scripting languages. The opcode will enable developers to build and evaluate Merkle trees and other hash data structures in Tap, a native scripting language used to enable new transaction types during the Taproot upgrade process.

OP_CAT is not a new idea. BTC developers previously removed opcodes from BTC scripts because it could build data-intensive scripts, increasing the burden on BTC node computing resources. However, since the Taproot upgrade introduces a size limit (520 bytes) for Taproot scripts, OP_CAT will be a useful tool for developers and will not incur excessive computational overhead for node operators.

Why it matters: Prior to the November 2021 Taproot upgrade, BTC relied entirely on BTC scripts for programmability. However, the Taproot upgrade significantly expands BTC’s transaction programmability capabilities. Enabling OP_CAT will further enhance the programmability of BTC by removing previously imposed limitations, creating new opportunities for different use cases.

OP_TXHASH Proposal

OP_TXHASH Proposal Definition: Steven Roose, BTC core developer, proposed a BIP focused on the benefits of implementing two new opcodes, OP_TXHASH and OP_CHECKTXHASHVERIFY for BTC scripting languages. The OP_TXHASH opcode will compete directly with the two major contract proposals BTC today, BIP-118 and BIP-119. A contract is a predetermined spending condition imposed on BTC transaction. For example, a user can create a contract that ensures that the recipient of a transaction can only spend the BTC sent to their address after 200 blocks.

Why it matters: Enabling the contract could be the motivation for BTC next major upgrade. TXHASH IS ONE OF THE LEADING BIPS THAT DEVELOPERS WANT TO ACTIVATE IN 1-2 YEARS. TXHASH PROVIDES A MORE ADAPTABLE REPRESENTATION OF CONTRACTS BY ALLOWING THE TRANSACTION FIELDS TO BE CUSTOMIZED WITHIN BTC TRANSACTIONS. This flexibility enables users to adjust transaction fees, a key feature when dealing with uncertain and fluctuating rates, which is not supported by other covenant proposals such as BIP-119. In addition, when combined with other BIPs such as OP_CAT, OP_TXHASH has the potential to replicate the functionality of BIP-118, another leading compact proposal currently being evaluated by the BTC community.

Lightning Timeout Trees Proposal

Lightning Timeout Trees Proposal Definition: The Lightning Network is the primary Layer 2 of BTC and has seen widespread adoption over the past few years. A key hurdle to further adoption is that users need to initiate at least one on-chain BTC transaction when using the Lightning Network in order to transfer funds off-chain. This limit limits the number of users who can migrate assets off-chain, especially if on-chain transaction fees are high.

One long-explored solution is a concept called a “channel factory” that allows multiple users to join the LN in a single BTC transaction. The implementation of a channel factory has the potential to significantly lower the barrier to entry for the Lightning Network by reducing the cost of opening a Lightning channel between multiple users.

Importance: Although BTC theory has been around for years, its scripting limitations make it difficult for anyone to come up with a convincing and secure solution to enable a channel factory. However, John Law’s proposal for “Lightning Timeout Trees” may have found a solution to the use of contracts (i.e., the spending conditions for the output of BTC transactions). 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 the deed, the coordinator will be restricted from spending the user’s BTC without proper authorization. While the proposal is not without its limitations, it is the first channel factory architecture to take advantage of contracts, a powerful mechanism for adding spending conditions on BTC that is growing in popularity among BTC developers for a variety of use cases, including BTC hosting (see BIP 345).

Updated Musig2 Proposal

MuSig2 Proposal Definition: MuSig2 is an upgraded version of MuSig1, a multisig scheme on BTC that enables privacy and scalability. MuSig allows multiple parties to control a private key with their own key. Shared private keys don’t look like on-chain multisig transactions, leaving a minimal on-chain footprint. MuSig1 is an advancement based on Schnorr signatures that offers significant enhancements over BTC traditional multisig schemes that rely on ECDSA.

MuSig2 (BIP-327) is an improved iteration of MuSig1 that provides superior security, efficiency, and privacy features by operating as a two-round multisig scheme, requiring only two rounds of communication between signers to generate valid signatures 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-Descriptor.

Why it matters: MuSig2-PSBT is a standard orbital BIP that will enable a private multisig scheme for partially signed BTC transactions (PSBTs). This advancement will benefit Ordinals and BRC-20 users and marketplaces, among other users, who use PSBT to boost the sale of assets. Integrating MuSig2 into PSBT in general will help hide these types of on-chain transactions by making them look like single-signature transactions. The second BIP, MuSig2-deiors, is an informational BIP that will help wallet providers implement MuSig2-PSBT by providing a way to describe the output of transactions controlled by the MuSig2 wallet. It is important to note that the BIP of MuSig2-PSBT is still under preliminary review and needs to be assigned a BIP number, therefore, this BIP will not be ready for shipment in the short term (6-12 months).

BIP-324 – V2 Transport

BIP-324 Definition: BIP-324 is an improvement on privacy at the BTC P2P layer, which facilitates the transfer of data between BTC nodes on the BTC. BTC P2P layer acts as a highway for data, although much of the data is plaintext and vulnerable to multiple types of attacks. Potential attackers may employ passive methods, such as monitoring node activity to gather information about IP addresses and the origin of transactions, or they may employ proactive techniques, including tampering activities such as intercepting data transmitted by nodes and censoring them. These attacks are known as MITM (man-in-the-middle) attacks. BIP-324, formerly known as BIP-151, advocates encryption of data on BTC P2P layer to enhance resistance to BTC passive and active attacks.

Importance: The latest version of Bitcoin core (v0.26) adds support for version 2 encrypted P2P transfers specified in BIP-324. The feature is disabled by default, but anyone is allowed to turn it on and benefit from additional protection. This is a significant step BTC P2P-level privacy, marking the first time BIP has been activated on BTC since 2021 (although BIP-324 does not require a soft fork).