Explaining RGB protocol with Bitcoin: tokenisation done right
RGB is still a mysterious protocol in the Bitcoin community because it is difficult for Bitcoiners to wrap their heads about it, I think a good way to explain it is to show how RGB allow you to take a fresh look at what Bitcoin is technically.
RGB is single-use seals management
A single-used seal proves the unicity and integrity of the message if they are secure. It is a "commit to commit". It makes a message more "legitimate" at a certain place and time than any other. A single-use seal tells you if a message was truely commited before being broadcasted, no other message will have the same commitment.
Does it remind you something ? Double-spend ! The problem of double spend is that we don't know which of two conflicting transactions is the most legitimate. Single-used seals are a solution. They tell you securely which transaction should be seen as the first.
Definition of single-use seal
We say something is a single-use seal if it has two features:
- The owner can use a method/action "Close" which given a seal and a message returns something called a witness
- There is another method/action "Verify" which given a seal, a message and a witness return True only if the witness was the output of a "Close" method applied on the seal and message.
We say the single-use seal is secure if two messages and witnesses such that "Verify" is True implies they are in fact the same message and witness. This is what makes the seal "single-use": there is only one message for which "Verify" can return True.
Ok, this is quite abstract because we didn't say what a single-seal could be or "how it looks like". Some real life examples:
- A paid annoncement in a page of "the Times" journal of the 3 january 2009 is a single-use seal. You "close" the seal over a message (the content of the annoncement) when the journal is published and the journal becomes the witness. This seal is secure under the assumption that there is only one Times' journal a day. The seal's owner is "The Times" company.
- An event wristband is one too. It is closed on your wrist (you are the message) when you enter the party the first time and the witness is that the event staff which owned the seal can see by its design that it is attach to you. This seal is secure if there is no way to transfer it to someone else without destroying it or copy the design (here it is secure enough if you can't copy it for the duration of the event).
Now you may say that all of this is "physical" and ask if a "digital" version of a single-use seal exist:
Digital signatures as single-use seal
Let say someone generally trusted publicly proposes you to sign a message with its key using a determined nonce. Then his public key and the nonce are the seal ! By giving him a message to sign, he will return you his signature using the predetermined nonce, this is the witness, and the seal is now closed if we assume this nonce will never be reused. The classical verification of digital signatures is exactly the "Verify" method of the seal. If he closes the seal on two differents messages (meaning he signed both), then both signatures can be used to compute his private key because of nonce reuse. This means the seal is secure if we assume that the trusted third party don't want to reveal the private key: this is exactly how Discreet Log Contracts handles the breach case !
The embarassing need of trust
Ok so single-used seal can exist in the "digital realm". It tells you that this message is a legitimate version of the truth as real life examples: the annoncement written in the Times is the more "official" message, you carry the event wristband so you can freely goes in and out the event, the message signed by the third-party is the only one you gave him to sign...
So why not using "digital" seal described above to solve Bitcoin double spend problem ? We have a way to create "digital" single-used seals if we assume the spender doesn't want to revealing his private key.... But ... but you must trust the seal's owner ! Maybe he will earn more by defrauding you than by revealing the private key, and you can't trust the one who must pay you to not try to revert the payment ! Those digital single used seal are limited by trust .... How can we solve that ? Let's look at how Bitcoin does it.
Thank you for this good summary. I'm a big fan of RGB.
As far as I understand, RGB's security is finally attributed to publisher nodes (Notary nodes).
When a possession of an asset is with a proof (route proof on the DAG in publisher nodes), it's need to be legitimatized by a fact another publisher node cannot submit a proof of state destruction. (https://github.com/rgb-archive/spec/blob/develop/01-OpenSeals.md#proof-of-state-destruction)
The ability to show the state destruction requires being with data availability to make the conflicting proof, and this can be difficult when the colluded nodes do not provide this to others.
So if any good node can provide a proof of state destruction everything will be fine, but proof of state destruction can be hidden by colluded nodes, and this is finally same situation for a threshold( like 1/3) of BFT protocols like these in DPoS or consortiums. What do you think?
What is cool of RGB is how this work on LN imo.
The p2p commitment on LN can be used for an agreement to a state. If anything wrong about agreements, the pair can finalize last agreement just with the channel close transaction on LN. I think this enhances a lot of LN functions like what you said about DeFi.