November’s online transaction volume surges by 62%, taking stock of the seven major advancements in Bitcoin technology

Bitcoin Technology Advances Lead to 62% Surge in Online Transactions for November

Source/Galaxy

Compiled by/Nick

Abstract

This article focuses on important technical developments that occurred in the Bitcoin ecosystem in October and November 2023. It covers the following seven topics:

• Japanese social media giant LINE sinks further into Web3, is it for fundraising or revolution?
• Ethereum Core Developers Latest Meeting Summary Goerli Shadow Fork to Take Place Before End of Year, Cancun/Deneb Upgrade to be Tested
• Glassnode Bitcoin pacing back and forth, encountering resistance in its upward movement

BitVM whitepaper release

Taproot Assets launched 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 saw a 62% increase compared to the previous month, primarily due to the recovery of Ordinals and BRC-20. The total dollar value of Bitcoin transferred in November exceeded $147 billion, representing a significant 21% growth from the previous month. This growth can be attributed to the increase in BTC price, but the spot market trading volume for BTC also increased by 18%, while the futures trading volume decreased by 1% respectively.

Since the rise of Ordinals in January 2023, the Bitcoin development community has experienced significant recovery in exploring new 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 article will focus on the 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 scope of Bitcoin applications and support new use cases.

Technical Developments

BitVM

Definition of BitVM: BitVM enables expressive smart contracts on Bitcoin. Given the design considerations of Bitcoin, executing smart contracts directly on Bitcoin is both slow and costly. With BitVM, smart contracts are executed off-chain, and participants only resort to on-chain Bitcoin code in case of disputes, utilizing Bitcoin’s native scripting to enforce contract rules. BitVM operates similar to optimistic rollups used in the Ethereum ecosystem, featuring elements like fraud proofs and challenge-response protocols.

The structure of BitVM contracts is to reach an agreement between two parties on the pre-signed transaction sequence that leads to an event. Similar to optimistic rollups, in case of a cheater, the honest party has an opportunity to challenge the cheater. Importantly, BitVM does not require upgrading Bitcoin’s Layer 1 blockchain. BitVM solely employs primitives already understood within Bitcoin, such as hash locks, time locks, and Tapscript.

Importance: Bitcoin is often criticized for its lack of innovation and ability to directly compete with more versatile Layer 1 solutions like Ethereum and Solana. Bitcoin has always prioritized layer scaling instead of trying to expand the functionality of its base layer. The Lightning Network is an example of a high-performance network built on top of Bitcoin, with a focus on payments. With BitVM, more complex computations can be executed on layers built on top of Bitcoin, continuing to scale Bitcoin through layering instead of upgrading the core protocol.

Taproot Assets Go Live on Mainnet

Definition of Taproot Assets: Lightning Labs is a blockchain development company that builds software for the Bitcoin Lightning Network. They have 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 Bitcoin-based assets. Over the 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 Taproot scripts (Tapscript). Tapscript is a scripting language that enables various new transaction types during the Taproot upgrade process. Taproot Assets store token data in Taproot outputs using Taptree, a Merkle tree data structure. All Taproot Assets are issued on-chain via standard Taproot transactions at the base layer. While 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 enables trustless peer-to-peer trading of Taproot Assets on the Lightning Network.

Importance: Taproot Assets will provide an efficient way to create fungible tokens on Bitcoin. In April 2023, the developers of Ordinals introduced a new fungible token standard called BRC-20. This token standard uses inscription technology, allowing users to attach arbitrary data to individual satoshis (the smallest unit of Bitcoin). The emergence of BRC-20 demonstrates the demand for NFTs on Bitcoin, despite the known 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 are a promising solution to introduce NFTs on Bitcoin and onboard more users to the Lightning Network.

OP_CAT Proposal

Definition of OP_CAT Proposal: Bitcoin researcher Ethan Heilman submitted a Bitcoin Improvement Proposal (BIP) to the Bitcoin-Dev mailing list, suggesting the addition of the OP_CAT opcode to the Bitcoin scripting language. This opcode would allow developers to construct and evaluate Merkle trees and other hash data structures in Tapscript. Tapscript is 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 the opcode from Bitcoin script because it could construct data-intensive scripts, increasing the computational burden on Bitcoin nodes. However, with the Taproot upgrade introducing a size limit for Taproot scripts (520 bytes), OP_CAT will become a useful tool for developers and will not impose excessive computational costs on node operators.

Importance: Prior to 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 Proposal

Definition of OP_TXHASH Proposal: Bitcoin Core developer Steven Roose proposed a BIP that focuses 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 contract proposals in Bitcoin today, BIP-118 and BIP-119. Contracts are predefined spending conditions imposed on Bitcoin transactions. For example, a user can create a contract to ensure that the recipient of a transaction can only spend BTC sent to their address after 200 blocks.

Importance: Enabling contracts could become a driving force for the next major upgrade in Bitcoin. TXHASH is one of the leading BIPs that developers hope to activate within 1-2 years. TXHASH allows for customizable transaction fields within Bitcoin transactions, providing a more adaptive way of expressing contracts. This flexibility allows users to adjust transaction fees, which is a key feature when dealing with uncertain and fluctuating rates, while other contract proposals like BIP-119 do not support this. 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

Definition of Lightning Timeout Trees Proposal: The Lightning Network is Bitcoin’s primary Layer 2 protocol that has seen widespread adoption in recent years. One 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 limitation restricts the number of users who can migrate their assets off-chain, particularly when 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 between multiple users.

Importance: While the theory for 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 Law’s “Lightning Timeout Trees” proposal may have found a solution using contracts, specifically spending conditions on BTC transaction outputs. The proposal introduces the concept of a coordinator (or Lightning Service Provider – LSP) who oversees the opening and closing of user channels. By using contracts, the coordinator would be restricted from spending users’ BTC without proper authorization. Although the proposal is not without limitations, it is the first channel factory architecture that utilizes contracts, a powerful mechanism for adding spending conditions on BTC, which is gaining popularity among Bitcoin developers and applicable to various use cases, including BTC custody (see BIP 345).

Updated Musig2 Proposal

Musig2 Proposal Definition: 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 private key with their respective keys. The shared private key does not appear as a multi-signature transaction on the blockchain, leaving the smallest footprint. Musig1 is an improvement based on Schnorr signatures, which has 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 operating as a two-round multi-signature scheme, generating valid signatures with only two rounds of communication among signers instead of three. In October, Bitcoin Core developer Andrew Chow proposed two new BIPs focused on the development of Musig2. The proposed BIPs are MuSig2-PSBT and MuSig2-Descriptors.

Importance: MuSig2-PSBT is a standard track BIP that enables 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 hide these types of on-chain transactions by making multi-signature transactions appear as 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 to describe transaction outputs controlled by MuSig2 wallets. It is worth noting that the BIP for MuSig2-PSBT is still under initial review and requires BIP assignments, therefore it will not be ready for deployment in the short term (6-12 months).

BIP-324 – V2 Transport

BIP-324 Definition: BIP-324 is an improvement for privacy on the Bitcoin P2P layer, which facilitates data transfer between Bitcoin nodes. The Bitcoin P2P layer acts as a highway for data, although most of the data is unencrypted, making it vulnerable 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 the data being 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 against passive and active attacks on Bitcoin.

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

We will continue to update Blocking; if you have any questions or suggestions, please contact us!