From Bitcoin Script to LNP/BP protocol, one article reveals RGB’s ambitions

Co-authored: Infinitas; Waterdrip Capital; viaBTC Capital

Technology Provider: Li Ning; Hong Shuning

After more than ten years of vigorous development, Web3 technology has emerged with innovations at various levels. On the premise of not compromising its decentralization and security, Bitcoin continues to improve its privacy protection capabilities, and implements a series of advanced features such as Schnorr signatures and Taproot, laying the foundation for subsequent technological innovations. At the same time, the evolution of smart contracts on the chain represented by Ethereum has given birth to the golden age of blockchain applications (such as DeFi), bringing two rounds of bull markets. However, since 2022, innovation in the Web3 industry has suddenly lost its direction, and blockchain technology has never been able to get rid of the shackles of the impossible triangle, resulting in the failure of large-scale applications of blockchain. So, have we hit the boundaries of technology? Are there hidden deeper unknown areas waiting for us to explore? Perhaps, it is in the process of these explorations that the second-layer protocol RGB of Bitcoin is waiting for the opportunity and gradually matures to challenge the limitations of existing technologies and show a dazzling brilliance.

Bitcoin: Establishing its place as the currency layer

The biggest difference between Web3 and Web2 lies in its built-in economic system, and any economic system uses currency as its base layer, and above the currency layer is the protocol layer and application layer. The currency of Web3 is called Cryptocurrency (CryptoCurrency), which is issued through the blockchain.

Due to the following key factors, Bitcoin is recognized as the most secure and stable cryptocurrency, and the value of Bitcoin has been globally recognized:

First, the Bitcoin network covers the world, with more than 10,000 full nodes that work together to verify and record transactions. This decentralized nature makes it difficult for attackers to tamper with transaction history. Second, Bitcoin uses powerful hash computing power as a proof-of-work mechanism, which is the cornerstone of network security. In block verification and mining, expending large amounts of computing power makes it difficult for attackers to control the network. Additionally, Bitcoin’s consensus rules have not undergone major changes in history, and this stability helps maintain the consistency and security of the network. Bitcoin’s consensus rules are less susceptible to radical changes than other blockchain projects. The Bitcoin community is extremely concerned about the security and stability of the network, focusing on the security of the core protocol. Modifications to the core protocol are carefully discussed and tested to ensure network stability. In short, Bitcoin is recognized as the most secure and stable among many blockchains. With its excellent decentralization, consensus mechanism, stability and community attention, Bitcoin has become the first choice for the Web3 currency layer.

Bitcoin script that guarantees security and simplicity

Bitcoin plays an important role in the basic currency layer of the Web3 world. During the gradual evolution of the core protocol after careful discussion and testing, the development of its scripting system deserves special attention. The original intention of the Bitcoin script language is to ensure security and avoid potential risks, so the design intentionally limits its functions while maintaining the simplicity and security of a similar chip instruction set. Bitcoin Script is a stack-based execution language based on Reverse Polish Notation. Such scripts are designed to execute on limited hardware.

In the Bitcoin mainstream node code, developers have imposed some restrictions on the types of scripts that can be executed, and only allow certain types of transactions called standard scripts to be executed. The most important of these is the P 2 SH (Pay to Script Hash) transaction, which actually allows any Bitcoin script to be executed, which makes it possible to execute scripts with certain complex functions on Bitcoin. The Lightning Network, for example, has become the de facto standard for small, high-frequency Bitcoin payments.

With the introduction of Proposal Schnorr signatures and the Taproot soft fork upgrade, Bitcoin has taken a major step, marking a major milestone. This enables Bitcoin to better support the development of Layer 2 protocols, further enhancing its role in the future Web3 world.

Focus on Schnorr signatures and Taproot

Behind Schnorr signatures and Taproot lies a series of technological innovations that create new opportunities for Bitcoin. First, Taproot introduces more flexible payment channels, enabling multiple transaction types to be executed on-chain in a more privacy-preserving manner. By hiding complex multi-signature scripts in a single script, Taproot makes complex transactions look like regular single-party payments, improving privacy and security. The introduction of Schnorr signatures makes transactions on the Bitcoin network more compact, reduces transaction fees, improves scalability, and closely matches the efficient transaction requirements of the Web3 world.

These two innovations not only improve the performance and privacy of Bitcoin, but also bring more innovation possibilities to the ecosystem. More efficient scripting and signature technology supports cross-chain operations, lightning network expansion and complex smart contracts. This refocuses Bitcoin on the core of Web3, paving the way for building a safer and more efficient decentralized finance and application ecosystem.

Impact of Schnorr signatures

In the initial design stage of the Bitcoin protocol, Satoshi Nakamoto needed to comprehensively consider various factors of the signature algorithm, including signature length, open source, patent issues, security verification time, and performance. In the end, he chose the Elliptic Curve Digital Signature Algorithm (ECDSA), and chose a specific elliptic curve secp 256 k 1 , based on the performance and security of this algorithm. However, in addition to ECDSA, there are other digital signature algorithms that meet the criteria, notably Schnorr Signature. The reason why Satoshi Nakamoto did not adopt this algorithm previously may be that Schnorr Signatures patent had not expired in the year of Bitcoins birth. German mathematician and cryptographer Claus-Peter Schnorr applied for and received a related patent in 1990, so the open source community could not adopt the technology while the patent was valid. Otherwise, Satoshi Nakamoto may have adopted this signature mechanism in the original version of the Bitcoin protocol.

Compared with ECDSA, Schnorr Signature is more in line with the essence of Bitcoin signature. Not only is the performance better, the signature length is shorter, but it also has linearity, which makes key aggregation simple and does not require special skills required for multi-signature. This linearity is easy to understand, and the keys of each party are aggregated to form a new key through a simple mechanism. There are various ways of aggregation mechanism, such as MuSig proposed by Blockstream and the newer version MuSig 2. In the MuSig 2 scheme, multiple signatures can generate an aggregated public key from their respective private keys, and then jointly generate a valid signature for the public key, optimizing the number of interaction rounds from the original three rounds (MuSig) to only two rounds.

So from the perspective of a 2-3 multi-signature transaction, the original traditional method requires three public keys plus two signatures to initiate a transaction.

In the Schnorr Signature scenario, on-chain transactions only require an aggregated public key and a signature, which reduces a lot of transaction bytes, which also reduces the transfer cost.

Innovations in Taproot scripts

Taproot is an innovative Bitcoin scripting structure designed to dictate how Taproot-type transaction addresses are used and parsed. Taproot was originally inspired by Bitcoin developers research on Merkle Abstract Syntax Trees (MAST), so Taproot can be seen as a special implementation of MAST. Through Taproot, Bitcoin UTXO with multiple different branch scripts can only expose one of the branches when spending, and the rest of the branches will never appear on the blockchain, thus greatly improving the privacy and efficiency of transactions. This technology makes the use of complex scripts more convenient and efficient under the premise of greater security.

In the Bitcoin protocol, the lock script (output script) specifies the conditions for receiving bitcoin (UTXO), while the unlock script (input script) specifies the way to use bitcoin (UTXO). The former can be regarded as a The lock, and the latter is the corresponding key. In the Segregated Witness (SegWit) upgrade, Bitcoin’s scripting rules have been comprehensively upgraded. Two new script rules are introduced, P 2 WPKH (Pay to Witness Public Key Hash) and P 2 WSH (Pay to Witness Script Hash), which allow addresses starting with bc 1 to apply. P 2 WPKH is mainly used for regular addresses, while P 2 WSH is often used for multi-signature addresses.

In the Segregated Witness upgrade, the script also introduces the concept of version numbers, and the previous Segregated Witness rules were marked as V 0 version. However, Taproot has further upgraded the isolated witness framework, and the version number has been updated to V1, which is also in BIP 341."SegWit V1"The origin of the title. Therefore, this new set of script rules is called P 2 TR (Pay to Taproot), to correspond to P 2 WPKH and P 2 WSH.

In addition, combining Schnorr Signature and Taproot, there are many ways to build multi-signatures (multi-signatures). For example, Steve Lee, a pioneer in the Bitcoin community, introduced various methods in his speech, such as threshold signature and Musig tree (Musig Keytree).

Original speech video: https://www.youtube.com/watch?v=fDJRy6K_3yo

For example, for an exchanges hot wallet, a 2-3 multi-signature scheme can be used, involving three private keys: the exchange private key, the trusted third-party private key, and the cold wallet backup private key. In the threshold signature, multiple signers pre-build the receiving address through the MuSig mechanism. In the actual transaction, only two signatures need to be aggregated to complete the transaction.

LNP/BP: Maturity of Bitcoin Protocol/Lightning Network Protocol

Previously, we took a deep dive into the forward-looking nature of the Bitcoin network through the introduction of Schnorr signatures and the Taproot soft fork upgrade. At the same time, as technological miracles never stop, the LNP/BP Standards Association is working quietly behind the scenes, as if a finely crafted work of art has brought more innovative possibilities to the Bitcoin ecosystem. The LNP/BP codebase covers Bitcoin Layer 2 and above standards and best practices, they do not require soft forks or hard forks at the Bitcoin blockchain level, and are consistent with those covered by the Lightning Network RFCs (BOLTs) The content is not directly related. In short, the LNP/BP standard covers everything related to Bitcoin transactions, defines the basic building blocks of layer-2 and above solutions, and describes complex use cases built on top of these blocks. This opens up possibilities for areas such as financial assets, storage, messaging, computing, secondary markets that leverage the Bitcoin security model and Bitcoin as a payment method/medium of exchange, etc.

This article will not expand on each protocol within LNP/BP in detail. Users who want to fully understand LNP/BP can visit https://github.com/LNP-BP/LNPBPs.

Here, only a few key points that will have an important impact on the future of Web3 will be introduced, such as key stage transactions in state channels, as well as some key protocols and technologies: Bi-directional channels, PTLCs, eltoo, channel factories (Channel factories), discrete log contracts (Discreet log contracts), high-frequency micropayments (high-frequency micropayments) and Sphinx, etc.

Overview of transactions in the same phase of the state channel

Funding Transactions: Funding transactions are the initial transactions used to create payment channels in the Lightning Network. It aggregates the funds of all parties to a multi-signature address as a deposit for the payment channel. Funding transactions ensure that participants have all committed a certain amount of funds before they start transacting off-chain on the payment channel. Funding transactions are the first step in creating a payment channel, ensuring the security and availability of the channel.

Partially Signed Bitcoin Transactions (PSBT, Partially Signed Bitcoin Transactions):A partially signed Bitcoin transaction is a special Bitcoin transaction format that allows multiple participants to jointly construct and sign a transaction. In the Lightning Network, PSBT can be used to create, update, and close transactions on payment channels. When the two parties of the payment channel want to conduct a transaction, they can jointly construct PSBT, and each perform partial signatures, then merge the partially signed transactions, and finally complete the transaction and submit it to the Bitcoin network. PSBT makes the transaction process of multi-party cooperation more flexible and efficient.

State-based Bitcoin transactions (BSBT, Base-Signed Bitcoin Transactions):BSBT is a transaction used to build and update channel state in the Lightning Network. It contains information about the current state of the channel and is signed by the owner of the channel. BSBT is used to record the latest status in the channel to ensure the correctness and security of transactions. When channel status changes, BSBTs are created and updated to reflect the new channel status.

The key technology of Lightning Network supporting RGB smart contracts

The Lightning Network is a layer-2 solution built on top of Bitcoin that allows users to conduct fast, low-cost transactions through one or more bidirectional channels, while maintaining the decentralization and security features of the blockchain. In the following content, we will delve into the strategy adopted by the Lightning Network in the face of complex RGB smart contract requirements. From efficiency to scalability, we will analyze the internal key technologies one by one to reveal whether the Lightning Network has the potential to support large-scale RGB smart contracts in its continuous evolution.

Bi-directional channels:As a special payment channel, it enables two participants to conduct two-way real-time interaction without executing transactions on the blockchain every time they interact. This channel can be compared to a private ledger between two people, allowing them to freely transfer and trade assets in the channel. The final state of the channel is only committed to the blockchain when the channel is closed. In the Bitcoin network, the implementation of two-way channels mainly relies on Bitcoin script. For example, Lightning Network, users can realize payment and asset transfer in the channel, and only when the channel needs to be closed, the final state of the channel will be submitted to the Bitcoin blockchain. It should be added that the core technology of the two-way payment channel of Lightning Network includes RSMC and HTLCs, which will not be introduced in detail here.

Point Time Lock Contract (PTLC):When discussing the privacy issues of HTLC (Hash Time Locked Contract), we encountered a key challenge: each hop on the entire path uses the same preimage, that is, each hop in the entire path HTLC can only be unlocked by the same preimage. Does this mean we have no other solutions? In fact, we need to solve the following problems:

Once the payment is completed, the payer (Alice) must be able to provide valid proof of payment to the payee (Bob).

Each hop in the path must be able to provide some secret value s to unlock the conditional payment sent by the previous node.

To obtain the secret value s, each hop needs to send a conditional payment that needs to be unlocked with the secret value s to the next node in the path. This secret value s can be used to find the secret value s.

While there is a simple approach of using the same secret value s for the entire path, as we do with HTLC, this is not really the only solution. In fact, the secret values ​​s and s need not be the same. The key is that as long as a node knows s, it can know s, so we can satisfy this condition when constructing the secret value. This is the core concept of PTLC (Pointlocked Timelocked Contract),

The following is an illustrated case:

Eltoo：Bitcoin and other blockchain-based systems have limitations in terms of scalability. On-chain payments require verification and storage by all network nodes, limiting overall throughput. To solve this problem, the second-layer protocol (off-chain protocol) is considered as a feasible solution. It renegotiates and shares state among a small number of participants, avoids frequent broadcast state updates to the blockchain, and reduces the burden on the network. But all second-layer protocols face a core problem, that is, how to ensure that only the latest state is committed to the blockchain.

In this context, eltoo becomes an attractive alternative protocol. It introduces state numbers, an enforceable variant of on-chain sequence numbers. This solves the old state submission problem and ensures that only the latest state is recognized and recorded on the blockchain, improving system efficiency and security. This simple yet powerful mechanism improves the viability of second-layer protocols and provides a powerful solution for the scalability of Bitcoin and other blockchains.

Discreet log contracts:While smart contracts are highly regarded in cryptocurrency systems such as Bitcoin, they have not been widely used in finance. The scalability of smart contracts and the difficulty of introducing external data are two major obstacles to implementation and application. At the same time, the privacy of the contract has always been concerned. Discreet Log Contracts (DLC) is a system that addresses scalability and privacy concerns while also attempting to minimize the need for trust in oracles that provide external data. These contracts remain discrete in nature, making it difficult for outside observers to detect the existence of the contract in transaction records. Also, these contracts rely on knowledge of discrete logarithms, which is an advantage.

SPHINX：In the Lightning Network, a path refers to the route a payer takes to send a payment to a payee through a series of payment channels. In order to enable users to relay payments through paths, the Lightning Network uses a mechanism called Source-based Onion Routing, commonly referred to as SPHINX. SPHINX is a tool used to ensure secure communications that requires payers to create multiple layers of encryption. During the message delivery process, these encryption layers are stripped one by one by intermediate nodes until the intended recipient obtains the innermost message. During the transmission process, each intermediate node only knows the nodes before and after it. With source routing, the payer is responsible for creating a payment path from its node to the payee node.

In summary, when facing complex RGB smart contract requirements, the Lightning Network can complete payment and asset transfers through two-way channels without frequent broadcasts to the blockchain. The point time lock contract (PTLC) solves the problem of using the same secret value in the payment path and improves privacy. Eltoo, as a new choice of the second-layer protocol, solves the old state submission problem by introducing state numbers. In addition, discrete logarithmic contracts (DLC) address the scalability and privacy issues of smart contracts, reducing the need for trust in oracles. Finally, SPHINX, as a source-based onion routing mechanism, ensures secure communication for large-scale applications. These innovative technologies and strategies not only enhance the performance and functionality of the Bitcoin network, but also lay the foundation for it to play an important role in the future digital financial world.

Leading the Change: Exploring the Mission of the RGB Protocol

RGB is a powerful protocol designed to combine the characteristics of Bitcoin as the underlying currency layer with the flexibility of smart contracts. Through RGB, we can create and manage various assets on the Bitcoin network, enabling wider financial and application innovation. From efficient and secure asset issuance to more complex contract logic, RGB has injected new vitality into the Bitcoin network, enabling it to play a more important role in the future digital ecology. Let’s dive into what makes RGB so exciting and its role in moving the Bitcoin network forward.

brief overview

The history of RGB has been covered in detail in several recent articles, so here is just a basic review.

In 2016, Peter Todd proposed the concepts of Single-use seal and Client-Side Validation. Inspired by these important ideas, RGB was proposed in 2018. In 2019, core developer Orlovsky started pushing RGB and working on many of the parts that would eventually make up the RGB protocol. Subsequently, the LNP/BP Association was established in Switzerland to develop guidance related to these standards. After a lot of development work, in April 2023, RGB released version v 0.10, which is the first initially available version and promises to maintain backward compatibility.

Interpreting RGB smart contracts

RGB smart contracts can be briefly summarized into two core elements: ownership and state validation. Therefore, the RGB smart contract can be viewed as a distributed network. In this network, no one has a complete view of the current state, but due to the one-time sealing technology based on Bitcoin Proof-of-Work (PoW) (possibly through the Lightning Network as an intermediary), and the same client verification rules (architecture) , which is still globally consistent (with consensus). In this system, only owners have access to the states they own, and a branch of a directed acyclic graph (DAG) of state history directly related to those owned states.

In RGB smart contracts, rights management involves the definition of specific types of operations that can only be performed by a party that owns a specific part of the smart contract state. These operations include but are not limited to asset ownership, identity ownership, asset supply and issuance rights, sub-identity creation rights, asset tailoring/destruction rights, etc.

In RGB smart contracts, user rights are enforced. The allowed entitlement types are well defined in the schema and these types are called state types because every entitlement must have some current state/value even if this is null. The initial rights are assigned by the contract issuer at the time of creation, and as the state transitions, the rights can be transferred together with the new owner (carrying new state values ​​at the same time). Ownership of rights (state) is controlled through Bitcoin scripts and one-time sealing mechanisms. The next owner of a particular right is always defined by the party currently owning that right (i.e., the state owner). Client-side validation requires that entitlement transfers must always be reverse-validated by the new owner according to validation rules.

The RGB smart contract implements rights transfer/state transition verification rules defined by Schema through two main tools: Schema structure (used to decide the distribution of rights among descendants) and easy script (used to specify the state way of evolution). For example, on the asset side, the script requires that the sum of the outputs must equal the sum of the inputs. These rules can be further restricted (rather than expanded) at creation and at each state transition. Within a specific subgraph of the state DAG, new owners can backtrack and verify these rules up to genesis. At the same time, it is worth noting that violating rights rules in the ownership branch of one smart contract will not affect the integrity of smart contracts in other branches.

In terms of the core security measures of RGB smart contracts, each entitlement (i.e. state) cannot directly access state information under other entitlements. In some cases, entitlements can use metadata to achieve shared state if desired. Both the schema and the genesis file have clear rules on whether this sharing is allowed.

RGB smart contract example:

When Web3 meets RGB

The emerging smart contract paradigm brought about by the technological innovation of RGB smart contracts gives users the ability to manage rights, providing greater flexibility from asset ownership, identity ownership to asset supply rights. In the RGB smart contract, the transfer of rights is controlled through Bitcoin script and a one-time sealing mechanism, which ensures the safe transfer of rights.

At the same time, RGB smart contracts try to solve the problem of old states by introducing the concept of state numbers. This enables the owner of rights to retrospectively verify the rules, which is expected to improve system efficiency and security, provide stronger guarantees for contract transfers and state transitions, and ensure that each transfer complies with the verification rules. Overall, RGB smart contracts bring some exciting ideas, especially in terms of scalability, privacy, and rights management for smart contracts. This kind of innovation is bound to have a positive impact on the entire Bitcoin network and bring more possibilities to the future Web3 field.

Unlocking Infinity: A Whole New World Like TCP/IP

In the Bitcoin network, the gradual implementation of proposals such as Schnorr signatures and Taproot, as well as the continuous maturity of the second layer protocol with LNP/BP and RGB as the core, paint an exciting future for us. In this context, the development path of the standard Web3 has become clearer, building a new pattern based on more complex decentralized technologies and cryptography. The Infinitas technical team believes that this pattern will be based on the LNP/BP protocol, presenting a layered structure, similar to the TCP/IP architecture, which organically integrates the three key layers of currency layer, protocol layer and application layer.

Scalability and efficiency improvements:The LNP/BP protocol can introduce more second-layer solutions to the Bitcoin network, such as the Lightning Network, thereby increasing transaction speed and throughput, reducing transaction costs, and promoting more efficient capital flows.

Privacy and security enhancements:The development of RGB smart contracts will achieve a higher degree of privacy and security in the second-layer protocol, allowing users to conduct transactions and contract execution in a more private environment, protecting personal information and asset security.

Scalability and efficiency improvements:The LNP/BP protocol can introduce more second-layer solutions to the Bitcoin network, such as the Lightning Network, thereby increasing transaction speed and throughput, reducing transaction costs, and promoting more efficient capital flows.

Privacy and security enhancements:The development of RGB smart contracts will achieve a higher degree of privacy and security in the second-layer protocol, allowing users to conduct transactions and contract execution in a more private environment, protecting personal information and asset security.

Richer functions:RGB smart contracts introduce more smart contract functions into the Bitcoin ecosystem, support operations such as asset ownership, identity management, and asset issuance, and promote the development of more types of financial and non-financial applications.

Reduce blockchain burden:The development of the second-layer protocol can transfer most transactions from the main chain to the second layer, reducing the burden on the main chain and enabling the main chain to focus more on security and core functions.

Developer innovation:The development of the LNP/BP protocol and RGB has created a broader space for developers to innovate, build more diverse applications and services, and promote the diversification and prosperity of the Web3 ecosystem.

History of TCP/IP

To better help you understand this new landscape, lets take a quick look back at the traditional domain of computer networking. In this area, the evolution of the TCP/IP protocol stack plays a crucial role. It has experienced a gradual evolution from the initial fragmentation to complexity, and finally to the process of standardization and ease of use. In the early stages from late 1960s to early 1970s, various protocols and communication methods were tried and developed by different research institutes. In 1969, the US Defense Advanced Research Projects Agency Network (ARPANET) was created, using the NCP protocol for communication. Subsequently, in 1972, Vint Cerf and Bob Kahn proposed the TCP protocol, and ARPANET began to adopt the TCP protocol in 1973, marking the beginning of the formation of the TCP/IP protocol stack. By 1977, the standardization phase began to emerge, with Vint Cerf and Jon Postel publishing RFC 791, which defined the IP v4 protocol. Subsequently, core protocols such as TCP and IP were standardized one after another, forming todays basic framework. And in 1989, Tim Berners-Lee invented the World Wide Web, introducing HTTP and HTML to make the Internet easier to use and more visual.

compelling narrative

The correct development path of Web3 is based on more complex decentralization technology and cryptography. This development path is based on the development and evolution of protocols such as LNP/BP and RGB. Similar to the development of the TCP/IP protocol stack (the core of Web2), Web3 must also go through several key stages and require more great contributions. Although this road is long, it is necessary. As a series of innovative solutions for Bitcoin-based smart contracts, Infinitas will be deeply expanded on the basis of protocols such as LNP/BP and RGB, and will realize payment universal addresses, Contractum language smart contract development environment, and schema. Immutability, and core technologies such as multi-level secure storage based on RGB client verification data (Proofs, etc.). Pursue the perfection of every detail to make the writing of smart contracts more efficient and reliable. The integration of these technologies constitutes the distributed Infinitas platform, which provides a solid foundation for the development of large-scale Web3 applications.

The Bright Future of Web3 Development

Through the in-depth discussion of this article, we have seen a development path similar to the TCP/IP protocol, and have reason to believe that with the continuous maturity of the LNP/BP protocol and the RGB protocol, peoples infinite imagination of the Metaverse is becoming a reality, Web3 The world will become richer and more diverse, and we will soon see:

• Decentralized finance will be adopted on a large scale;

• The emergence of chain games: high-performance competitive, strategy, casual and other games;

• Diversified social applications on the chain: media, dating, video, etc.;

• Deep integration with AI to prevent AI from doing evil;

• Integration with wearable devices and sensors.

The RGB protocol allows us to stand at a new starting point and witness a future with unlimited possibilities like Bitcoin. As a participant and witness of this process, we look forward to the more open, inclusive and innovative The future of Web3.