We Choose The Hard Way - Developing The Bitcoin L2 Ecosystem

Introducing the Bitcoin Layer 2 Open-source Library

This technical research report was authored by Zorrot from the ScaleBit Research Group

The Bitcoin development ecosystem has always been somewhat opaque, especially when compared to other public blockchains like Ethereum, which boasts an abundance of tutorials, numerous case studies, and sophisticated IDEs and development testing tools. The Bitcoin ecosystem seems to lack a unified development consensus.

This situation isn’t due to a shortage of developers or their capabilities but because developing on Bitcoin inherently presents more difficulties than on other public blockchains. For smart contracts primarily developed through scripting, developers don’t need an in-depth understanding of blockchain mechanics to produce high-quality projects. In contrast, Bitcoin development often requires dealing with client-side and transaction-level code and operations, demanding that developers have extensive experience with Bitcoin’s concepts and architecture to develop effectively.

These factors contribute to making developments on Bitcoin particularly “unfriendly” – lacking unified solutions, integrated testing environments, or ample tutorials and code references. While many expert developers within the Bitcoin community focus intensely on their projects and push through challenging issues (e.g., recent advancements like covenants and BitVM), there’s a tendency to overlook the more common development needs across the community.

However, this situation is gradually improving with the growth of Bitcoin’s Layer 2 (L2) ecosystem. Many projects have recognized that for the Bitcoin ecosystem to unleash its full potential, beyond the efficiency and operation of funds, it’s crucial for developers to smoothly join the ecosystem and contribute their ideas. We are encouraged to see many projects, such as Stacks, QED, Unisat, OKX, etc., introducing trendy functionalities and their corresponding libraries post the Taproot upgrade, such as BRC20 and BitIDE.

ScaleBit as a security company, we focus more on code-level examples and have noticed that the Taproot upgrade introduced a new concept to Bitcoin scripts, namely Tapscript. Traditional Bitcoin development was more focused on constructing transactions and validating data; meanwhile, development on Bitcoin L2 inevitably involves working with Tapscript construction and unlocking. Therefore, we aim to practice in this field, bringing an understanding and convenience of this new concept to more developers.

A Taproot Address-based Multisig Asset Bridge

Asset bridges are an unavoidable challenge for the vast majority of BTC Layer 2 (L2) projects. Essentially, an asset bridge is a special Bitcoin address. When users wish to transfer their assets to L2, they are actually depositing their assets into this address. Following the confirmation of the deposit transaction, the project will issue corresponding tokens on L2 for the user. Conversely, when withdrawing, users destroy the tokens on L2, and the project controls the address on L1 to return the corresponding assets to the user.

Before the Taproot upgrade, Bitcoin used the OP_CHECKMULTISIGVERIFY opcode to control a multisig address, but it could only support up to 16 addresses. Hence, asset bridges often employ Multi-Party Computation (MPC) solutions for management. This approach is secure when the custodian is reliable.

However, many Bitcoin developers have criticized this method as overly centralized and prone to instances of “inside jobs.” After the Taproot upgrade, Bitcoin introduced schnorr signatures, significantly improving verification efficiency. Further, with the new OP_CHECKSIGADD opcode, L1 can now support the verification of up to 999 multisig signatures. This means that the holders of the keys can be highly dispersed and interact in a decentralized manner, making trustless asset bridges possible.

As many developers and project teams eagerly prepare to dive in, they encounter a significant obstacle - the lack of comprehensive code instructing them to build a cross-chain bridge. Despite the Taproot upgrade being implemented nearly 4 years ago, spawning many open-source repositories for constructing Taproot addresses and Tapscript, these resources need to be more cohesive. While separate projects offer proofs of concept for various Taproot technologies - for instance, building a PSBT in Project A, constructing a Taproot address in Project B, and operating the Musig protocol in Project C - integrating them into a cohesive whole proves challenging.

Not Only Library But Integrated Demo

As previously mentioned, Bitcoin development demands in-depth knowledge of all its intricacies. This creates a unique dilemma: although all the necessary code components are openly available, assembling them into a functional project remains daunting; and frustratingly, no tutorials guide you through this process. Experienced Bitcoin developers might claim the solution is straightforward—simply combine these components. Yet, many find themselves stuck without clear guidance.

It’s not your fault; this is an inherent issue within the Bitcoin ecosystem: a lack of comprehensive code, complete testing environments, and full-fledged examples. Completeness is fundamental to understanding code and module operations.

Recognizing the silent majority struggling with basic issues and the absence of exemplary cases for learning and further development, we decided to address this problem. We’ve developed a complete L1 solution for a Taproot multisig cross-chain bridge based on Nodejs. This library encapsulates various useful functions and modules we’ve found practical. Moreover, it serves as a comprehensive demo, including how to build a testing environment, use a block explorer for visualization, send RPC transactions to interact with Bitcoin nodes, and of course, establish a complete Taproot asset bridge.

Our Implementation

The principles of the Taproot asset bridge have been well-documented in BIP-0341 and numerous excellent articles. We particularly recommend the Taproot-Workshop, an open-source repository by Bitcoin Optech that includes a wealth of information and code regarding Taproot’s key technologies. Typically, constructing a Tapscript script involves several steps:

Generate a key pair and tweak the keys.
Create scripts that may be used within the address, often consisting of multiple scripts, hence referred to as a Taptree.
Construct a Taproot address using both the key pair and scripts.
Handle the transfer logic and unlocking scripts.
Use RPC commands to build and send transactions.

The key aspect lies in the construction of the Taptree. Currently, three different schemes are generally used for constructing multisig scripts: single-leaf nodes, multiple-leaf nodes, and aggregated signature schemes. Although all these schemes can meet the requirements for constructing multisig addresses, they each have their advantages and disadvantages. The simplest approach is the single-leaf node scheme, which involves repeatedly adding the OP_CHECKSIGADD opcode to the script to construct a single multisig unlocking script as illustrated below:

This scheme, while straightforward, effectively accomplishes the task and is easy to understand. Hence, we have implemented this approach and recommend its use in less complex situations (e.g., 3-out-of-2 threshold signatures). However, it has a significant drawback: it substantially exposes privacy. Since it employs a single leaf node, all public keys are displayed on the chain along with the transaction. This visibility allows anyone to see the composition of the script’s signatories - which, while not directly affecting its security, could potentially lead to vulnerabilities through social engineering tactics.

To address the privacy concerns of the single-leaf node scheme, a second solution was developed. For an m-of-n threshold signature, each possible m-of-m combination of signatures is represented as a leaf node within the Taptree, culminating in a large Taptree. This method offers better privacy protection since unlocking a Taproot address only utilizes one leaf node, exposing only the m-of-m public keys and thus better safeguarding the remaining keys.

While this multiple-leaf node scheme enhances privacy and effectiveness, it presents two main challenges. First, its construction complexity is significantly higher than the single-leaf node approach, requiring the creation of numerous branches and a method for tracking each unique unlocking script. Fortunately, this issue can be mitigated through our provided bridge builder module, which simplifies building such script trees by only requiring the necessary keys and threshold values to generate a complete and accurate Taptree, with each branch numbered for easy tracking and unlocking.

Our library enables rapid completion of the multiple-leaf multisig scheme. However, a second problem arises when there are too many public keys, as calculating all unlocking combinations results in an excessively branched Taptree, leading to high computational costs. Therefore, it’s not the ultimate solution: A better approach exists in the form of aggregated signature schemes. With Taproot’s support for schnorr aggregated signatures, it’s entirely feasible to aggregate keys and signatures off-chain using protocols like Musig and Musig2. Nodes can construct an asset bridge with a single public key and unlock it with a single signature, providing an ideal balance of privacy and efficiency.

This method has its concerns, particularly with potential off-chain leakage risks if participants do not strictly follow protocols like Musig. Yet, aside from this, it offers unparalleled privacy for Taproot addresses. We’ve integrated Musig2, encapsulating it into easily understandable functions, allowing developers to immediately apply Musig to their asset bridges.

This approach has significant advantages, with one concern being the entire aggregation process occurs off-chain, posing potential leakage risks if users do not strictly adhere to protocols like Musig. However, it provides ultimate privacy for Taproot addresses. Building it is challenging since Musig and aggregated signatures are fundamentally different from Tapscript, and the Musig protocol is complex, involving multi-round communications between nodes. Fortunately, we have integrated Musig2 and encapsulated it into functions that are easy to operate and understand, allowing developers to immediately implement Musig in their asset bridges.

Additionally, an “escape hatch” is necessary for when the L2 network fails, providing a way for users to withdraw their assets back to their accounts. This can be achieved with a script that includes the OP_CHECKSEQUENCEVERIFY opcode, serving as a branch of the Taptree.

With all these elements, we are confident you can build any Tapscript script needed, including multi-sig wallets, asset bridges, and conditional payment addresses, among others. You can also quickly learn through our provided demo and debug your code in a comprehensive testing and visualization environment.

Build Bitcoin L2 Together

After completing these tasks, we were far from satisfied. Instead, we turned our attention to the Bitcoin L2 ecosystem, noting the existence of many intriguing scripts, such as inscriptions, runes, the Atomical protocol, and more. Our next steps will involve exploring additional scripts and their best practices. Concurrently, we plan to open-source our achievements, following thorough vetting for security and compliance. Moreover, we invite you to join us in this endeavor, contributing to the development of Tapscript to make the Bitcoin L2 ecosystem more developer-friendly.

About ScaleBit

ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like blockchain interoperability and zero-knowledge proofs, we provide meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise. Our mission is to provide security solutions for Web3 Mass Adoption and make security accessible for all.

Requests a quote