# RGB Authors - RGB Design (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/37896772) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[RGB Authors]] **Full Title**:: RGB Design **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [readwise.io](https://readwise.io/reader/document_raw_content/143466783) **Host**:: [[readwise.io]] **Highlighted**:: [[2024-02-20]] **Created**:: [[2024-02-22]] ## Highlights - An UTXO indeed can be seen as a seal that is closed when it is created, and opened when it is spent. ([View Highlight](https://read.readwise.io/read/01hq24jkqsbmg4cf5vkgqz7am5)) ^680437742 - Notice that the Bitcoin transactions are not connected to each other, the ownership is "teleported" from one UTXO to the other without leaving a trace in the Bitcoin transaction graph ([View Highlight](https://read.readwise.io/read/01hq24sgqfmbk194gsks5zathw)) ^680438632  - RGB uses the above described Bitcoin-based single-use-seal model, meaning that when an RGB transaction occurs, what actually happens is that the sender creates a state transition of the contract defining the rights being transferred. L ([View Highlight](https://read.readwise.io/read/01hq24xytnmyerjqcw4s0kkbrn)) ^680439038 Users transfer rights (or in another words, ownerships). - . This means that while receiving an incoming payment, an RGB client not only has to verify that the last state transition is valid, but also needs to do the same validation for all previous state transitions up the genesis state in the issuance contract. ([View Highlight](https://read.readwise.io/read/01hq250ddh9vdvebs4esasqw3n)) ^680439242 - by that time new data availability layers can be built, to allow clients to voluntarily share with each other state transition data related to specific contracts, so that future receivers can start validating part of the transaction history in advance. ([View Highlight](https://read.readwise.io/read/01hq252kwwzdacevmpbx41c5w8)) ^680439901 Data availability laters are crucial to improve user experience. - To make the commitment both versatile and secure, two conditions must be met: (i) multiple state transitions can be committed in a single Bitcoin transaction and (ii) each state transition can be committed only once in the Bitcoin transaction (otherwise double spending would be possible). ([View Highlight](https://read.readwise.io/read/01hq254vq2rxah12mxaw0tqgzt)) ^680439991 - To enable having several state transitions in one commitment, the state transitions are aggregated multiple times: first all the state transitions related to a specific contract (or asset ID) are deterministically aggregated, then all the commitments of all assets being moved are aggregated in a merkle tree and the resulting top hash is the final RGB commitment. ([View Highlight](https://read.readwise.io/read/01hq255m3bk8y53g6g01xs881q)) ^680440038  - Taproot commitment: an OP_RETURN script containing the LNPBP-4 message is added in the top right leaf of the TapTree of the first Taproot output of the Bitcoin transaction, and it will be revealed only off-chain to the receiver of the RGB transfer. ([View Highlight](https://read.readwise.io/read/01hq258vyb8rrtmmmghr3x4ave)) ^680440595 - OP_RETURN commitment: the LNPBP-4 message is inserted directly into the first OP_RETURN output of the Bitcoin transaction. ([View Highlight](https://read.readwise.io/read/01hq259sj5fnez88gvg2pngb4z)) ^680440641 - However, the batching is effective only when spending from the same UTXO, as if a user is spending from multiple UTXOs each of those outputs have to be included as input in the Bitcoin transaction, making its size and the on-chain fee it needs to pay grow. ([View Highlight](https://read.readwise.io/read/01hq2adb19413jmgdv57y9m2qg)) ^680465940 - To have the receiver of a transfer gain extra privacy from the payer RGB uses blinded UTXOs as payment outpoints instead of plain UTXOs. This means that when a user wants to be paid, instead of sharing the UTXO where he wants to receive the assets, he will share it in a blinded format which consists in the hash of the concatenation between the UTXO and a random blinding secret. ([View Highlight](https://read.readwise.io/read/01hq2aetppt9tdfvbeh8034h04)) ^680466006 - To prove during the spending phase that his UTXO is indeed the owner of certain assets, the sender needs to share with the receiver the blinding secret used to generate the blinded UTXO, so that during the validation phase it can be verified that the blinded UTXO that received the asset has been derived from the UTXO that is spending them. ([View Highlight](https://read.readwise.io/read/01hq2afc4wr34dnxrxmtpk5701)) ^680466024 - In order to hide the amount values of each state transition from the transaction history of an asset, RGB implements a zero-knowledge mechanism developed by Blockstream called Bulletproof, which is an improved and more efficient version of Confidential Transactions already used in the Liquid sidechain. ([View Highlight](https://read.readwise.io/read/01hq2ag2tevmqy4903pcm3ard8)) ^680466064 - Storm: a p2p messaging and storage system built over the Lightning Network. ([View Highlight](https://read.readwise.io/read/01hq2ah184gfgxx210vb2b6tk2)) ^680466102 - RGB proxy server: a standardised HTTP JSON-RPC server where clients can upload and download data. A user can run his own proxy server, or use the server of a third party. Relying on a third party server has privacy and censorship implications, but not security ones. ([View Highlight](https://read.readwise.io/read/01hq2ah516capbwm25ce5fxvp8)) ^680524384