Nostr Binding Protocol

If available, help parse the transaction and submit it to the CKB chain for unlocking. Transaction fees can be paid by reserving part of the balance as a fee Cell.

User: Requires a Nostr account and CKB

1. Index the CKB Cell and calculate the TYPE_ID of that Cell
2. Use TYPE_ID to generate a Nostr asset Event with a Nostr signature
3. Use the Nostr asset Event to generate a CKB binding transaction and send it to the chain

User: Requires a Nostr account, Bitcoin wallet, and satoshis

1. Index the UTXO, generate a mapping Cell via RGB++, and calculate the TYPE_ID of that Cell
2. Use TYPE_ID to generate a Nostr asset Event with a Nostr signature
3. Use the Nostr asset Event to generate a CKB binding transaction and send it to the chain

User: Requires a Nostr account

• Index the Cell on CKB that you want to unlock using the Nostr lock Script
• Construct a CKB transaction to replace this Cell with another lock Script
• Use the result from step 2 to generate a Nostr unlock Event via the Nostr client/browser extension
• Send the Nostr unlock Event to a special relay group and submit it to the chain

User: Requires a wallet corresponding to the other lock, no Nostr-related operations needed

Simply follow the normal process on CKB/RGB++ to unlock and transfer.

The main advantage of the Nostr binding protocol is its simplicity and directness. This simplicity also makes it easier for client developers to build products on top of it. On the other hand, the downside of the Nostr binding protocol is scalability issues. With this simple design, the throughput of Nostr tokens is bound to the CKB blockchain, making the CKB blockchain a bottleneck. Considering Nostr as a more flexible social network aimed at mass adoption, this throughput could become an issue when a large number of users interact with these native assets in the future.

However, we see some options to address this issue:

1. Integration with the CKB Lightning Network

Since the Nostr native assets created by the Nostr binding protocol can be considered ordinary CKB assets, once the CKB Lightning Network is launched, we can leverage it to scale the Nostr binding protocol. The Nostr binding protocol itself does not require any changes, making this a free feature. The downside is the need to wait for the CKB Lightning Network to launch.

1. Implementing Simple but Useful Payment Channels

Another option before the CKB Lightning Network is launched is to implement some very simple but useful payment channels, such as the Spillman channel. The Spillman channel is a one-way payment channel that is simpler to implement. The channel has a payer and a payee. For the blockchain, this type of payment channel may not be very useful, but in the case of the Nostr binding protocol, it is very suitable for a subscription model between content creators and their followers.

1. N-to-1 Binding Instead of 1-to-1 Binding

Instead of creating a 1-to-1 binding, we can create an N-to-1 binding between Nostr Events and CKB Cells. In other words, we bundle multiple events into one cell to achieve scalability. This will make the on-chain mapping storage cost much smaller than the off-chain Nostr Event. However, the problem with N-to-1 binding is that it requires designing a new model to control and split the ownership of bundled events. This will be more complex and require additional design and implementation work.

1. RGB-Style Solution

Another way to achieve ultimate scalability is to create an RGB-style solution, using CKB Cells as one-time seals and making the Nostr protocol an implementation layer similar to the RGB protocol. This solution can choose to implement only the token standard, excluding the general smart contract concept from the original RGB protocol, thereby simplifying the workflow.

Why Choose Nostr?

Nostr is an ideal layer for mass-market applications based on cryptography. It is a super simple, direct, practical, unbiased, and easy-to-integrate information distribution protocol. Many web3 projects may use things like Arweave and IPFS, which hold completely different values and philosophies. You can think of Nostr as a super loose protocol, without an obsession with fully decentralized P2P networks, nor an overcommitment to token economics and incentive mechanisms that have long existed in the web3 world, making Nostr more practical and unbiased.

Why Not Use Blockchain Assets Directly?

Allowing users to issue their own native assets based on Events in the Nostr network, rather than directly using existing blockchain tokens in the Nostr network, is mainly based on the simple fact that tokens are meaningless without creating value. For consumer products, most blockchain assets will only add friction to the product workflow without adding value to the product. Instead of imposing token mechanisms on the product, it is better to look at what users need and what blockchain can help with from the user's perspective. We believe that native assets based on Events fit this methodology. Application developers and users can see what they can do with assets from their own perspective, rather than forcing them to accept existing blockchain assets and rules. Additionally, assets based on Events are easier to seamlessly collaborate with the Nostr protocol, bringing new ways to play for existing Nostr ecosystem products and tools.

Why Choose CKB?

Due to the programmability of CKB, it is much easier to implement the binding protocol using CKB. Bitcoin is much harder. Additionally, considering the unique way CKB is bound to BTC, it will be easier to bind to BTC after binding to CKB first.

Overall, Nostr, as a simple and practical information distribution protocol, is very suitable for mass adoption of consumer applications. The programmability of CKB and its binding relationship with Bitcoin make it an ideal choice for implementing the Nostr binding protocol. At the same time, issuing native assets based on Nostr Events can design new product mechanisms from the application perspective, allowing Nostr to compete with other traditional internet applications and find its unique PMF.