Detailed Introduction to RGB, BitVM, and Nostr

BTC Security Lab
2024-01-29 14:55:33
Collection
This article will take you deep into understanding RGB, BitVM, and Nostr, three highly promising BTC L2 solutions based on the Lightning Network.

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

Intro: Why BTC L2

The explosive growth of the inscription ecosystem in 2023 has rapidly increased the priority of BTC scalability issues. Various colored coins (Colored Coin - a method of adding additional attributes or meanings to Bitcoin on the Bitcoin blockchain through additional information, such as BRC20) have caused congestion in native Bitcoin transactions. BTC L2, as a key solution to this problem, will become a crucial narrative in 2024. This article will take you deep into three promising BTC L2 solutions: RGB, BitVM, and Nostr based on the Lightning Network.

RGB Protocol

What is RGB

RGB is a scalable and confidential smart contract protocol suitable for Bitcoin and the Lightning Network, developed by the LNP/BP Standards Association. It adopts the concepts of private and shared ownership and is a Turing-complete, trustless form of distributed computation that does not require the introduction of tokens in a non-blockchain decentralized protocol. It is important to clarify that there is no network or blockchain in RGB; it is a client-side validation technology, a partially state smart contract system.

Development History of RGB Protocol

History of RGB Protocol

RGB was initially conceived in 2016 by Giacomo Zucco from BHB Network 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 promoting RGB and participated in most of the code development and underlying standard design of the RGB protocol. Maxim Orlovsky and Giacomo Zucco jointly established the LNP/BP Standards Association (https://www.lnp-bp.org) to promote the transition of RGB from concept to practical application. The association is supported by Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA. After extensive development work, RGB released version V0.10 in April 2023, which is the first stable version available. In January 2024, RGB core developers indicated that version V0.11 would be released early in the first half of the year.

Latest Developments of RGB Protocol

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

  • Support for L-BTC will be added soon.
  • There will be updates on the interoperability of RGB assets with Liquid assets and cross-chain bridges.

However, RGB V0.11 will be incompatible with V0.10, which will result in significant migration costs for current projects, and many projects are currently in a wait-and-see state for the release of V0.11 due to slow development progress.

Design Philosophy and Operating Principles of RGB

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

RGB uses a single-use seal defined on Bitcoin UTXOs, which provides any party with the ability to verify its uniqueness with a smart contract state history. In other words, RGB leverages Bitcoin scripts to implement its security model and define 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 its existence except the contract owner (or parties to whom the owner discloses contract information).

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

In-Depth Look at RGB Contracts

After understanding the basic ideas behind the RGB architecture design, let's look at the contract part. In the current smart contract world, it is required that smart contract creators organize or execute the development of smart contract code themselves. However, the design philosophy of RGB believes that this is a bad practice that leads to higher contract code vulnerabilities and multiple hacking incidents. Therefore, RGB aims to reduce the risk of vulnerabilities and auditing requirements in development by introducing 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 needing to code or audit customized code written by some random outsourced vendor.

Flexible Scalability and Good Interoperability

RGB contracts are defined in a declarative manner rather than imperative programming. This means that the logic of the contract is not defined by a series of commands or steps but is described by a set of rules that define its behavior and state transitions, forming a directed acyclic graph (DAG) of state changes. The local state operations are key to the schema. Operations in RGB contracts are local rather than 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 every state to follow the same algorithm. This feature makes RGB sufficiently flexible and scalable while also providing good interoperability.

Easy Smart Contract Writing

The schema defines what types of global and owned states, seals, and metadata are allowed in state transitions. RGB uses the Contractum language to write programs for 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 very suitable for smart contracts, remote code execution, distributed and edge computing, providing a foundation for various advanced smart contract use cases.

How RGB Ensures Security and Privacy

From RGB's Own Design Perspective

  • ++Privacy of Non-Global Broadcasting:++ As mentioned above, RGB's client-side validation means that the validation process only occurs between the directly involved peers, not the entire network. This non-global broadcasting approach enhances privacy and censorship resistance, as the details of the contract state are only visible to the relevant participants, and miners cannot see transaction details.
  • ++Data Privacy in a Sandbox Environment:++ On the other hand, RGB stores all operational data in a stash. Since RGB is not blockchain-based, the storage is not replicated to other peer nodes. User-controlled local 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 also means there is a risk of loss.
  • ++In addition to validation and storage, the invoicing system also ensures security and privacy.++ Contract operations in RGB are conducted through the creation of invoices, which can include multiple contract operation requests. By requiring users to explicitly specify and validate contract operations, the accuracy and security of operations are improved. At the same time, the invoicing system supports the private transmission of contract operation requests between users, enhancing transaction privacy. State transfers, such as token transfers, are executed through invoices and specific commands.

From the Perspective of Interaction with BTC

  • The design of RGB is highly tied to UTXO. During interactions with the BTC mainnet, users create off-chain contracts to issue RGB assets and allocate them to Bitcoin's UTXO, which is very similar to the Lightning Network. Subsequently, asset transfers, contract interactions, and validations are conducted off-chain as described above.
  • RGB benefits from the better multi-signature, adapter-based signature protocols, and point-time lock contracts (PTLC) brought by Schnorr signatures, but its benefits are purely based on Bitcoin's benefits (i.e., indirect). There is nothing that needs to be signed internally in RGB (thus Schnorr does not make any changes internally), nor does it use Bitcoin scripts (thus new Tapscript is of no use).

The BTC Security Lab, jointly initiated by ScaleBit, is a dedicated BTC security laboratory that is committed to researching the latest developments of the RGB protocol, aiming to protect the security of its contracts and jointly promote the continuous updates and growth of the RGB protocol and the infrastructure of the BTC ecosystem.

Overview of RGB Ecosystem Projects

  1. BiHelix

Official website: https://www.bihelix.net/

BiHelix is a Bitcoin ecological infrastructure built on the native Bitcoin blockchain, combining the RGB protocol and the Lightning Network to optimize nodes. It aims to make it easier for developers to use, increase the use cases of Bitcoin, and address the challenges of scalability and Turing incompleteness faced by the Bitcoin blockchain. It aims to create a fairer decentralized crypto world for miners, validators, node service providers, exchanges, and users. As the first infrastructure built on the RGB protocol, BiHelix will create next-generation large-scale application scenarios for Bitcoin. Currently, the project is not yet interactive and is in the research and 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 for Lightning nodes to achieve globally universal payments.

  1. High reliability and scalability

Utilizing a mature cloud service architecture, fully leveraging the features of rust-lightning to support channel factory functions, efficiently managing channels, and creating channels in batches.

  1. Security and privacy protection

Transmitting and storing state data off-chain, using technologies such as recursive zero-knowledge proofs to randomize multi-party payments and path selection to achieve privacy protection.

  1. Developer-friendly

Providing comprehensive development tools, including open-source development documentation, tools, etc., while introducing the Schema social consensus mechanism to enable developers to easily build applications.

  1. Iris Wallet

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

IRIS Wallet, developed by the Bitfinex team, is the first Android wallet dedicated to RGB integration and RGB-related tools, supporting fungible and non-fungible assets. Iris Wallet supports RGB asset operations from issuance to expenditure and receipt, wrapping all functions in a familiar wallet application while abstracting as many technical details as possible. Currently, this is still an experimental application and is recommended for use with only a small amount of Bitcoin and low-value assets.

  1. DIBA

Official website: https://diba.io/

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

  1. Bitmask

Official website: https://bitmask.app/

This wallet, created by DIBA, is the first NFT wallet in the RGB ecosystem, running in web browsers and interacting with RGB contracts like MetaMask on Ethereum. It is currently frequently updated, awaiting the release of V0.11.

  1. Pandora Prime Inc

Official 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 committed to pioneering Bitcoin Finance by combining RGB smart contracts and the Lightning Network. They start with programmable assets on Bitcoin (RGBTC and CHFN), which can scale to VISA/MasterCard levels in transaction throughput via the Lightning Network while providing easy facilities for exchanging these assets. Currently, their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network.

  1. MyCitadel

Official website: https://mycitadel.io/

MyCitadel is a brand of Pandora Prime and is the first graphical user interface wallet supporting 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.

  1. RGB Explorer

Official website: https://rgbex.io/

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

  1. Bitlight Labs (formerly Cosminmart)

Official website: https://bitlightlabs.com/

Bitlight Labs develops infrastructure based on the RGB protocol, preparing to deploy multiple applications on the Lightning Network, including the RGB utility wallet Bitlight Wallet and Bitswap, an automated market maker built on the Lightning Network and RGB protocol.

  1. 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 version RGB V0.11 (the RGB v0.11 version is also working on code functionality related to Liquid).

10.2 MRGB Inscriptions

MRGB inscriptions are tokens based on the RGB protocol's client-side state validation and smart contract system. This token operates on 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 this system.

This innovation will bring enormous potential to BRC20 public chains, including reduced GAS consumption, faster transaction speeds, and improved overall performance. By adopting the MRGB system, BRC20 public chains will be able to handle transactions more efficiently and reduce user transaction costs. Meanwhile, MRGB inscription tokens will also serve as consumables in the transaction process, thereby increasing the liquidity and scalability of BTC.

10.3 Single-Use-Seal

X: @SingleUseSeal

Seal is a 10k PFP collection, rare UDA, and tokens on RGB20 and RGB21, named after the Single Use Seal proposed by Peter Todd, currently awaiting the Bitlight and Bitmask wallets to update to version 0.11 RGB before issuing.

10.4 Bitman

X: @bitmancity

Will issue 10k UDA on DIBA, possibly as wl+public sale, with the aim of "passing on the spirit of BTC." The project has a good intention and will issue wl to BTC ecosystem contributors, with most of the public sale 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), with all computations processed off-chain to reduce congestion on the Bitcoin blockchain.

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

On October 9, 2023, Robin Linus, co-founder of blockchain developer ZeroSync, published the ++BitVM white paper++. Compared to RGB, BitVM is much younger.

Design Architecture of BitVM

Architecture

Similar to optimistic rollups and the MATT proposal (Merkelize All The Things), BitVM is based on fraud proofs and challenge-response protocols, requiring no 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 submitter to set specific bits to "0" or "1." Any computable function can be represented as a Boolean circuit, forming logical gate commitments. Built using NAND gates (universal logic gates), each gate has its own commitment. Combinations of gate commitments can express any circuit. 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 are represented by instructions in the Script, forming the basic unit of the program. These instructions generate binary outputs (0 or 1) within the Taproot address, thereby constructing the entire taptree. The complexity of the programs that taptree can execute depends on the number and complexity of the Taproot addresses that compose it. In short, BitVM enables the execution of more complex programs on the Bitcoin network by transforming Bitcoin's Script instructions into binary operations.

Two-Party Participation

The current model is limited to two parties and cannot expand the number of participants. Additionally, to make BitVM work properly, a large number of pre-signed transactions (off-chain computations) are required, which makes BitVM quite complex and may lead to efficiency issues.

Fraud Proofs and Challenge-Response Protocols

The prover and challenger deposit an equal amount of BTC in a transaction for betting (as input), and this transaction output will contain a logical circuit. This is achieved by pre-signing a series of transactions during the setup phase to rebut erroneous claims. BitVM is likened to optimistic rollups because it executes most computations off-chain and submits some of those computations on-chain to resolve disputes when they arise.

  • Optimistic rollups are a second-layer scaling solution that alleviates the load on the base layer by moving computation and data storage off-chain. It then bundles multiple transactions and publishes them to the main chain.
  • Optimistic rollups assume that all transactions are valid. However, if network participants become aware of dishonest behavior, they can initiate fraud proofs. Fraud proofs are evidence that someone has computed inaccurately. They are generated after verification.

Off-Chain Computation

Almost all activities on BitVM are conducted off-chain. This includes initiating computation tasks, sharing data, and verifying submitted claims. BitVM typically does not run computations on the Bitcoin blockchain. Only when there is a dispute due to suspected fraud will computational activities and validations be published on-chain. However, if there is a dispute, a small part of the dispute process does run on-chain, just enough to identify which party is dishonest.

With the above foundational knowledge, we can better understand the specific principles of BitVM's two-party interaction.

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 multi-signature manner. The prover must also share enough information with the verifier to prove that their program can produce the promised output.

The verifier's task is to run the prover's code and verify whether 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 pre-signed transactions to verify the correctness of the computation.

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

Ultimately, this interaction ensures that computation verification only transfers to the Bitcoin blockchain in the event of a dispute, allowing the vast majority of computations to be executed off-chain. This design maintains the efficiency of the Bitcoin network while providing the capability to run more complex programs on Bitcoin.

Security of BitVM

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

Fraud Proofs

In the event of a dispute, the verifier can challenge the prover's erroneous claims through fraud proofs. This mechanism is similar to optimistic rollups and does not require changes to Bitcoin's consensus rules.

Challenge-Response Protocol

BitVM employs a challenge-response protocol in which the prover and verifier pre-sign a series of transactions during the protocol's setup phase. These transactions are used to resolve issues when disputes arise.

Off-Chain Computation and On-Chain Confirmation

BitVM allows for complex computations to be executed off-chain, with relevant verifications and resolutions occurring on-chain only 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 Penalty Mechanism

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

The two-party contract mechanism enhances privacy on BitVM and reduces transaction costs, but compared to the multi-party mechanism of EVM, its universality is somewhat diminished.

Nostr Protocol

What is the Nostr Protocol

Nostr stands for "Notes and Other Stuff Transmitted by Relays." From the full name of the protocol, it is clear that this is a transmission protocol, and the existence of relays indicates that this is not a P2P transmission protocol. The Github code update records show that this project started 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 the control or interference of 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 and Private Key Pair

A public-private key pair constitutes a Nostr account. Nostr accounts are not based on traditional username and password systems but use a public key and private key system similar to cryptocurrencies. For ease of understanding, the public key can be considered the username, while the private key can be considered the password. It is important to note that if the private key is lost, it cannot be reset like a password. Public keys start with npub1, while private keys start with nsec1. Ensure that public and private keys are properly stored before use, as they cannot be recovered once lost.

Client

Nostr itself is merely a protocol for sending information over the internet. Users need client software to use the Nostr protocol. Clients can be web-based, desktop software, or mobile apps. Clients read information from relays and send newly generated data to relays for other clients to read. The information contains signatures that ensure the data is sent by the real sender. Clients use the private key to create signatures. When using a desktop or mobile client for the first time, the private key must be stored within it. The public key can be derived from the private key. If using a web client, it is not recommended to store the private key directly; it is better to use a plugin to save the private key.

Relay

Relays can be understood as the backend servers of the Nostr protocol. Nostr clients send information to 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; rather, they can vary greatly over time. The Nostr protocol relies on relays to store and retrieve data. If users feel that their client is slow, it may be because the connected relay is slow, and they can consider adding other relays.

NIPs

Nostr Implementation Possibility (NIP) is used to standardize compatible Nostr relays and client software, specifying what must, should, and may be implemented. "NIP" serves as a reference document outlining how the Nostr protocol works. Nostr is a decentralized protocol and is not monopolized by any centralized entity (like Twitter). This means that the development direction of the protocol depends on all participants, and we can suggest and advocate for changes and provide feedback on ideas offered by others. As active members of the protocol community, everyone has a say in the subsequent development direction of the Nostr network. The main code repository has already approved NIPs, 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 for peer-to-peer encryption.
  • NIP-05: Mapping Public Keys to Domain Names, for easier memorization, e.g., the author's public key npub10jprg9n3ecjlpez0fyg7y7yvpl66drtjv8rv0hfllxpdxhesuwzs4c2kw6 is mapped to the domain @NomandJames.
  • NIP-06: Mnemonic Phrases, similar to mnemonic phrases used in cryptocurrency wallets.
  • NIP-13: Proof of Work. This concept predates the emergence of Bitcoin and is widely used in the blockchain POW consensus layer, and is also applied in Ethereum's whisper protocol. Its principle is that before a client sends a message, it must complete a computation-intensive proof of work, which the receiving relay server will verify for validity. Providing this proof means spending computational power, raising the threshold for sending spam to clog relays.
  • NIP-22: Message Timestamps. Informing the relay server of the time the message was created so that the relay can selectively receive messages. Timestamps can be set to the past or future.
  • NIP-40: Expiration Time. Informing the relay server of the message's expiration time so that the relay can delete it.
  • NIP-57: Lightning Network Tip Links.
  • NIP-65: Relay Service Recommendation List.

Events

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

Operation of the Nostr Protocol

The Nostr protocol operates through relays. These relays allow users on the same relay to send JSON files to each other.

The following simplified diagram will help everyone understand:

The diagram includes three relays and three users. Each user in the diagram uses a different client (and is 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 does not even know Mary exists).
  • Alice can see all of Bob's tweets but cannot see any of Mary's tweets (Alice also does not know Mary exists).
  • Mary can see tweets from both Bob and Alice. Because Mary only writes data to Relay 3, she can read data from Relay 2 (which stores Bob and Alice's data).

In-Depth Look at Nostr Contracts

Given that the Nostr protocol is a very lightweight open protocol that provides protocol specifications for decentralized social media platforms, we will attempt a simple code analysis of the protocol:

The foundation of the protocol is a WebSocket server (called nostr-relay), and its processing and storage is a very simple data structure called ++Event++. It is as follows:

{ "id": \<32-bytes sha256 of the serialized event data\>, "pubkey": \<32-bytes hex-encoded public key of the event creator\>, "created_at": \, "kind": \, "tags": [ ["e", \<32-bytes hex of the id of another event\>, \], ["p", \<32-bytes hex of the key\>, \], … // other kinds of tags may be included later ], "content": \, "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 they contain structured data that may have different semantic meanings. The Schnorr-type XOnlyPubkeys defined in ++BIP340++ (currently used with Bitcoin Taproot) serve as "identities" throughout the protocol.

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

Filters represent all Nostr events that the client is interested in.

Clients do not need to register or create accounts, as clients identify users using their public keys. Each time a client connects to a relay, it submits the user's subscription filter, and as long as they are connected, the relay will stream "interesting events" to the client.

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

Clients do not talk to each other. But relays can. This allows relays to fetch data that the client does 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 raw JSON and let clients figure it out?), but looking deeper, the "dumb server, smart client" model can reveal some significant advantages in decentralized protocol design.

Full Decentralization as a Key Feature of Nostr

As the protocol layer for social applications, Nostr transmits Notes and other Stuff through Relays, relying on no centralized servers. Its full decentralization allows any app to freely connect, providing an open and permissionless social platform through a distributed network. Therefore, Nostr does not even provide users with a direct C-end product to operate; instead, it focuses on implementing the necessary infrastructure for social interactions at the protocol layer. The ability to productize is provided by third-party apps, and the social behaviors of users across different apps are interoperable.

Nostr's advantage lies in its provision of a truly free and open social network, unaffected or threatened by any centralized power or interests. Users can freely express their views and beliefs without fear of censorship, bans, or cancellations; content creators can freely set their incentive models without fear of losing income or facing unfair competition. Nostr users can also freely choose their social circles without worrying about manipulation, misinformation, or loss of privacy.

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 but transmits and stores information through the Bitcoin network. This means users do not have to worry about their data being stolen, censored, or deleted, nor are they subject to the rules or policies of any third party.

Autonomy

Nostr allows users to control their data and identity. Users can freely choose whom they want to follow and trust, as well as express their views and thoughts. Users do not have to worry about being banned, blocked, or downgraded, nor do they have to endure the interference of advertisements or recommendations. At the same time, the verifiability of specific users makes it easy for users to identify spam and bot information.

Openness

Nostr is an open protocol, allowing anyone to participate and contribute. Users can develop and use different clients themselves, as well as set up and run nodes (which can forward and store Nostr information). Users can also create and use different types and tags, which are metadata used to distinguish and categorize Nostr information. The simple and flexible event (Event) format supports various types of publications: social media posts, long-form content, rich media, e-commerce, etc. At the same time, Nostr's integration with the Lightning Network realizes a new value-for-value, 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 properly. Once a private key is lost, it cannot be recovered. This may pose a challenge for most users, as they may not have sufficient technical knowledge and experience to manage private keys securely.

Relay Selection

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

Information Dissemination

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 not visible to other users.

Isolation Effect Intensification

In the Nostr protocol, relays can freely choose whether to receive and store users' information. This may lead some relays to choose only to receive and store information they deem valuable or in their interest 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 functionalities. This may lead some clients and relays to implement insecure or malicious functionalities, thereby affecting user security and privacy.

Information Processing Issues

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

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 support its development. His personal Nostr address is still prominently displayed on his X profile, indicating his fondness for the protocol.

Damus⚡️: The Main Application of the Nostr Protocol

X: https://twitter.com/damusapp

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

In addition to Damus, applications of the Nostr protocol include communication tools like Anigma, text-sharing tools like Sendtr, and online chess mini-games like Jeste.

TGFB: The Main Collaborative Media for the Nostr Protocol

Official website: https://tgfb.com/

TGFB is a Christian Bitcoin education platform aimed at educating and equipping Christians to understand Bitcoin and use it to promote God's glory and benefit all humanity.

A significant portion of its content is dedicated to promoting the Nostr protocol through podcasts hosted by Jon and Jordan, exploring the implications and extensions of this decentralized social protocol from a Christian perspective. As a widely spread religion in Europe and America, combined with the well-known Bitcoin that has been approved by the SEC for ETFs, and the Nostr social protocol built on the user base of the Lightning Network, the combination of these three will undoubtedly bring a large number of supporters and advocates for the Nostr protocol, greatly promoting the development of the Nostr ecosystem.

Nostr Derivative Protocols

Nostr + Taproot Assets

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 interactions with other payment protocols, including the Lightning Network and Taproot assets.

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

Nostr Assets helps users better perform basic functions such as transfers/trading by controlling (hosting) wallets with Nostr messages, built on the technology of Nostr, but it is a completely different protocol from Nostr.

The full custody service of the Nostr Assets Protocol means that users 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 come with certain controversies: the custodial wallets of the Nostr Assets Protocol may pose security risks, and users cannot fully control their assets. If the platform is hacked or goes bankrupt, users may lose all their assets.

At the same time, after the launch of Nostr on October 30, there were many users recharging assets, leading to multiple instances of the website going offline for maintenance, raising doubts about the team's background and project reliability. On November 8, the official account of the Nostr Assets Protocol responded to a Chinese comment under a tweet, and some users are currently skeptical about the true identity and reliability of the project. The Nostr official has also consistently expressed strong opposition to the tokens named after the protocol in this expansion protocol.

Nostr + Inscription

Noscription is an experimental token protocol based on Nostr that allows users to create and trade tokens similar to brc-20, rather than tokens like Taproot assets.

Comparison of the Three

Protocol Implementation

BitVM has extremely high requirements for computational capabilities and currently only has theoretical executability. In terms of commercial implementation, RGB is superior and already has many applications (the technical organization of RGB, LNP/BP, has few developers and is non-profit, leading to slow development progress). Nostr has not been able to further advance the protocol application ecosystem due to the common bottlenecks of Socialfi.

Privacy Protection

Both RGB and BitVM are off-chain computations, but the RGB protocol means that third parties cannot track the history of RGB assets on the blockchain; users only learn about the asset's history when they receive it. This is something BitVM cannot achieve. The Nostr protocol, as a social protocol, has a high degree of uncertainty in the relays that disseminate information, which may lead to information leaks, blockages, losses, and malicious tampering due to vulnerabilities.

Native BTC Nature

Both RGB and BitVM do not require protocol changes to Bitcoin; Nostr, on the other hand, is built on the native Lightning Network, with relatively good native characteristics and a smooth development experience.

Protocol Security

The RGB protocol executes off-chain, and the sandbox environment ensures data security. The invoicing system also guarantees data security by design. In terms of interaction with BTC, it issues assets using a model similar to the Lightning Network.

BitVM adopts a rollup model, with data executed off-chain as well. The characteristics of the virtual machine, combined with fraud proofs and challenge-response modes, ensure the security of BitVM.

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

Currently, there is no laboratory specifically focused on the security of the Bitcoin ecosystem in the Web3 industry. 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 security track of the Bitcoin ecosystem, setting security standards for the entire industry and promoting the healthy development of the ecosystem.

Ecosystem and Commercialization

As a social protocol, the Nostr protocol can surpass both BitVM and RGB in terms of user volume and traffic heat, with its ecosystem protocol expansion and application commercialization being relatively more complete than the other two.

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

The BitVM white paper has only been released for a few months, and its ecosystem has not yet been established.

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

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

*【Disclaimer】The market has risks, 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 align with their specific circumstances. Investment based on this is at one's own risk.**

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.
banner
ChainCatcher Building the Web3 world with innovators