RGB Magic: Client-Side Bitcoin Contracts

Federico Tenga is an opinion editorial. He has been a long-time contributor to Bitcoin projects and has experience as a start-up founder, consultant, and educator. Nick Szabo first mentioned smart contracts in 1994. He defined them as “computerized transaction protocols that execute the terms of a contract.” Although Bitcoin, due to its scripting language, supports smart contracts from the very beginning block, Ethereum promoters changed the original definition to “code that is redundantly executed at all nodes in the global consensus network”. While delegating code execution to a worldwide consensus network has many advantages (e.g. It is simple to deploy unowed contracts such as the popularly-automated market makers, but this design has one major flaw. Every node in a network must run the same code. This means that the code that can be executed without increasing the cost of running the node (and thus maintaining decentralization) is limited. Let’s take the example of a company that plans to issue shares. Instead of publishing the issuance agreement publicly on a global ledger, and using that ledger for tracking all future ownership transfers, it could issue the shares privately and give the right to transfer them to other buyers. Each new owner can then transfer the right to ownership as if it were an amended contract to the original issue contract. Each owner can verify that the shares received are genuine by reading the original contract. Then, the right to transfer ownership can be passed on to each new owner as if it were an amendment to the original issuance contract. In the U.K. it wasn’t mandatory to register property when ownership was transferred up until the ’90s. This means that over 15% of land in England or Wales is still unregistered. You will need to verify that the seller has a valid chain of ownership for at least 15 years if you want to purchase unregistered property. This is sufficient time to be able to assume that the seller holds sufficient title to the property. You must verify that the transfer of ownership was done correctly and that all mortgages have been paid in full. This model offers the advantage of increased privacy over ownership and you don’t have to rely upon the maintainer the public land registry. However, this model makes it more difficult for buyers to verify the seller’s ownership. Source: Title deed for unregistered real property. How can we improve the transfer of unregistered property? It can be digitized first. A computer can run the code to verify that ownership transfers are in accordance with the original contract rules. This makes buying and selling much more efficient and less expensive. We could, for example, establish a rule that each transfer of ownership must take place on a predetermined spot in a well-known newspaper (e.g. The hash of the ownership transfer should be placed in the upper-right corner on the first page of New York Times. Double-spending is prevented by not putting the hash of a transfer at the same spot twice. However, this method requires you to purchase a lot of newspapers in order to verify the transaction. It is not practical. Each contract requires its own space in a newspaper. It is not very scalable. The newspaper editor can easily censor and, worse, simulate double-spending. By placing a random hash into your slot, potential buyers of your asset will think it has been sold before. This discourages them from purchasing it. It is not very trust-worthy. The Bitcoin blockchain is a trusted public ledger that has strong incentives to be censorship-resistant, decentralized, and secure. However, it is not recommended that we specify a specific location in the block where ownership transfer must occur (e.g. The miner could also alter the transaction, just as with the editor of New York Times. It is better to place the commitment in a predefined Bitcoin transactions, specifically in a transaction that originates in an unspent transaction output. This will link the ownership of the asset to issue. The link between an asset, and a bitcoin UTXO, can be made in the contract that issues it or in a subsequent transfer ownership. Each time the target UTXO becomes the controller of the transferred assets. This clearly defines where ownership transfer obligations should occur (i.e. in Bitcoin transactions originating from a specific UTXO). Any Bitcoin node can independently verify the promises. Neither the miners nor any other entity can censor or interfere in the asset transfer. The seller must have a dedicated communication channel to provide proofs to the buyer that the ownership transfer is valid. You could do this in many ways. One possibility is to print the proofs and send them with a carrier bird. However, it would be a bit cumbersome. The best way to avoid privacy violations and censorship is to establish peer-to-peer encrypted communication. This is what the RGB protocol has done. It is possible to create a contract using RGB that defines rights, assigns them one or more bitcoin UTXO, and specifies how they can be transferred. A template, also known as a “schema”, can be used to create a contract. The creator of the contract will only modify the ownership rights and parameters. This is similar to traditional legal contracts. There are currently two types of RGB schemas: one for issuing fungible tokens, RGB20, and another for issuing collectibles, but in the future, anyone can create more schemas without changing the protocol. For example, a issuer of fungible assets, such as. Company shares, stablecoins, and others. You can use the RGB20 template to create a contract that defines how many tokens it will issue, its name and any additional metadata. It can then determine which bitcoin UTXO is authorized to transfer ownership of the tokens created and assign other rights to other UTXOs such as the right make a secondary issuance or renominate an asset. The Genesis contract can be verified by each client that receives tokens. It will also validate that any transfer of ownership made in the history of the tokens received has been in compliance with the rules. It allows for the issuance and transfer of tokenized assets with greater privacy and scalability than any other alternative. RGB’s privacy benefits come from the fact that all transfer data is kept client side. This means that a blockchain observer can not extract any information about a user’s financial activities. The receiver shares only blinded UTXO with the sender (i.e. the hash concatenation between a UTXO in the receiver’s wish to receive the assets) instead of the UTXO. This makes it impossible for the payer or receiver to monitor the receiver’s future activities. RGB uses the bulletproof cryptographic method to hide amounts in asset transfers history. This allows future owners of assets to have a distorted view of past holders’ financial behavior. First, the majority of the data is kept off-chain. The blockchain is used only as a commitment layer. This reduces fees and allows each client to validate only the transfers they are interested in, instead of all activity from a global network. Although an RGB transfer requires a Bitcoin transaction, it can save you a lot of fees. However, transaction batching can make them much more cost-effective. It is possible to transfer all tokens (or more commonly “rights”) associated a UTXO towards any number of recipients with a single transaction. Let’s say you are a service provider that makes payouts to multiple users at once. In RGB, you can make thousands of payments to multiple users at once by making a single Bitcoin transaction. Because an issuance contract is not required to be committed on the Blockchain, this is possible. The contract simply specifies to which UTXO new assets will be assigned. If you are an artist who is interested in creating collectible tokens, then you can issue as many as needed and only pay the transaction fee when a buyer requests the token be assigned to their UTXO. RGB is built on top bitcoin transactions and is compatible with the Lightning Network. Although it is still not implemented at the time this article was written, it will be possible for asset-specific Lightning channels to route payments through them. The RGB node is a great way to get started with the core technology. The rgblib library is a tool that allows you to create applications using RGB without having to learn the complex protocol. You can use Iris Wallet Android to issue and transfer assets. It is also open-source on GitHub. This is Federico Tenga’s guest post. These opinions are not necessarily those of Bitcoin Magazine or BTC Inc.