Original source: Galaxy

Original compilation: Lynn, Mars Finance

This note highlights important technological developments taking place in the Bitcoin ecosystem in October and November 2023. We cover the following seven topics:

• BitVM white paper released

• Taproot Assets mainnet online

• OP_CAT proposal

• OP_TXHASH proposal

• Lightning Timeout Trees Proposal

• MuSig 2-PSBT Proposal

• BIP-324 Proposal

introduce

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

Bitcoin 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-ordinal 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 the fourth quarter of 2023. These developments highlight a renewed commitment from Bitcoin ecosystem developers to expand Bitcoin’s adoption and support use cases.

BitVM

What it is: BitVM supports express smart contracts on Bitcoin. Given the nature of Bitcoins design, executing smart contracts directly on Bitcoin is slow and expensive. With BitVM, smart contracts are executed off-chain, and participants can only directly use the code on Bitcoin in the event of a dispute, utilizing Bitcoins native scripts to execute the contract rules. BitVM operates similarly to the optimistic aggregation used in the Ethereum ecosystem, containing elements such as fraud proofs and challenge response protocols.

The structure of a BitVM contract works by allowing two parties to agree on a sequence of pre-signed transactions that lead to an event. Similar to optimistic aggregation, these types of contracts assume you dont cheat, but if you do, the honest party has a chance to challenge the cheater. Crucially, BitVM does not require upgrades to Bitcoin’s layer 1 blockchain. BitVM only uses primitives that are 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 ability to compete directly with other more general Layer 1s like Ethereum and Solana. Bitcoin has always prioritized layer-by-layer scaling rather than trying to extend the functionality of the base layer. The Lightning Network is an example of a high-performance payment-centric network built on top of Bitcoin. With BitVM, more complex calculations can be performed on layers built on top of Bitcoin, continuing to scale Bitcoin through layers rather than upgrading the core protocol.

Taproot Assets mainnet online

What it is: Lightning Labs, a blockchain development company building software for Bitcoin’s Lightning Network, has released a new protocol for issuing stablecoins and other assets on the Lightning Network. Taproot Assets (officially 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 an important milestone.

Taproot Assets are created by entering arbitrary data into a Taproot script (Tapscript). Tapscript is a scripting language used to enable various new transaction types in Taproot upgrades. Taproot Assets uses 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. Taproot Assets functionality is enabled by an improved version of Partially Signed Bitcoin Transactions (PSBT), which is also used to trade 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 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. The token standard uses inscription technology to allow users to attach arbitrary data to a single sat (the smallest unit of Bitcoin). The emergence of BRC-20 proves that there is a demand for fungible tokens on Bitcoin, despite the notorious inefficiency of the BRC-20 standard. With the official launch of Taproot Assets on October 18, 2023, fungible tokens on Bitcoin have the opportunity to flourish on the Lightning Network. The benefits of having fungible tokens on the Lightning Network include reducing network congestion on Bitcoin’s native chain. Overall, Taproot Assets is a promising solution for introducing fungible tokens on Bitcoin and getting more users on board the Lightning Network.

OP_CAT proposal

What it is: Bitcoin researcher Ethan Heilman submitted a Bitcoin Improvement Proposal (BIP) to the Bitcoin-Dev mailing list, proposing to add the OP_CAT opcode to Bitcoins scripting language. This opcode will enable developers to build and evaluate Merkle trees and other hash data structures in Tapscript, the native scripting language used to enable new transaction types in the Taproot upgrade. .

OP_CAT is not a new idea. Bitcoin developers previously removed opcodes from Bitcoin scripts because it allowed the construction of data-intensive scripts that could tax Bitcoin nodes 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 restrictions, creating new opportunities for different use cases.

OP_TXHASH draft proposal

What it is: Bitcoin Core developer Steven Roose proposed a BIP focusing on the benefits of implementing two new opcodes for the Bitcoin scripting language, OP_TXHASH and OP_CHECKTXHASHVERIFY. The OP_TXHASH opcode will directly compete with BIP-118 and BIP-119, the two main contract proposals for Bitcoin today. Covenants are predetermined spending conditions imposed on Bitcoin transactions. For example, a user can create a contract that ensures that the recipient of a transaction 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 within 1-2 years. TXHASH allows customizing transaction fields in Bitcoin transactions, providing a more adaptable way of expressing contracts. This flexibility enables users to adjust transaction fees, a key feature when dealing with uncertain and fluctuating rates, which is not supported by other compact proposals such as BIP-119. Additionally, OP_TXHASH has the potential to replicate the functionality of BIP-118 when combined with other BIPs such as OP_CAT, another leading contract proposal currently being evaluated by the Bitcoin community.

Lightning Timeout Trees 

What it is: The Lightning Network is Bitcoin’s primary layer 2 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 when using the Lightning Network in order to move funds off-chain. This restriction limits the number of users who can move assets off-chain, especially if on-chain transaction fees are high.

A long-explored solution is a concept called channel factories. It 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 matters: Although the theory of Bitcoin has been around for years, Bitcoin’s 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 “Timeout Tree” proposal may have found a solution using contracts, i.e. spending conditions on BTC transaction outputs. The 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, coordinators will 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 leverage contracts, a powerful mechanism for adding spending conditions on BTC that is increasingly popular among Bitcoin developers and is suitable for applications including BTC Various use cases including hosting (see). BIP 345

Updated Musig 2 proposal

What it is: MuSig 2 is an upgraded version of MuSig 1, a Bitcoin multi-signature scheme 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. MuSig 1 is an advancement based on Schnorr signatures that offers significant enhancements compared to Bitcoins traditional multi-signature scheme that relies on ECDSA.

MuSig 2 (BIP-327) is an improved iteration of MuSig 1, 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 wheels. In October, Bitcoin Core developer Andrew Chow proposed two new BIPs focused on MuSig 2 development. The proposed BIPs are MuSig 2-PSBT and MuSig 2-Descriptor.

Why it matters: MuSig 2-PSBT, a Standard Orbit 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 MuSig 2 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, MuSig 2-descriptors, is an informational BIP that will help wallet providers implement MuSig 2-PSBT through MuSig 2 wallets by providing a way to describe controlled transaction outputs. It is worth noting that the BIP for MuSig 2-PSBT is still under preliminary review and needs to be assigned a BIP number, so the BIP will not be ready to ship in the short term (6-12 months).

BIP-324 – V2 Transport

What it is: BIP-324 is privacy-oriented improvements 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 most of the data is clear text information 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 tampering activities such as intercepting and censoring data transmitted by nodes. These attacks are called MITM (man-in-the-middle) attacks. BIP-324, formerly known as BIP-151, advocates encrypting data on Bitcoin’s P2P layer to increase resistance to passive and active attacks on Bitcoin.

Importance: The latest version of Bitcoin Core (v 0.26) added support for version 2 encrypted P2P transfers specified in BIP-324. This feature is disabled by default, but allows anyone to turn it on and benefit from additional protection. This is a major step towards P2P-level privacy for Bitcoin and marks the first time BIP has been activated on Bitcoin since 2021 (although BIP-324 does not require a soft fork).