The tripartite agreement will give rise to many Dapps in the fields of Socialfi, GameFi, and DeFi in the future, bringing a new wave of heat to the BTC ecosystem.

Authors: Zhejiang University Blockchain Association, BiHelix, ScaleBit & BTC Security Lab

Intro: Why BTC L2

The explosive growth of the Mingwen ecosystem in 2023 has rapidly raised the priority of BTC scalability issues. Various colored coins (Colored Coin - a method of endowing Bitcoin with additional attributes or meanings on the Bitcoin blockchain by attaching additional information, such as BRC20) have caused congestion in native Bitcoin transactions. BTC L2, as a key solution to this problem, will become a key narrative in 2024. This article will take you deep into understanding RGB, BitVM, and the potential giant BTC L2 solutions based on the Lightning Network, Nostr.

RGB Protocol

What is RGB

RGB is a scalable and confidential smart contract protocol for Bitcoin and the Lightning Network, developed by the LNP/BP standard association. It adopts the concept of private and common ownership and is a Turing-complete, trustless distributed computing form that does not require the introduction of tokens for non-block decentralized protocols. It is important to note that RGB has no network or blockchain; it is a client-side verification technology and a partially stateful smart contract system.

RGB Protocol Development History

RGB Protocol History

RGB was initially conceived by Giacomo Zucco from BHB Network in 2016 as a "non-blockchain-based asset system." In the same year, 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 Maxim Orlovsky began to promote RGB and participated in the vast majority of RGB protocol code development and underlying standard design. Maxim Orlovsky and Giacomo Zucco jointly established the LNP/BP standard association (https://www.lnp-bp.org) to promote RGB from conceptual birth to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA. After a lot of development work, in April 2023, RGB released version V0.10, the first stable and usable version. In January 2024, the core developers of RGB stated that they would release version V0.11 as early as possible in the first half of the year.

Latest Developments in RGB Protocol

The new features of RGB V0.10 have been detailed in other research reports. However, V0.11 has not been officially released yet. Here are some of the latest developments from developers and the community:

• Support for L-BTC will be added soon

• Interoperability and cross-chain bridges between RGB assets and Liquid assets will be updated

However, RGB V0.11 will be incompatible with V0.10, leading to a high migration cost for current projects. Due to slow development progress, many projects are currently waiting for the release of V0.11.

Design Principles and Operation Principles of RGB

RGB smart contracts use client-side validation, meaning that all data is stored outside of Bitcoin transactions, i.e., Bitcoin blockchain or Lightning channel states. This allows the system to run on the Lightning Network without the need to make any changes to the BTC mainnet or Lightning Network protocol. This lays the foundation for the protocol's scalability and privacy.

RGB uses single-use seals defined on Bitcoin UTXO, which provides the ability for any party with a history of smart contract states to verify their uniqueness. In other words, RGB utilizes Bitcoin scripts to implement its security model as well as the definition of ownership and access rights.

RGB is a directed acyclic graph (DAG) of state transitions, where contracts are completely isolated from each other, and no one knows of their existence except for the contract owner (or parties to whom the owner discloses contract information).

A directed acyclic graph (DAG) is a special type of graph structure that can be used to vividly explain complex systems or relationships. In the context of a DAG, each edge can be imagined as a one-way street in a city, representing the "directed" concept. Assuming that in these roads, no matter how you drive, you cannot return to the starting point to form a closed loop, this means "acyclic." The same applies to a DAG, where there is no sequence of nodes that allows you to start from one node, pass through a series of edges, and return to the same node.

Applying this concept to the RGB system, we can view each contract as a node in the graph, and the relationships between contracts (such as ownership transfers) as directed edges. This structure ensures that the relationships between contracts are clear, orderly, and do not form closed loops, meaning that a contract does not directly or indirectly affect itself.

This design ensures that the commitments in state transitions are unique and tamper-proof, preventing double spending and achieving effective and consistent state transitions.

In-depth Understanding of RGB Contracts

After understanding the basic principles of RGB architecture, let's look at the contract part. In the current world of smart contracts, creators of smart contracts are required to organize or execute the development of smart contract code themselves. In the design philosophy of RGB, this is considered a bad practice that can lead to higher contract code vulnerabilities and multiple hacker attacks. Therefore, RGB aims to reduce the risk of vulnerabilities and audit requirements in development and introduces the concept of "contract schema." The "contract schema" is the actual code of the smart contract, which issuers can use as a "contract template" without having to encode or audit custom code written by a random outsourcer.

Flexible Scalability and Interoperability

RGB contracts are defined in a declarative manner, rather than an imperative programming manner. This means that the logic of the contract is not defined by a series of commands or steps, but by a set of rules that describe its behavior and state transitions, forming a directed acyclic graph (DAG) of state changes. The key to the schema is local state operations. Operations in RGB contracts are local, not global. Each node (or state) has its own rules and is only responsible for its own state transitions. This is different from global algorithms on platforms like Ethereum, which require each state to follow the same algorithm. This feature makes RGB flexible and scalable, while also ensuring good interoperability.

Simple Smart Contract Writing

The Schema defines the types of global and owned states, seals, and metadata allowed in state transitions. RGB uses the Contractum language to write RGB Schemas and AluVM (Arithmetic Logic Unit Virtual Machine), simplifying the writing of RGB smart contracts. AluVM is based on a register design and does not provide random memory access, making it suitable for smart contracts, remote code execution, distributed and edge computing, and providing a foundation for various advanced smart contract use cases.

How RGB Ensures Security and Privacy

From the Design of RGB Itself

• Privacy without global broadcasting: As mentioned earlier, RGB's client-side validation means that the validation process occurs only between directly involved peers, rather than the entire network. This non-global broadcasting method enhances privacy and censorship resistance, as the details of contract states are only visible to relevant participants, and miners cannot see transaction details.

• The privacy of data in the sandbox environment: On the other hand, RGB stores all operation data in a stash. Since RGB is not based on a blockchain, the storage is not replicated to other peer nodes. Locally controlled storage reduces the risk of external attacks and data leaks, ensuring data privacy. RGB is a computing platform that isolates each program ("smart contract") in its sandbox environment, providing better scalability and security than blockchain-based platforms.

• Similarly, off-chain data implies the risk of loss.

• In addition to verification and storage, the invoice system also ensures security and privacy. Contract operations in RGB are conducted by creating invoices, which can contain multiple contract operation requests. By allowing users to explicitly specify and verify contract operations, accuracy and security of operations are improved. Additionally, the invoice system supports private transmission of contract operation requests between users, enhancing transaction privacy. State transitions are executed through invoices and specific commands, such as token transfers.

From the perspective of interacting with BTC

• RGB's design is highly tied to UTXO. During the interaction with the BTC mainnet, users create off-chain contracts to issue RGB assets and allocate them to Bitcoin's UTXO, similar to the Lightning Network. Subsequently, asset transfers, contract interactions, and verification are conducted off-chain in the manner described above.

• RGB benefits from the improved multisignature, adapter-based signature protocol, and Point Time Lock Contract (PTLC) brought by Schnorr signatures, but its benefits are purely indirect based on Bitcoin's benefits. There is no content requiring signatures internally in RGB (hence Schnorr has not made any changes internally), and it does not use Bitcoin scripts (hence new Tapscript is of no use).

BTC Security Lab, jointly initiated and established by ScaleBit, is a dedicated BTC security laboratory that is committed to researching the latest developments in the RGB protocol, aiming to protect its contract security, jointly promote the increasingly updated and strengthened RGB protocol, and build the infrastructure of the BTC ecosystem.

Overview of RGB Ecosystem Projects

1. BiHelix

Website: https://www.bihelix.net/

BiHelix is an optimized node-based Bitcoin ecosystem infrastructure built on the native Bitcoin blockchain, combined with the RGB protocol and the Lightning Network. It aims to make it easier for developers to use, increase the use cases of Bitcoin, and address the scalability and Turing incompleteness challenges faced by the Bitcoin blockchain. It aims to create a more fair decentralized encrypted world for miners, validators, node service providers, exchanges, and users. As the first infrastructure built on the RGB protocol, BiHelix will create the next generation of large-scale Bitcoin application scenarios. The project is currently not interactive and is in the development stage, so stay tuned.

Project Features

1. Low user threshold

Using the SLR (Security-Lightning-RGB) protocol, RGB and the Lightning Network are repackaged, introducing innovative solutions from Lightning nodes to achieve global universal payments.

2. High reliability and scalability

Adopting a mature cloud service architecture, fully utilizing the features of rust-lightning to support the functionality of channel factories, efficiently managing channels, and creating channels in batches.

3. Security and privacy protection

Transmit and store state data off-chain, use technologies such as recursive zero-knowledge proofs to randomize multi-party payments and path selection, thereby achieving privacy protection.

4. Developer-friendly

Provides comprehensive development tools, including open-source development documentation, tools, and introduces the Schema social consensus mechanism, making it easy for developers to build applications.

2. Iris Wallet

Website: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

IRIS Wallet, the first Android wallet developed by the Bitfinex team, is dedicated to RGB integration and RGB-related tools, supporting fungible and non-fungible assets. Iris Wallet supports RGB asset operations from issuance to spending and receiving, packaging all functions in a familiar wallet application and abstracting technical details as much as possible. This is currently an experimental application and is recommended for use with small amounts of Bitcoin and low-value assets.

3. DIBA

Website: https://diba.io/

DIBA is the first NFT marketplace for smart contracts and the Lightning Network using the RGB Protocol on Bitcoin. It aims to help shape people's understanding of unhosted art assets on the Bitcoin blockchain.

4. Bitmask

Website: https://bitmask.app/

This wallet, created by DIBA, is the first NFT wallet in the RGB ecosystem, which can run in a web browser and interact with RGB contracts similar to MetaMask on Ethereum. It is currently updated frequently, awaiting the release of V0.11.

5. Pandora Prime Inc

Website: https://pandoraprime.ch/

Pandora Prime is a Swiss company headquartered in Verify Valley and is also a founding member of LNP/BP.

Pandora Prime is dedicated to pioneering Bitcoin finance using the combination of RGB smart contracts and the Lightning Network. They start with programmable assets on Bitcoin (RGBTC and CHFN), which can be extended to VISA/MasterCard level in terms of transaction throughput through the Lightning Network, while providing facilities for easy exchange of these assets. Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network, among others.

6. MyCitadel

Website: https://mycitadel.io/

MyCitadel is a brand of Pandora Prime, the first graphical user interface wallet that supports RGB, created by RGB developers in 2021. It provides cross-platform desktop wallets and iOS/iPad wallets. The mobile wallet can handle fungible RGB assets.

7. RGB Explorer

Website: https://rgbex.io/

RGB Explorer is the first browser developed by Pandora Prime to provide RGB asset registration and smart contracts. It currently supports RGB 20, RGB 21, RGB 25, and can display assets such as LNPBP, RGBTC, dCHF, and RGBEX.

8. Bitlight Labs (formerly Cosminmart)

Website: https://bitlightlabs.com/

BitlightLabs develops infrastructure based on the RGB protocol and is preparing to deploy multiple applications on the Lightning Network, including the RGB practical wallet Bitlight Wallet and the establishment of a BitcoinFi automated market maker Bitswap on the Lightning Network and RGB protocol.

10. RGB Memes & NFT

10.1 PPRGB

X: @PepeRgb20

PPRGB is currently issued on the Liquid network and will be mapped to RGB after the release of RGB V0.11 (RGB v0.11 is also working on code integration with Liquid).

10.2 MRGB Inscription

MRGB Inscription is a token based on the RGB protocol for client-side state verification and smart contract systems. The token operates in the second and third layers (off-chain) of the Bitcoin ecosystem and will provide open-source underlying protocol code, allowing all BRC20 public chains to directly use the system.

This innovation will bring tremendous potential to BRC20 public chains, including reducing gas consumption, accelerating transaction speed, and improving overall performance. By adopting the MRGB system, BRC20 public chains will be able to process transactions more efficiently and reduce user transaction costs. At the same time, the MRGB Inscription token will also serve as a consumable in the transaction process, thereby increasing the liquidity and scalability of BTC.

10.3 Single-Use-Seal

X: @Single_Use_Seal

The walrus is a 10k PFP collection, rare UDA, and token on RGB20 and RGB21, named after Peter Todd's proposal of Single Use Seal. It is currently awaiting updates to v0.11 RGB versions from Bitlight and Bitmask wallets, after which it will be issued on them.

10.4 Bitman

X: @bitmancity

Will issue 10k UDA on DIBA, possibly through a whitelist and public sale. The aim is to "spread the spirit of BTC," and the project's intention is good. The whitelist will be given to BTC ecosystem contributors, and most of the public sale proceeds will be donated to LNP/BP.

BitVM

Why BitVM?

BitVM (Bitcoin Virtual Machine) introduces a system that can verify any computation on the Bitcoin blockchain without affecting its security or changing the network. This development opens the door to complex computations (such as Turing-complete smart contracts), all of which are processed off-chain to reduce congestion on the Bitcoin blockchain.

"In short, BitVM is a computing model that can express Turing-complete contracts on the Bitcoin network." Like RGB, BitVM does not require modifications to the network's consensus rules.

On October 9, 2023, Robin Linus, co-founder of the blockchain developer ZeroSync, announced the whitepaper for BitVM. Compared to RGB, BitVM is much younger.

Architecture of BitVM

Architecture

Similar to Optimistic Rollups and the MATT proposal (Merkelize All The Things), based on fraud proofs and challenge-response protocols, it does not require changes to Bitcoin's consensus rules. BitVM proves that Bitcoin is Turing-complete in large Taptrees encoding fraud proofs.

Gate Circuit Design

Bit Value Commitment is the most basic component, allowing the committer to set the value of specific bits to "0" or "1". Any computable function can be represented as a Boolean circuit, constituting logical gate commitments. Constructed through NAND gates (universal logic gates), each gate has its own commitment. Any circuit can be expressed by combining gate commitments. Each execution step is committed in Tapleaf and combined in the same Taproot address.

BitVM utilizes Bitcoin's Taproot upgrade to achieve its functionality by creating a structure similar to a binary circuit (called a taptree). In this system, the spending conditions of each UTXO, represented by instructions in the Script script, form the basic unit of the program. These instructions generate binary outputs (0 or 1) within the Taproot address, thus constructing the entire taptree. The output of the taptree can be seen as the result of running a binary circuit, similar to an executable program. The complexity of programs that taptree can execute depends on the number and complexity of the Taproot addresses that make it up. In short, BitVM enables the ability to run more complex programs on the Bitcoin network by converting Bitcoin's Script instructions into binary operations.

Two-Party Participation

The current model is limited to two parties and cannot currently expand to more participants. Additionally, to make BitVM work properly, a large number of presigned transactions (off-chain computations) are required, making BitVM quite complex in practice and potentially inefficient.

Fraud Proofs and Challenge-Response Protocol

The prover and challenger both deposit an equal amount of BTC in a single transaction (as input) and the transaction output will contain a logical circuit. Disputes are resolved by presigning a series of transactions during the setup phase to challenge erroneous claims. BitVM is likened to Optimistic Rollups because it executes most computations off-chain and submits some of them to the chain in case of disputes.

• Optimistic Rollups are a layer 2 scaling solution that offloads computation and data storage off-chain to relieve the burden on the base layer. It then bundles multiple transactions and publishes them to the main chain.

• Optimistic Rollups assume that all transactions are valid. However, if network participants detect dishonest behavior, they can initiate fraud proofs. Fraud proofs are evidence of someone's inaccurate computation. They are generated after inspection.

Off-Chain Computation

Almost all activities on BitVM are conducted off-chain. This includes initiating computation tasks, sharing data, and verifying submitted claims. BitVM generally does not run computations on the Bitcoin blockchain. However, if there is a dispute, a small part of the dispute process does run on-chain, just enough to determine which party is dishonest.

With the above background knowledge, we can better understand the specific principles of two-party interaction in BitVM.

The two-party interaction model of BitVM involves a prover and a verifier. In this system, the prover first creates and submits a smart contract or program, then sends funds to a jointly controlled main root address. These funds are held in a 2-of-2 multisig manner. The prover also needs to share enough information with the verifier to prove that their program can produce the expected output.

The verifier's task is to run the prover's code and verify if the output meets expectations. If the output does not meet expectations, the verifier will challenge the prover. This challenge-response interaction involves off-chain data exchange and the use of presigned transactions to verify the correctness of the computation.

In the event of a computational error, the verifier can publicly prove the prover's dishonesty with an on-chain fraud proof. In the BitVM system, if the prover's response is proven to be incorrect, they will lose the bet and forfeit the funds. Conversely, if all answers are correct, the prover will retain their funds. This economic incentive mechanism aims to prevent dishonest behavior.

In the end, this interaction ensures that computation verification is only transferred to the Bitcoin blockchain in the event of a dispute, allowing the vast majority of computations to be executed off-chain. This design both maintains the efficiency of the Bitcoin network and provides the ability to run more complex programs on Bitcoin.

Security of BitVM

From an architectural design perspective, the security of BitVM is mainly based on the following aspects:

Fraud Proofs

In the event of a dispute, verifiers can challenge the prover's erroneous claims using fraud proofs. This mechanism is similar to Optimistic Rollups and does not require changes to Bitcoin's consensus rules.

Challenge-Response Protocol

BitVM uses a challenge-response protocol, where provers and verifiers presign a series of transactions during the protocol's setup phase. These transactions are used to resolve disputes when they occur.

Off-Chain Computation and On-Chain Confirmation

BitVM allows for complex computations to be executed off-chain, and relevant verification and resolution only occur on-chain in the event of a dispute. This approach reduces on-chain resource consumption while maintaining the integrity and security of the Bitcoin blockchain.

Deposit and Punishment Mechanism

If a prover makes an incorrect claim, the verifier can confiscate their deposit. This mechanism ensures that attackers always lose their deposit due to wrongful behavior.

Two-Party Contract Mechanism

This enhances privacy on BitVM and reduces transaction costs, but compared to the multi-party mechanism of EVM, its generality is somewhat reduced.

Nostr Protocol

What is the Nostr Protocol

Nostr stands for "Notes and Other Stuff Transmitted by Relays," indicating that it is a transmission protocol with relays, meaning it is not a P2P transmission protocol. According to the update records on the Github code, this project was initiated in November 2020. The protocol aims to create the simplest open protocol for a global social network resistant to censorship. It is a decentralized social protocol that allows users to create, publish, and subscribe to any type of content without being controlled or intervened by any centralized platform or institution. Nostr is inspired by Bitcoin and the Lightning Network, using similar cryptography and consensus mechanisms, as well as an event-based data structure called the Nostr Network.

Components of the Nostr Protocol

Public-Private Key Pairs

A public-private key pair is a Nostr account. Nostr accounts are not based on traditional username and password systems, but rather use a public-private key system similar to cryptocurrency. For ease of understanding, the public key can be considered as the username and the private key as the password. It is important to note that once the private key is lost, it cannot be reset like a password. The public key is prefixed with npub1, and the private key is prefixed with nsec1. It is important to securely store the public and private keys, as they cannot be recovered once lost.

Client

Nostr itself is just a protocol for sending information over the internet. Users need a client software to use the Nostr protocol. The client can be a web page, desktop software, or a mobile app. The client reads information from the relays and sends newly generated data to the relays for other clients to read. The information includes signatures, which can ensure that the data is sent by the real sender. The client uses the private key to create signatures. When using a desktop or mobile client for the first time, the private key needs to be stored in it. Through the private key, the public key can be obtained. If using a web client, it is not recommended to directly store the private key, and it is better to use a plugin to store the private key.

Relays

Relays can be understood as the backend servers of the Nostr protocol. Nostr clients send information to the relays, which may or may not store this information and broadcast it to all clients connected to them. It is important to note that relays are not static; instead, they change significantly over time. The Nostr protocol relies on relays to store and retrieve data. If a user feels that their client is slow, it may be due to slow relay connections, and they can consider adding other relays.

NIPs

Nostr Implementation Possibilities (NIPs) are used to standardize compatible relays and client software for Nostr, specifying what must, should, and can be implemented. "NIP" is a reference document outlining how the Nostr protocol works. Nostr is a decentralized protocol not monopolized by a centralized institution (such as Twitter). This means that the direction of the protocol's development depends on all participants, and suggestions for change can be made, and feedback can be provided on others' ideas. As active members of the protocol community, everyone has a say in the future development direction of the Nostr network. NIPs in the main code repository have been approved, and new ideas can be added through pull requests.

Here are some important NIPs:

• NIP-04: Message Encryption, using the secp256k1 algorithm to complete Diffie-Hellman key exchange, enabling point-to-point encryption.

• NIP-05: Mapping Public Keys to Domains, for easy memorization, such as mapping the author's public key to the @NomandJames domain.

• NIP-06: Mnemonic Words, similar to mnemonic words in cryptocurrency wallets.

• NIP-13: Proof of Work. This concept predates the emergence of Bitcoin and is widely used in blockchain POW consensus layers. It is also used in the Ethereum whisper protocol. The principle is to complete a computationally intensive proof of work before sending a message, and the relay server receiving the message will verify the validity of this proof. Providing this proof means spending computational power and raising the threshold for sending spam messages to clog the relay.

• NIP-22: Message Timestamp, informing the relay server of the time the message was created, so the relay can selectively receive messages. The timestamp can be set to the past or future.

• NIP-40: Expiration Time, informing the relay server of the message's expiration time, so the relay can delete it.

• NIP-57: Lightning Network Tip Links.

• NIP-65: Recommended Relay Service List.

Events

Events are the only Object structure on Nostr. Each event structure has a category (kind) used to mark the type of event (which operation the user performed or what information was received).

Operation of the Nostr Protocol

The Nostr protocol operates through relays, allowing users on the same relay to send Json files to each other.

The simplified diagram below illustrates this:

The diagram includes 3 relays and 3 clients. Each user's client is different (and not on the same platform).

The read and write situations in the diagram are as follows:

• Bob can see all of Alice's tweets but cannot see any of Mary's tweets (Bob is not even aware of Mary's existence).

• Alice can see all of Bob's tweets but cannot see any of Mary's tweets (Alice is also unaware of Mary's existence).

• Mary can see the tweets of both Bob and Alice. Since Mary only writes data to relay 3, she can read data from relay 2 (which stores Bob and Alice's data).

In-depth Analysis of the Nostr Contract

Given that the Nostr protocol is an extremely lightweight open protocol providing protocol specifications for decentralized social media platforms, let's attempt a simple analysis of the protocol code:

The foundation of the protocol is a WebSocket server (referred to as nostr-relay), which processes and stores a very simple data structure called Event. It is structured as follows:

{
  "id": 32-bytes sha256 of the serialized event data,
  "pubkey": 32-bytes hex-encoded public key of the event creator,
  "created_at": unix timestamp in seconds,
  "kind": integer,
  "tags": [
    ["e", 32-bytes hex of the id of another event, recommended relay URL],
    ["p", 32-bytes hex of the key, recommended relay URL],
    ... // other kinds of tags may be included later
  ],
  "content": arbitrary string,
  "sig": 64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field
}

Events are always signed (using Schnorr-type signatures) and contain structured data that may have different semantic meanings. XOnlyPubkeys of Schnorr type defined in BIP340 (currently used with Bitcoin Taproot) are used as "identities" throughout the protocol.

nostr-client is an app that can communicate with nostr-relay and can use a subscriber to subscribe to any set of events.

Filters represent all Nostr event sets that the client is interested in.

Users do not need to register or create accounts, as the client uses the user's public key for identification. Each time the client connects to a relay, it submits the user's subscription filter, and as long as they are connected, the relay streams "interested events" to the client.

Relays can cache client subscriptions, but it is not mandatory. Clients should handle everything like a "client," while relays may be as dumb as a rock.

Clients do not communicate with each other, but relays can. This allows relays to obtain data for clients that they do not have, and clients can subscribe to events outside of the relays they are connected to.

At first glance, this gives the impression that Nostr is useless as a protocol (why not just sign and dump the original JSON and let the client figure it out?), but upon closer inspection, the "dumb server, smart client" model can be found to have some significant engineering advantages in decentralized protocol design.

Key Features of Nostr's Full Decentralization

As a protocol layer for social applications, Nostr transmits notes and other stuff through relays, independent of any centralized servers. Its full decentralization allows any app to freely access an open and permissionless social platform through a distributed network. Therefore, Nostr does not even provide C-end products that users can directly operate, but focuses on implementing the necessary infrastructure for social interaction at the protocol layer. The productization capability is provided by third-party apps. Additionally, the social behaviors of users across different apps are interoperable.

Nostr's advantage lies in providing a truly free and open social network that is not influenced or threatened by any centralized power or interest. Users can freely express their views and beliefs without fear of censorship, banning, or cancellation. Content creators can freely set their incentive models without fear of income deprivation or unfair competition. Nostr users can also freely choose their social circles without fear of manipulation, misinformation, or privacy deprivation.

Nostr differs significantly from traditional social media and has the following characteristics and advantages:

Decentralization

Nostr does not rely on any centralized servers or platforms, instead using the Bitcoin network to transmit and store information. This means users do not have to worry about their data being stolen, censored, or deleted, nor do they have to comply with any third-party rules or policies.

Autonomy

Nostr allows users to control their own data and identity. Users can freely choose who they want to follow and trust, as well as freely express their views and ideas. Users do not have to worry about being banned, blocked, or downgraded, nor do they have to endure interference from advertisements or recommendations. Additionally, the authenticity of specific users makes it easy to identify spam and bot information.

Openness

Nostr is an open protocol that anyone can participate in and contribute to. Users can develop and use different clients, as well as build and run nodes (servers that can forward and store Nostr information). Users can also create and use different types and tags, which are used to differentiate and classify Nostr information. The concise and flexible event format supports various types of publishing: social media posts, long-form content, rich media, e-commerce, etc. Additionally, the combination of Nostr with the Lightning Network has enabled a new value-for-value and fairer business model.

Security Risks of the Nostr Protocol

Private Key Management

The Nostr protocol uses public-private key pairs as accounts, and users need to manage their private keys securely. Once the private key is lost, it cannot be recovered. This may be a challenge for most users, as they may not have enough technical knowledge and experience to manage private keys securely.

Relay Selection

In the Nostr protocol, users need to select and verify relays themselves. If a user chooses an untrustworthy or malicious relay, their information may be leaked, tampered with, or deleted.

Information Propagation

In the Nostr protocol, the information sent by users does not propagate across multiple relays. This means that if a user's information is not received and stored by enough relays, it may be lost or inaccessible to other users.

Island Effect Exacerbation

In the Nostr protocol, relays can freely choose whether to receive and store user information. This may lead to some relays choosing to only receive and store information they consider valuable or in line with their interests, while ignoring or rejecting other information.

Malicious Protocol Extensions

The Nostr protocol defines some basic event types and functions, but it also allows clients and relays to selectively implement additional functions. This may lead to some clients and relays implementing unsafe or malicious functions, thereby affecting user security and privacy.

Information Processing

Due to the lack of a consensus layer in the Nostr protocol, some relays do not process messages with significant differences in timestamps and UNIX time, which allows clients to potentially exploit time differences to forge messages.

Overview of the Nostr Ecosystem

The main supporter of the Nostr protocol is Jack Dorsey, co-founder of Twitter. As early as December 2022, Dorsey donated 14.17 bitcoins (approximately $245,000) to Nostr to support its development. His personal Nostr address is still prominently displayed on his X profile, indicating his fondness for the protocol.

Damus⚡️: Primary Application of the Nostr Protocol

X: Damus Twitter

Damus is a social app that supports Bitcoin tipping based on the Lightning Network, replacing the more common "Like" or thumbs-up with tips. The low fees of the Lightning Network make the network cost of tipping almost negligible.

In addition to Damus, the Nostr protocol is also used in communication tools like Anigma, text sharing tools like Sendtr, and offline chess mini-games like Jeste.

TGFB: Primary Media Partner of the Nostr Protocol

Website: TGFB

TGFB is a Christian Bitcoin education platform with the goal of educating and equipping Christians to understand Bitcoin and use it to glorify God and benefit all humanity.

A significant portion of the platform is dedicated to promoting Nostr protocol content, hosted by Jon and Jordan, who explore the implications and extensions of the decentralized social protocol Nostr from a Christian perspective. With Christianity being widely spread in Europe, America, and globally, and with Bitcoin being approved by the SEC for ETFs, combined with the Nostr social protocol built on the Lightning Network with a large user base, this will undoubtedly bring a large number of supporters and advocates for the Nostr protocol, playing an excellent role in promoting the development of the Nostr protocol ecosystem.

Derived Protocols of Nostr

Nostr + Taproot assets

The Nostr Assets Protocol is an open-source protocol that introduces Taproot assets and native Bitcoin payments in Satoshis (Sats) into the Nostr ecosystem. This protocol also supports interaction with other payment protocols, including the Lightning Network and Taproot assets.

Once assets are introduced, users can send and receive them at the Nostr protocol layer using Nostr's public and private keys. However, the settlement and security of assets still rely on the Lightning Network, as the Nostr Assets Protocol itself does not issue assets but introduces them into the Nostr asset platform through the protocol.

Nostr Assets provides full custody services, allowing users to deposit their Bitcoin or other assets into a wallet controlled by the Nostr Assets Protocol and then send instructions via Nostr messages to deploy, mint, and transfer tokens.

It is important to note that full custody services have some controversy: the custodial wallet of the Nostr Assets Protocol may have security risks, and users may lose all their assets if the platform is hacked or runs away. Additionally, after the launch of Nostr on October 30th, there were multiple instances of the website being shut down for maintenance, leading to doubts about the team's background and the project's reliability among some users. The Nostr official team has also expressed strong opposition to the token with the same name as the expansion protocol.

Nostr + Inscription

Noscription is an experimental token protocol based on Nostr, allowing users to create and trade tokens similar to brc-20 tokens on Nostr, as opposed to tokens similar to Taproot assets.

Comparison of the Three Protocols

Protocol Implementation

BitVM has high requirements for computing power and currently only has theoretical executability. In terms of commercial implementation, RGB has the upper hand and has many applications. (The development team of RGB's technical organization LNP/BP is small and non-profit, and the development progress is slow). Nostr, hindered by the general bottleneck of Socialfi, has also not been able to further advance the protocol's application ecosystem.

Privacy Protection

RGB and BitVM both involve off-chain computation, but the RGB protocol means that third parties cannot track the history of RGB assets on the blockchain; they only learn about the assets' history when they receive them. This is something BitVM cannot achieve. As a social protocol, Nostr's relays for information transmission have a high level of unpredictability, which may lead to issues such as information leakage, censorship, loss, and malicious exploitation of vulnerabilities.

BTC Native Support

RGB and BitVM do not require protocol changes to Bitcoin; Nostr is built on the native Lightning Network, and its native support is relatively good, providing a smooth development experience.

Protocol Security

The RGB protocol executes off-chain, and the sandbox environment ensures data security. The invoice system also ensures data security from a design perspective. In terms of interaction with BTC, it uses a pattern similar to the Lightning Network for asset issuance.

BitVM uses a Rollup model, also executing data off-chain. The features of the virtual machine, combined with fraud proofs and challenge-response mode, ensure the security of BitVM.

Nostr uses a relay model, and the clever design of information transmission between relays, combined with encryption algorithms, makes the information in the Nostr protocol sufficiently secure.

In the Web3 industry, there is currently no laboratory specifically focused on the security of the Bitcoin ecosystem. The establishment of the BTC Security Lab fills this gap, providing professional security support and research for the Bitcoin ecosystem. ScaleBit and BiHelix hope to lead the Bitcoin ecosystem security race, setting security standards for the entire industry and promoting the healthy development of the ecosystem.

Ecosystem and Commercialization

As a social protocol, Nostr's user base and traffic heat can surpass both Bit VM and RGB protocols. Its ecosystem expansion and commercial application are relatively more complete than the remaining two.

RGB has been released for a long time, and there are currently many ecosystem projects, many of which are waiting for the release of RGB V0.11.

The BitVM whitepaper was released only a few months ago, and the ecosystem has not yet been established.

The future of the three protocols will give rise to many Dapps in the fields of Socialfi, GameFi, and DeFi, bringing a new wave of enthusiasm to the BTC ecosystem.

Special thanks to Ausdin.eth, 0xLayman, Echo, and Venus for their contributions to this report.

【Disclaimer】The market is risky, and investment should be cautious. This article does not constitute investment advice, and users should consider whether any opinions, views, or conclusions in this article are suitable for their specific situation. Investment is at your own risk.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。