Contract Transfers
Last updated
Last updated
contractsIn this section we will be guided through a step-by-step RGB Contract Transfer operation, again with the cooperation of our cryptographic couple: Alice and Bob. We will also provide some coding sections of both our characters, which use the rgb Command Line Interface Tool which can be installed from the dedicated RGB library.
Let's start with Bob, who owns a Bitcoin wallet but has not yet started using RGB technology.
1) To begin operating with RGB protocol, Bob must install an RGB wallet. This startup process involves installing the RGB wallet software, which usually, by default, contains no contracts. The RGB wallet software, in addition, requires the ability to interact with Bitcoin UTXO through a Bitcoin wallet and a Bitcoin Blockchain node tool (a full node or an Electrum Server). These tools are a mandatory requirement because, as we learned previously, owned states are defined over Bitcoin UTXO and represent a necessary item for state transitions implementing transfers of contract in RGB.
2) Then, Bob has the task of acquiring the necessary information about the contracts. These data, in the RGB ecosystem, can be sourced through various channels, such as specific websites, e-mails, or Telegram messages, etc, following the contract issuer's choice. These data are distributed using a contract consignment which is a data package containing Genesis, Schema, Interface, and Interface Implementation.
Each of these parts, usually, consists of as little as 200 bytes of data, meaning a consignment is typically of the order of a few KiBs. The contract consignment can also be encoded in Base58 format and sent in a format similar to that of a PGP key or as a QR code. This kind of format In the future will also be easily adaptable to censorship-resistant transmission media such as Nostr, through the use of relay servers, or over the Lightning Network.
In this regards, it's useful to point out that the RGB ecosystem fosters innovation and competition among various wallets by allowing the freedom to propose new methods of contract interaction and transfer. This openness to experimentation and the adoption of new technologies, such as decentralized, censorship-resistant networks, promises to further enrich the capabilities offered by RGB.
3) Once a contract is obtained in consignment format, Bob is able to import it into his RGB wallet and validate the data contained herein. The next thing he can do is to find someone possessing the contract / asset he is interested in receiving in his wallet. In our example, Alice possesses the asset in her wallet. So, similarly to Bitcoin Transaction they can setup an RGB Transfer. The mechanism for discovering stakeholders who have owned states in the contract, such as Alice, remains up to the receiving party, just as the process for discovering who can pay in Bitcoin.
4) In order to initiate a transition, Bob must act first. It does so by issuing an invoice that calls the specific transfer method encoded in the Schema of the contract and which he will hand over to Alice. This invoice generation, which precedes the effective asset transfer, guarantees that the invoice contains all the relevant instructions needed by Alice to make the transfer, containing in particular Bob's UTXO derived from his Bitcoin wallet encoded in blinded form or in clear. To generate the Invoice to be handled to Alice, he can use the rgb command line tool issuing a request e.g. over interface RGB20 an amount of 100 assets of a certain contact (for example 100 USDT), which will be assigned to one of his UTXOs identified by Txid and :vout using Tapret form, by typing the following code:
5) Invoices, which are described in more detail in this chapter, are generated as simple URL strings and can be transmitted by any means in a manner similar to what we said for consignment.
6) Alice, who has both a Bitcoin wallet and an RGB wallet with a stash of client-side validated data, receive the Invoice from Bob, which appears to be a string like this:
rgb:2WBcas9-yjzEvGufY-9GEgnyMj7-beMNMWA8r-sPHtV1nPU-TMsGMQX/RGB20/100+utxob:egXsFnw-5Eud7WKYn-7DVQvcPbc-rR69YmgmG-veacwmUFo-uMFKFb , where Bob's UTXO has been blinded automatically in the generation process (for Invoice encoding see the related chapter).
7) First, Alice prepares a PSBT transaction which spends the UTXO containing the seal definition which assigns the ownership of the RGB asset to her. The following represents the generic shell command of a wallet utility in order to construct the transaction which will be modified later:
8) Then Alice, through a shell command, is now able to generate terminal consignment consignment.rgb that contains, according to the instruction of Bob's <invoice> :
The final RGB state transition client-side data.
The history of state transitions since contract genesis and contained in validated form in Alice's stash.
The unsigned version of the witness transaction, elaborated from the tx.psbt file, which:
Spend Alice's single-use seal related to the asset being transferred.
Contains in some first Opret / Tapret output the DBC commitment related to the state transition to Bob, in addition to necessary "blank" state transitions if some additional assets where defined on the same single-use seal being spent by Alice.
9) This terminal consignment, obviously larger than a contract consignment because of the inclusion of the entire history of the asset, is then forwarded to Bob, even though the related witness transition has not yet been broadcasted into the Bitcoin P2P Network.
10) Bob, at this point, using the rgb accept command proceeds at validating the transfer consignment. If the validation is successful:
Adds all the data to his stash.
Produce a signature of the validation process.
11) After verifying the data contained in the transfer consignment handed over by Alice, Bob may optionally send to Alice the produced signature sig: to Alice, in a so-called payslip, which confirms her that Bob:
Agrees on the validity of the client-side validated data included in the consignment.
Agrees that the witness transaction shall be published.
12) Alice, by receiving the payslip:
May validate Bob's signature.
Publishes the witness transaction contained in the modified tx.psbt file using her wallet tool.
Once published, the witness transaction represents the conclusion of the transfer between Alice and Bob.
The following diagram represents a summary of all the operations just described:
Finally, the following diagram shows an example of transfer interaction between the various elements of the RGB technology stack composed of RGB wallets, RGB nodes, and Electrum Server.
The approach adopted by RGB in transferring consignments between parties, as illustrated in the Alice and Bob example, underscores the significance of privacy and security.
In the ideal case, no one other than Bob and Alice is in possession of the consignment and witness transaction. Nonetheless, Bob has all the elements to verify the validity of the consignment by comparing it with the various anchors on the Bitcoin Blockchain. Bob's stash status is consequently updated through this consignment decomposition and validation procedure. In practical transfer cases, Alice may publish the witness transaction to be included in the blockchain only when some events have occurred, such as, for example, the transfer of some object from Bob.
In this regard, it's useful to point out that the RGB system offers a significant advantage over other digital exchange methods, especially when it comes to complex operations such as atomic swaps. Atomic swaps, commonly used in various cryptocurrency networks, such as the Lightning network, can present complications. Typically, they require two separate transactions and the use of a hash code to ensure that both parties complete the swap almost simultaneously. This process can create a situation where one party has the power to influence the timing of the exchange by revealing or withholding the hash code, which is known as the reverse American call option problem.
RGB simplifies this issue considerably. Instead of requiring two separate transactions, RGB allows the direct exchange of one asset against another (e.g., Bitcoin against an RGB asset or an RGB asset against another RGB asset) within a single transaction. This eliminates the need for a hash code, as both assets can be exchanged directly. If an exchange involves Bitcoin and RGB assets, both can be included in the same witness transaction output, making the process more direct and secure.
In addition, RGB introduces a mechanism that allows both parties to have complete control over the execution of the transaction. If the transaction is not published, both parties have the option to do so, ensuring that neither can take advantage at the expense of the other. If both parties fail to publish, the original inputs can be spent again, rendering the transaction invalid. This approach offers a higher level of security and flexibility than traditional methods while simplifying the exchange process.
