Galaxy: Latest Bitcoin Technical Developments in Q4 2023
TechFlow Selected TechFlow Selected
Galaxy: Latest Bitcoin Technical Developments in Q4 2023
Bitcoin's ecosystem saw significant technical developments in October and November 2023, including the release of the BitVM whitepaper and the launch of Taproot Assets.
Navigating Web3 tides with focused insightsSource: Galaxy
Translation: Lynn, Mars Finance
This report highlights key technical developments in the Bitcoin ecosystem during October and November 2023. We cover the following seven topics:
-
Release of the BitVM whitepaper
-
Taproot Assets mainnet launch
-
OP_CAT proposal
-
OP_TXHASH proposal
-
Lightning Timeout Trees proposal
-
MuSig2-PSBT proposal
-
BIP-324 proposal
Introduction
In November 2023, on-chain Bitcoin transaction volume increased by 62% month-over-month (MoM), primarily driven by Ordinals and BRC-20. The total dollar value transferred on Bitcoin exceeded $147 billion in November, a significant 21% increase from the previous month. This growth is largely attributable to BTC's price appreciation in USD terms, but spot market BTC trading volume also rose 18% MoM, while futures trading volume declined slightly by 1%.
Since the rise of Ordinals in January 2023, the Bitcoin development community has seen a notable resurgence in exploring alternative token protocols, scaling solutions, and smart contract implementations. Overall, the post-Ordinals Bitcoin development landscape has expanded significantly and is working harder than it has in years to enhance both on-chain and off-chain application use cases. This report focuses on seven major developments and proposals for Bitcoin in Q4 2023. These advancements highlight a renewed commitment among Bitcoin ecosystem developers to expand Bitcoin’s utility and support broader use cases.
BitVM
What it is: BitVM enables expressive smart contracts on Bitcoin. Due to the nature of Bitcoin’s design, executing smart contracts directly on Bitcoin is slow and expensive. With BitVM, smart contracts are executed off-chain, and participants only resort to using code on Bitcoin when disputes arise, leveraging Bitcoin’s native scripting system to enforce contract rules. BitVM operates similarly to optimistic rollups used in the Ethereum ecosystem, incorporating elements such as fraud proofs and challenge-response protocols.
The structure of BitVM contracts works by having two parties agree on a sequence of pre-signed transactions leading to an outcome. Similar to optimistic rollups, these types of contracts assume you don’t cheat, but if you do, the honest party has an opportunity to challenge the cheater. Crucially, BitVM does not require upgrading Bitcoin’s Layer 1 blockchain. BitVM uses only well-understood primitives already present in Bitcoin, such as hash locks, time locks, and Tapscript.
Why it matters: Bitcoin is often criticized for lacking innovation and its inability to directly compete with more general-purpose Layer 1s like Ethereum and Solana. Bitcoin has always prioritized layered scalability over expanding the base layer’s functionality. The Lightning Network is an example of a high-performance, payment-focused network built atop Bitcoin. With BitVM, more complex computations can be executed on layers built atop Bitcoin, continuing the strategy of scaling via layers rather than upgrading the core protocol.
Taproot Assets Mainnet Launch
What it is: 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. Taproot Assets (formerly known as TARO) enables developers to issue, send, and receive Bitcoin-based assets. Lightning Labs has long proposed and worked toward methods of issuing assets on the Lightning Network, and this mainnet release marks a significant milestone.
Taproot Assets are created by embedding arbitrary data into a Taproot script (Tapscript). Tapscript is a scripting language that enables various new transaction types introduced in the Taproot upgrade. Taproot Assets use Taptree, a Merkle tree data structure, to store token data within Taproot outputs. All Taproot Assets are issued on-chain via standard Taproot transactions at the base layer. Although Taproot Assets are issued and settled on Bitcoin’s base layer, Lightning Labs specifically designed them to be compatible with the Lightning Network. The functionality of Taproot Assets is enabled through an enhanced version of Partially Signed Bitcoin Transactions (PSBT), also used for Ordinals and BRC-20 transactions, called virtual PSBT (vPSBT). This mechanism allows trustless, peer-to-peer trading of Taproot Assets over the Lightning Network.
Why it matters: Taproot Assets provide an efficient method for creating fungible tokens on Bitcoin. In April 2023, Ordinals developers introduced a new fungible token standard called BRC-20. This token standard uses inscription technology to allow users to attach arbitrary data to individual sats (the smallest unit of Bitcoin). The emergence of BRC-20 demonstrated demand for fungible tokens on Bitcoin, although the BRC-20 standard is notoriously inefficient. With Taproot Assets officially launched on October 18, 2023, there is now an opportunity for fungible tokens on Bitcoin to thrive on the Lightning Network. Benefits include reduced network congestion on Bitcoin’s base chain. Overall, Taproot Assets represent a promising solution for introducing fungible tokens on Bitcoin and bringing more users into 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, suggesting the reintroduction of the OP_CAT opcode into Bitcoin’s scripting language. This opcode would allow developers to construct and evaluate Merkle trees and other hash-based data structures within Tapscript—the native scripting language enabling new transaction types under the Taproot upgrade.
OP_CAT is not a new idea. Bitcoin developers previously removed the opcode from Bitcoin’s script because it allowed the creation of data-intensive scripts that could potentially burden Bitcoin nodes with excessive computational demands. However, due to the Taproot upgrade introducing size limits on Taproot scripts (520 bytes), OP_CAT could now serve as a useful tool for developers without imposing excessive computational overhead on node operators.
Why it matters: Before the November 2021 Taproot upgrade, Bitcoin relied entirely on Bitcoin Script for programmability. The Taproot upgrade significantly expanded Bitcoin’s transaction programmability. Re-enabling OP_CAT would remove prior restrictions and further enhance Bitcoin’s programmability, unlocking new opportunities for diverse use cases.
OP_TXHASH Proposal Draft
What it is: Bitcoin Core developer Steven Roose proposed a BIP focusing on the benefits of implementing two new opcodes—OP_TXHASH and OP_CHECKTXHASHVERIFY—into Bitcoin’s scripting language. The OP_TXHASH opcode would directly compete with two major covenant proposals currently under discussion in the Bitcoin community: BIP-118 and BIP-119. Covenants are predetermined spending conditions imposed on Bitcoin transactions. For example, a user could create a covenant ensuring that BTC sent to an address can only be spent by the recipient after 200 blocks.
Why it matters: Enabling covenants could become a driving force behind Bitcoin’s next major upgrade. TXHASH is one of the leading BIPs that developers hope to activate within 1–2 years. TXHASH allows customization of transaction fields within Bitcoin transactions, offering a more flexible way to express covenants. This flexibility enables users to adjust transaction fees—a critical feature when dealing with uncertain and volatile fee rates—which other covenant proposals like BIP-119 do not support. Additionally, when combined with other BIPs such as OP_CAT, OP_TXHASH could replicate the functionality of BIP-118, another prominent covenant proposal currently being evaluated by the Bitcoin community.
Lightning Timeout Trees
What it is: The Lightning Network is Bitcoin’s primary Layer 2 solution and has seen widespread adoption over recent years. A key barrier to further adoption lies in the requirement for users 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 during periods of high on-chain transaction fees.
A long-explored solution is the concept of “channel factories,” which would allow multiple users to join the Lightning Network through a single Bitcoin transaction. Implementing channel factories could significantly lower the entry barrier to the Lightning Network by reducing the cost of opening Lightning channels across multiple users.
Why it matters: While the theory behind channel factories has existed for years, Bitcoin’s scripting limitations have made it difficult for anyone to devise a compelling and secure implementation. However, John Law’s “timeout trees” proposal may have found a solution using covenants—spending conditions placed 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 covenants, the coordinator is restricted from spending users’ BTC without proper authorization. While the proposal is not without limitations, it represents the first channel factory architecture leveraging covenants—a powerful mechanism for adding spending conditions on BTC that is gaining popularity among Bitcoin developers for various use cases, including BTC custody (see BIP-345).
Updated MuSig2 Proposal
What it is: MuSig2 is an upgraded version of MuSig1, a Bitcoin multisignature scheme that enhances privacy and scalability. MuSig allows multiple parties to jointly control a single private key using their respective keys. The shared private key does not appear on-chain as a multisignature transaction, leaving minimal on-chain footprint. MuSig1 was an advancement based on Schnorr signatures, offering significant improvements over traditional Bitcoin multisignature schemes that rely on ECDSA.
MuSig2 (BIP-327) is an improved iteration of MuSig1, operating as a two-round multisignature scheme that provides superior security, efficiency, and privacy features—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 advancing MuSig2: MuSig2-PSBT and MuSig2-descriptors.
Why it matters: MuSig2-PSBT, a standards-track BIP, will enable private multisignature schemes within Partially Signed Bitcoin Transactions (PSBT). This advancement will benefit not only general users but also Ordinals and BRC-20 users and marketplaces that use PSBTs to facilitate asset sales. Integrating MuSig2 into PSBT will help conceal these types of on-chain transactions by making multisignature transactions appear indistinguishable from single-signature ones. The second BIP, MuSig2-descriptors, is an informational BIP that will assist wallet providers in implementing MuSig2-PSBT by offering a method to describe transaction outputs controlled via MuSig2 wallets. Notably, the MuSig2-PSBT BIP is still under preliminary review and awaits BIP number assignment; therefore, it will not be ready for deployment in the short term (6–12 months).
BIP-324 – V2 Transport
What it is: BIP-324 is a privacy-focused improvement to Bitcoin’s peer-to-peer (P2P) layer, which facilitates data transmission between Bitcoin nodes. This layer acts as a data highway for Bitcoin, though most data is transmitted in plaintext, making it vulnerable to various attacks. Potential attackers may use passive methods, such as monitoring node activity to collect information about IP addresses and transaction origins, or active techniques including intercepting, censoring, or tampering with node-transmitted data. These are known as MITM (Man-in-the-Middle) attacks. BIP-324, formerly known as BIP-151, advocates encrypting data on Bitcoin’s P2P layer to strengthen resistance against both passive and active attacks.
Why it matters: The latest version of Bitcoin Core (v0.26) added support for version 2 encrypted P2P transport as specified in BIP-324. This feature is disabled by default but can be manually enabled, allowing users to benefit from additional protection. This marks a significant step forward for privacy at the Bitcoin P2P level and represents the first activation of a BIP on Bitcoin since 2021 (although BIP-324 does not require a soft fork).
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@galaxyhq
