RGB protocol

What is RGB

RGB is a scalable and confidential smart contract protocol applicable to Bitcoin and the Lightning Network, developed by the LNP/BP Standards Association. It adopts the concepts of private and joint ownership, offering a Turing-complete, trustless form of distributed computing without the need for a blockchain, operating as a client-validated, partial-state smart contract system.

Development History of the RGB Protocol

RGB protocol history

RGB was initially conceived by Giacomo Zucco from the BHB Network in 2016 as a “non-blockchain-based asset system.” That same year, Peter Todd introduced the concepts of single-use seals and client-side validation. Inspired by these ideas, RGB was proposed in 2018. In 2019, core developer Maxim Orlovsky took a leading role in RGB’s code development and foundational standard design. Maxim Orlovsky and Giacomo Zucco founded the LNP/BP Standards Association (https://www.lnp-bp.org) to drive RGB from concept to application, with support from Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime, and DIBA. After extensive development, RGB released its first stable version, V0.10, in April 2023. In January 2024, the core developers of RGB announced that version V0.11 would be released early in the first half of the year.

Latest Developments in the RGB Protocol

The new features of RGB V0.10 have been thoroughly analyzed in other reports. While V0.11 has not yet been officially released, here are some of the latest developments from the developers and community:

• Upcoming support for L-BTC

• Updates on the interoperability and cross-chain bridges between RGB assets and Liquid assets

However, RGB V0.11 will be incompatible with V0.10, leading to significant migration costs for current projects. Additionally, due to slow development progress, many projects are currently waiting for the release of V0.11.

RGB Design Philosophy and Operating Principles

RGB smart contracts utilize client-side validation, meaning all data is stored outside of Bitcoin transactions, that is, on the Bitcoin blockchain or the state of Lightning channels. This allows the system to operate on top of the Lightning Network without any changes to the BTC mainnet or Lightning Network protocols, laying the foundation for the protocol’s scalability and privacy.

RGB uses one-time seals defined on Bitcoin UTXOs, providing anyone with a record of the smart contract state history the ability to verify its uniqueness. In other words, RGB leverages Bitcoin scripts to implement its security model and to define ownership and access rights.

RGB is a Directed Acyclic Graph (DAG) of state transitions, where contracts are completely isolated from each other, and nobody knows of their existence except for the contract owners (or those to whom the owner discloses contract information).

A Directed Acyclic Graph (DAG) is a special graph structure that can vividly explain complex systems or relationships. In a DAG, each edge can be thought of as a one-way street in a city, which represents the “directed” aspect of the graph. Suppose in this network of streets, no matter how you travel, it’s impossible to return to the starting point and form a closed loop; this represents the “acyclic” nature of the graph. In a DAG, there is no sequence of nodes that allows you to start from one node, travel through a series of edges, and return to the same node.

Applying this concept to the RGB system, each contract can be viewed as a node in the graph, and the relationships between contracts (such as the transfer of ownership) can be seen as directed edges. This structure ensures that the relationships between contracts are clear and orderly, without forming closed loops, meaning a contract cannot directly or indirectly affect itself.

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

Diving into RGB Contracts

After understanding the basic principles of RGB’s architectural design, let’s look at the contract part. In the current world of smart contracts, creators are required to organize or execute the development of smart contract code themselves. RGB’s design philosophy considers this practice undesirable, leading to higher contract code vulnerabilities and multiple hacker attacks. Therefore, RGB aims to reduce the risk of vulnerabilities in development and the need for audits by introducing the concept of “Schema Patterns.” “Schema Patterns” are the actual code of smart contracts. Publishers can use them as “contract templates” without needing to code or audit custom code written for them by some random contractor.

Flexible Scalability and Good Interoperability

RGB contracts are defined declaratively, not imperatively. This means 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 local state operations lies in the Schema. Operations in RGB contracts are local, not global. Each node (or state) has its own rules and is only responsible for its state transitions. This is different from global algorithms on platforms like Ethereum, which require each state to follow the same algorithm. This characteristic makes RGB sufficiently flexible and scalable while also providing good interoperability.

Simplified Smart Contract Creation

Schema defines which types of global and owned states, seals, and metadata are 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 without random memory access, making it highly 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 the design of RGB itself:

• Privacy without global broadcasting: As mentioned, RGB’s client-side validation means the validation process only occurs between directly involved peers, not the entire network. This non-global broadcasting approach enhances privacy and censorship resistance because the details of the contract state are only visible to relevant participants, and miners cannot see transaction details.

• Data privacy in a sandbox environment: On the other hand, RGB stores all operation data in a stash. Since RGB is not blockchain-based, the storage is not replicated to other peer nodes. Storage controlled locally by users reduces the risk of external attacks and data leaks, ensuring data privacy. RGB is a computing platform where each program (“smart contract”) is isolated in its sandbox environment, offering better scalability and security than blockchain-based platforms. However, off-chain data also means there is a risk of loss.

• Beyond validation and storage, the invoicing system also ensures security and privacy. Contract operations in RGB are carried out by creating invoices, which can contain multiple contract operation requests. By allowing users to explicitly specify and verify contract operations, the accuracy and security of operations are improved. At the same time, the invoicing system supports private transmission of contract operation requests between users, enhancing transaction privacy. State transitions, such as token transfers, are executed through invoices and specific commands.

From the Perspective of Interacting with BTC

RGB’s design is highly tied to UTXOs. In interactions with the BTC mainnet, users create off-chain contracts to issue RGB assets and allocate them to Bitcoin’s UTXOs, similar to the Lightning Network. Then, asset transfers, contract interactions, and validations are performed off-chain as introduced above.

RGB benefits from the improved multisig, adaptor-based signature protocols, and Point Time Locked Contracts (PTLCs) brought by Schnorr signatures, but its benefits are purely based on Bitcoin’s (i.e., indirect). There is nothing within RGB that requires signatures (thus Schnorr makes no changes internally), nor does it use Bitcoin scripts (thus new Tapscript is of no use).

BTC Security Lab, co-founded by ScaleBit, is a dedicated BTC security laboratory working on the latest developments of the RGB protocol. Its aim is to protect contract security, jointly promoting the continuous growth and strengthening of the RGB protocol and the infrastructure construction of the BTC ecosystem.

Overview of RGB Ecosystem Projects

BiHelix

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

• BiHelix is a Bitcoin ecosystem infrastructure optimized for nodes, built on the native Bitcoin blockchain, incorporating the RGB protocol and the Lightning Network. It aims to make development easier, expand the use cases for Bitcoin, and address the challenges of scalability and Turing incompleteness faced by the Bitcoin blockchain. BiHelix strives to create a fairer decentralized cryptographic world for miners, validators, node service providers, exchanges, and users. As the first infrastructure built on the RGB protocol, BiHelix will develop the next generation of large-scale Bitcoin application scenarios. The project is currently in the development stage and not yet open for interaction; stay tuned.

  Project Features

• Low User Threshold : Utilizes the SLR (Security-Lightning-RGB) protocol, repackaging RGB and the Lightning Network with innovative solutions for lightning nodes to achieve universal payment.

• High Reliability and Scalability : Employs a mature cloud service architecture, fully leveraging the features of rust-lightning to support channel factory functions, efficiently manage channels, and create channels in bulk.

• Security and Privacy Protection : Off-chain transmission and storage of state data, using recursive zero-knowledge proofs among other technologies to randomize multipart payments and path selection for privacy protection.

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

  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 enables operations of RGB assets from issuance to spending and receiving, packaging all functionalities in a familiar wallet application while abstracting as many technical details as possible. It is currently an experimental application recommended for small amounts of Bitcoin and low-value assets.

  DIBA

• Website: https://diba.io/

• DIBA is the first NFT marketplace on Bitcoin using the RGB Protocol and the Lightning Network. It aims to shape the understanding of un-custodied art assets on the Bitcoin blockchain.

  Bitmask

• Website: https://bitmask.app/

• Created by DIBA, Bitmask is the first NFT wallet in the RGB ecosystem, operable in web browsers and interacting with RGB contracts similar to MetaMask on Ethereum. It is currently frequently updated, awaiting the release of V0.11.

  Pandora Prime Inc

• Website: https://pandoraprime.ch/

• Located in Verify Valley, Switzerland, Pandora Prime 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 scale transaction throughput to VISA/MasterCard levels through the Lightning Network while providing facilities for easy exchange of these assets. Their products include MyCitadel (wallet), RGB Explorer (browser), and Pandora Network, among others.

  MyCitadel

• Website: https://mycitadel.io/

• A brand of Pandora Prime, MyCitadel is the first GUI wallet supporting RGB, created by RGB developers in 2021. It offers cross-platform desktop wallets and iOS/iPad wallets. The mobile wallet can handle fungible RGB assets.

  RGB Explorer

• Website: https://rgbex.io/

• Developed by Pandora Prime, RGB Explorer is the first browser to offer RGB asset registration and smart contracts. Currently, it supports RGB 20, RGB 21, RGB 25, displaying assets such as LNPBP, RGBTC, dCHF, and RGBEX.

  Bitlight Labs (formerly Cosminmart)

• Website: https://bitlightlabs.com/

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

RGB Memes & NFT

1. PPRGB

   • X: @PepeRgb20

   • PPRGB is currently issued on the Liquid network, awaiting mapping to RGB after the release of RGB V0.11 (V0.11 is also developing code functions for interfacing with Liquid).

2. MRGB Inscription

   • MRGB inscription is a token based on the RGB protocol client state validation and smart contract system. It operates on the second and third layers (off-chain) of the Bitcoin ecosystem and will provide open-source underlying protocol code, enabling all BRC20 public chains to directly use this system. This innovation brings significant 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 transaction costs for users. Meanwhile, the MRGB inscription token will also serve as a consumable in the transaction process, thereby increasing BTC’s liquidity and scalability.

3. Single-Use-Seal

   • X: @Single_Use_Seal

   • Seal, is a collection of 10k PFP, rare UDA, and tokens on RGB20 and RGB21, named after Peter Todd’s Single Use Seal concept. Currently waiting for the Bitlight and Bitmask wallets to update to the v0.11 RGB version, after which they will be issued on them.

4. Bitman

   • X: @bitmancity

   • Will issue 10k UDA on diba, possibly through a wl+public sale, with the mission of “transmitting the spirit of BTC.” The project has a commendable purpose and will give wl to BTC ecosystem contributors, with most of the public sale proceeds donated to LNP/BP.

BitVM

Why BitVM?

BitVM (Bitcoin Virtual Machine) introduces a system that allows any computation to be verified on the Bitcoin blockchain without compromising its security or altering the network. This development opens the door for complex computations, such as Turing-complete smart contracts, with all computations being processed off-chain to reduce congestion on the Bitcoin blockchain.

“In simple terms, BitVM is a computational model capable of expressing 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 blockchain developer ZeroSync, published the BitVM whitepaper. Compared to RGB, BitVM is much younger.

BitVM’s Design Architecture

Architecture

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

Gate Circuit Design

The Bit Value Commitment is the most basic component, allowing the committer to set a specific bit’s value to “0” or “1”. Any computable function can be represented as a Boolean circuit, forming logic 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 a Tapleaf and combined within the same Taproot address.

BitVM utilizes Bitcoin’s Taproot upgrade by creating a structure similar to a binary circuit (called a taptree) to achieve its functionality. Within this system, the spending conditions for each UTXO, represented by instructions in a Script, form the basic unit of the program. These instructions generate binary outputs (0 or 1) within a Taproot address, thus constructing the entire taptree. The output of the taptree can be considered the result of a binary circuit’s execution, akin to an executable program. The complexity of the programs that a taptree can execute depends on the number and complexity of the Taproot addresses composing it. In short, BitVM realizes the capability to run more complex programs on the Bitcoin network by translating Bitcoin’s Script instructions into binary operations.

Participating roles are two parties

Currently, the model is limited to two parties and cannot be expanded to include more participants. Moreover, for BitVM to function properly, a large number of pre-signatures (off-chain computations) are required, making BitVM quite complex and potentially inefficient.

Fraud proofs and challenge-response protocol

Both the prover and the challenger deposit an equal amount of BTC in a transaction as a bet (as input), and the output of this transaction will include a logic circuit. A series of transactions are pre-signed during the setup phase to refute incorrect statements. BitVM is likened to Optimistic Rollups because it performs most of the computation off-chain and submits some of these computations on-chain to resolve disputes when they arise.

Optimistic Rollups are a second-layer scaling solution that reduces 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 all transactions are valid. However, if network participants notice dishonest behavior, they can initiate a fraud proof. A fraud proof is evidence of someone’s inaccurate calculation. They are produced after an inspection.

Off-chain computing

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

With the above background 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 master root address. These funds are kept in a 2-of-2 multisignature arrangement. The prover also needs to 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 matches the expectations. If the output does not match, the verifier will challenge the prover. This challenge-response interaction process involves the exchange of data off-chain and the use of pre-signed transactions to verify the correctness of the computation.

If a computational error is discovered, the verifier can publicly prove the prover’s dishonest behavior through 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 retains their funds. This economic incentive mechanism is designed to prevent dishonest behavior.

Ultimately, this interaction ensures that computational verification is only transferred to the Bitcoin blockchain in the event of a dispute, thereby performing the vast majority of computations 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 the perspective of architectural design, the security of BitVM is primarily based on the following aspects:

Fraud Proofs

In the event of a dispute, validators can challenge the proposer’s incorrect statements through fraud proofs. This mechanism is similar to Optimistic Rollups and does not require changing Bitcoin’s consensus rules.

Challenge-Response Protocol

BitVM uses a challenge-response protocol, where proposers and validators sign a series of transactions in advance during the setup phase of the protocol. These transactions are used to resolve issues when a dispute arises.

Off-Chain Computation with On-Chain Verification

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

Deposit and Penalty Mechanism

If a proposer makes an incorrect statement, validators can confiscate their deposit. This mechanism ensures that attackers always lose their deposit for wrongful actions.

Bilateral Contract Mechanism

This mechanism provides better privacy on BitVM and reduces transaction costs, but compared to the multi-party mechanism of EVM, its universality 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 that involves relays, suggesting it is not a peer-to-peer (P2P) transmission protocol. According to the GitHub code update records, this project was launched in November 2020. The protocol aims to create the simplest open protocol for a censorship-resistant global social network. It is a decentralized social protocol that allows users to create, publish, and subscribe to any type of content without control or intervention from any centralized platforms or institutions. Nostr draws inspiration from Bitcoin and the Lightning Network, employing similar cryptographic and consensus mechanisms, as well as an event-based data structure known as the Nostr Network.

Components of the Nostr Protocol

Public and Private Key Pair

A public and private key pair constitutes a Nostr account. Unlike the traditional username and password system, Nostr accounts use a public and private key system similar to cryptocurrencies. For simplicity, the public key can be thought of as the username, and the private key as the password. It’s important to note that once the private key is lost, it cannot be reset like a password. Public keys are prefixed with npub1, and private keys with nsec1. It’s crucial to ensure the safekeeping of these keys, as they cannot be recovered if lost.

Client

Nostr is a protocol for sending information over the internet, requiring a client software for usage. Clients can be web pages, desktop software, or mobile apps. Clients read information from relays and send newly generated data to relays for other clients to read. Information includes signatures to ensure data is sent by the authentic 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. The public key can be obtained from the private key. For web clients, it’s not recommended to directly save the private key in them; instead, it’s 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 the information and broadcast it to all connected clients. It’s important to note that relays are not constant; they can change significantly over time. The Nostr protocol relies on relays to store and retrieve data. If a user experiences slow client speeds, it might be due to the connected relay’s slow speed, and they might consider adding some other relays.

NIPs

NIPs (Nostr Implementation Possibilities) are standards used to regulate Nostr-compatible relays and client software, specifying what must, should, or could be implemented. “NIP” refers to reference documents outlining how the Nostr protocol operates. Nostr is a decentralized protocol, not monopolized by any centralized entity (such as Twitter), meaning its development direction depends on all participants. We can propose and advocate for changes and provide feedback on others’ ideas. As active members of the protocol community, everyone has a certain say in the future development direction of the Nostr network. NIPs in the main codebase have been approved and new ideas can be added through pull requests.

Key NIPs include:

• NIP-04: Message encryption, using the secp256k1 algorithm for Diffie-Hellman key exchange, enabling end-to-end encryption.

• NIP-05: Maps public keys to domain names for easy recall, such as mapping the author’s public key to the @NomandJames domain.

• NIP-06: Mnemonic phrases, similar to those used in cryptocurrency wallets.

• NIP-13: Proof of Work. This concept predates Bitcoin and is widely used in blockchain POW consensus layers and Ethereum’s whisper protocol. It involves completing a computationally intensive proof of work before sending a message, which the receiving relay server verifies. Providing this proof means expending computational power, raising the threshold for spamming relays with junk messages.

• NIP-22: Message timestamps. Informing relay servers of the time a message was created, allowing relays to selectively accept messages. Timestamps can be set for the past or future.

• NIP-40: Expiry time. Informing relay servers of when a message expires so it can be deleted.

• NIP-57: Lightning Network tipping links.

• NIP-65: Recommended list of relay services.

Events are the only Object structure on Nostr. Each event has a kind to indicate the type of event (what action the user has taken or what information they have received).

Nostr Protocol Operation

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

To help understand this, consider a simplified diagram:

The diagram includes 3 relays and 3 clients, each client using a different platform.

In this diagram:

• Bob can see all of Alice’s tweets but none of Mary’s (Bob is even unaware of Mary’s existence).

• Alice can see all of Bob’s tweets but none of Mary’s (Alice is also unaware of Mary’s existence).

• Mary can see tweets from both Bob and Alice because she writes data only to Relay 3 but can read data from Relay 2 (which holds Bob and Alice’s data).

Deep Dive into Nostr Contracts

Given the Nostr protocol as a very lightweight open protocol, it provides a set of protocol specifications for decentralized social media platforms. Let’s conduct a simple code analysis of the protocol:

The foundation of the protocol is a WebSocket server (known as nostr-relay), which processes and stores a very simple data structure called an Event. It is shown 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. The Schnorr type XOnlyPubkeys defined in BIP340 (currently used with Bitcoin Taproot) are used as “identities” throughout the protocol.

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

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

Clients 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 the relay, it submits the user’s subscription filter, and as long as they are connected, the relay will stream the “events of interest” to the client.

Relays may cache client subscriptions, but this is not mandatory. Clients should handle everything on the “client side,” while relays may be as dumb as a rock.

Clients do not talk to each other. But Relays can. This allows relays to fetch data for the client that it does not have, and clients can subscribe to events outside of the relay they are connected to.

At first glance, this gives the impression that Nostr as a protocol is useless (why not just sign and dump the raw JSON and let the client figure it out?), but a deeper look reveals that the “dumb server, smart client” model can discover some significant advantages in the engineering of decentralized protocol design.

Fully Decentralized as a Key Feature of Nostr

Nostr serves as the protocol layer for social applications, transferring Notes and other Stuff via Relays without relying on any centralized servers. Its full decentralization allows any app to freely access through a distributed network, providing an open and permissionless social platform. Therefore, Nostr does not offer a direct-to-consumer product for users but focuses on implementing the necessary social infrastructure at the protocol level. The capability for productization is provided by third-party apps, and users of different apps can interact socially with each other.

The advantage of Nostr lies in its provision of a truly free and open social network, unaffected and unthreatened by any centralized power or interests. Users can freely express their opinions and beliefs without fear of censorship, bans, or deplatforming; content creators can freely set their incentive models without worrying about being deprived of income or facing unfair competition. Nostr users can also freely choose their social circles without fear of manipulation, misinformation, or privacy infringement.

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

Decentralization : Nostr does not rely on any centralized servers or platforms, but instead uses the Bitcoin network for information transmission and storage. This ensures users do not have to worry about data theft, censorship, or deletion, and are not subject to the rules or policies of any third parties.

Autonomy : Nostr allows users to control their own data and identity. Users can freely choose whom they want to follow and trust, and express their views and ideas without fear of being banned, blocked, or downgraded, and without suffering from advertisements or recommended content interference. The verifiability of specific users also makes it easier to identify spam and bot-generated content.

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 their own nodes (servers that can forward and store Nostr information). Users can also create and use different types and tags, which are metadata used to differentiate and categorize Nostr information. The simple and flexible Event format supports various types of publishing: social media posts, long-form content, rich media, e-commerce, etc. Moreover, Nostr’s integration with the Lightning Network has facilitated a new value-for-value, fairer business model.

Security Concerns of the Nostr Protocol

Private Key Management

The Nostr protocol utilizes public-private key pairs for accounts, requiring users to properly manage their private keys. Once lost, the private key cannot be recovered. This may pose a challenge for most users, who might lack the technical knowledge and experience to securely manage private keys.

Relay Selection

In the Nostr protocol, users must choose and verify relays on their own. Choosing an unreliable or malicious relay could result in their information being leaked, tampered with, or deleted.

Information Dissemination

In the Nostr protocol, the information sent by users does not propagate across multiple relays. This means if their information is not received and stored by a sufficient number of relays, it could be lost or unseen by other users, exacerbating the issue of information silos.

Relays’ Discretionary Information Storage

Relays in the Nostr protocol can freely decide whether to receive and store users’ information. This might lead to some relays choosing only to receive and store information they deem valuable or align with their interests, while ignoring or rejecting other information.

Malicious Protocol Extensions

While the Nostr protocol defines some basic event types and functionalities, it also allows clients and relays to selectively implement additional features. This could lead to the implementation of insecure or malicious functionalities by some clients and relays, affecting users’ security and privacy.

Handling of Information

Due to the lack of a consensus layer in the Nostr protocol, some relays do not process messages with a significant difference in timestamps and UNIX time, leaving room for clients to exploit this discrepancy to forge messages.

Overview of the Nostr Ecosystem

Jack Dorsey, co-founder of Twitter and a major supporter of the Nostr protocol, donated 14.17 Bitcoins (approximately $245,000) to support its development in December 2022. His X profile prominently displays his personal Nostr address, indicating his fondness for the protocol.

Damus⚡️: Main applications of Nostr protocol

X：https://twitter.com/damusapp

Damus is a social app that supports Bitcoin tipping via the Lightning Network, replacing the common ‘Like’ or thumbs-up with tipping. The low transaction fees of the Lightning Network make tipping virtually cost-free. Besides Damus, the Nostr protocol’s applications include communication tool Anigma, text sharing tool Sendtr, and online chess game Jeste, among others.

Main Media Partner of the Nostr Protocol: TGFB

TGFB is a Christian Bitcoin education platform aimed at educating and equipping Christians to understand Bitcoin and use it to glorify God and benefit humanity. A significant portion of its content is dedicated to promoting the Nostr protocol through podcasts hosted by Jon and Jordan, exploring the protocol’s implications from a Christian perspective. The combination of Christianity, widely known in the US and globally, the SEC-approved Bitcoin ETF, and the Nostr protocol built on the vast Lightning Network user base, is expected to significantly promote the adoption and support of the Nostr protocol.

Nostr Derivative Protocols

Nostr + Taproot assets

The Nostr Assets Protocol is an open-source protocol that integrates Taproot assets and native Bitcoin payments (denominated in Satoshis) into the Nostr ecosystem, supporting interactions with other payment protocols including the Lightning Network and Taproot assets.

Once assets are introduced, they can be sent and received using the Nostr protocol’s public and private keys, with settlement and security still reliant on the Lightning Network. The Nostr Assets Protocol, while built on Nostr’s technology, is a distinct protocol that facilitates basic transactional functions through Nostr messages.

The full custodial service of the Nostr Assets Protocol involves users depositing their Bitcoin or other assets into a wallet controlled by the protocol, and then executing token deployment, minting, and transfer instructions through Nostr messages.

However, the full custodial service is controversial due to potential security risks. Users cannot fully control their assets, and in the event of a platform breach or exit scam, they could lose all their assets.

Moreover, following its launch on October 30, Nostr experienced high demand for asset deposits, leading to frequent site maintenance and shutdowns, raising concerns about the team’s background and the project’s reliability. On November 8, the Nostr Assets Protocol officially responded to a comment in Chinese on a tweet, with some users still questioning the project’s credibility. The Nostr community has expressed strong opposition to the token associated with this extension protocol.

Nostr + Inscription

Noscription is an experimental token protocol based on Nostr, allowing users to create and trade brc-20-like tokens, distinct from Taproot assets tokens.

Comparative Analysis

Protocol Implementation

• BitVM demands extremely high computational capabilities and currently only exists in theory. In terms of commercial implementation, RGB has a significant advantage with numerous applications already in use. (The technical organization behind RGB, LNP/BP, has few developers and is non-profit, leading to slow development progress). Nostr , hindered by the common bottlenecks of SocialFi, has similarly failed to further advance the application ecosystem of its protocol.

  Privacy Protection

• Both RGB and BitVM perform computations off-chain, but the RGB protocol ensures that third parties cannot track the history of RGB assets on the blockchain. Only when a user receives an asset do they learn its history, a feature not achievable by BitVM. The Nostr protocol, being a social protocol, has a high degree of uncertainty in the relaying of information, potentially leading to information leaks, blockages, losses, and malicious tampering due to vulnerabilities.

  Native BTC Compatibility

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

  Protocol Security

• The RGB protocol operates off-chain in a sandbox environment, ensuring data security. Its invoicing system also guarantees data security from a design perspective. In terms of interaction with BTC, it uses a mechanism similar to the Lightning Network for asset issuance.

• BitVM uses a Rollup model, executing data off-chain as well. The characteristics of the virtual machine, combined with fraud proofs and a challenge-response model, ensure BitVM’s security.

• Nostr uses a relay model, where the ingenious design of information transmission between relays and encryption algorithms ensures the security of information within the Nostr protocol.

In the Web3 industry, there has been no laboratory specifically focused on the security of the Bitcoin ecosystem until the establishment of BTC Security Lab , which fills this gap by providing professional security support and research for the Bitcoin ecosystem. ScaleBit and BiHelix aim to lead the race in Bitcoin ecosystem security, setting security standards for the industry and promoting the healthy development of the ecosystem.

Ecosystem and Commercialization

• As a social protocol, Nostr exceeds both BitVM and RGB in user base and traffic popularity, making its ecosystem protocol expansion and application commercialization more comprehensive than the other two.

• The RGB protocol has been around for a while, with many projects currently awaiting the release of RGB V0.11.

• BitVM has only released its whitepaper a few months ago, and its ecosystem is still under development.

The future of these three protocols is expected to spawn numerous Dapps in the realms of SocialFi, GameFi, and DeFi, bringing a new wave of popularity to the BTC ecosystem.

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

Disclaimer：

1. This article is reprinted from[chaincatcher]. All copyrights belong to the original author [浙大链协，BiHelix，ScaleBit & BTC Security Lab]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.