### MPC Verification Example Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the verification process for an MPC commitment, showing how a verifier recomputes the tree root using a Merkle proof. ```plaintext # MPC Verification (for contract c_2 in an 8-leaf tree): # Verifier receives Merkle proof: { tH_MPC_LEAF(D), tH_MPC_BRANCH(tHA||tHB), tH_MPC_BRANCH(tHEF||tHGH) } # Verifier recomputes tree root and compares with anchor's mpc::Commitment ``` -------------------------------- ### RGB Genesis Example Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Describes the essential components of a Genesis operation, including global state (ticker, name, etc.), initial owned state allocations, SchemaId, ChainNet, and the fast-forward version. ```rust // Genesis defines: // - Global State: ticker, name, precision, issuedSupply, terms // - Owned State: initial token allocations to one or more UTXOs (seal definitions) // - SchemaId: 32-byte hash of the compiled Schema // - ChainNet: { Chain: Bitcoin, Network: Mainnet } // - Ffv: fast-forward version (starts at 0) ``` -------------------------------- ### RGB Invoice Format Examples Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the structure of RGB invoices for fungible tokens and NFTs, including breakdowns of URL components and optional signature usage. Also shows CLI generation. ```plaintext # Fungible token invoice (requesting 100 tokens with a blinded UTXO): rgb:2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o/RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU/cR/bc:utxob:x8H6O_~H-7RyndJZ-CAUUAcF-RJfWg7H-9hew6Zo-pacK97w-gaGhQ # URL breakdown: # rgb: — application identifier (protocol prefix) # 2whK8s5O-b1LG4rR-...-aba0V_o — ContractId (Base58, chunked into 6 groups of ~8 chars) # RWhwUfTMpuP2Zfx1~...V4zU — SchemaId (validates that contract implements the expected schema) # cR — requested amount encoded in Base32 (no digits alphabet) # bc:utxob:x8H6O_~H-...gaGhQ — concealed (blinded) seal definition; Bob's UTXO is hidden from Alice # NFT invoice (requesting fraction 1 of UDA token index 0): rgb:jgOr8JoA-BSmFO9S-Z0_hGE~-pV6VQf8-d0phP06-obTe8Go/~6rjymf3GTE840lb5JoXm2aFwE8eWCk3mCjOf_mUztE/1@0/bc:utxob:x8H6O_~H-7RyndJZ-CAUUAcF-RJfWg7H-9hew6Zo-pacK97w-gaGhQ # 1@0 — fraction 1 of token with index 0 # Invoice with optional signature: rgb:2whK8s5O-.../cR/bc:utxob:x8H6O_~H-...?sig=6kzbKKffP6xftkxn9UP8gWqiC41W16wYKE5CYaVhmEve # CLI generation: bob$ rgb invoice --amount 100 # Output: rgb:2whK8s5O-b1LG4rR-...-aba0V_o//cR/bc:utxob: ``` -------------------------------- ### MPC Merkle Tree Structure Example Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/multi-protocol-commitments-mpc.md Illustrates the hierarchical structure of an MPC Merkle Tree, showing branches, leaves, and the root. This diagram helps understand how commitments are organized and proven. ```text +-------------------------------+ | tH_MPC_ROOT(tHABCD || tHEFGH) | +-------------------------------+ | | +-----------------------------------------------------+ +---------------------------------------+ | | +-------------+---------------+ +-------------+---------------+ | tH_MPC_BRANCH(tHAB || tHCD) | | tH_MPC_BRANCH(tHEF || tHGH) | +-------------+---------------+ +-----------------------------+ | | +---------------------------+ +--------------+ | | +-------------+-------------+ +-------------+-------------+ | tH_MPC_BRANCH(tHA || tHB) | | tH_MPC_BRANCH(tHC || tHD) | +---------------------------+ +----------------^------^---+ | | +--------------+ +- ---+ | | +-------+--------+ +---------+------+ | tH_MPC_LEAF(C) | | tH_MPC_LEAF(D) | +-------------^--+ +-------------^--+ | +-------------------------+ | 0x10 || c_2 || BUNDLE_2 | +-------------------------+ ``` -------------------------------- ### MPC Tree Structure Diagram Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/multi-protocol-commitments-mpc.md Visual representation of an example MPC tree, illustrating the hierarchical hashing of leaf nodes up to the root. This diagram helps understand the merkelization process for contract commitments. ```text +--------------------------+ mpc:Root | th_MPC(tHABCD || tHEFGH) | +-----------^---------^----+ | | +------------------------------------------------+ +--------------------------------------------+ | +-------------+---------------+ +-------------+---------------+ | tH_MPC_BRANCH(tHAB || tHCD) | | tH_MPC_BRANCH(tHEF || tHGH) | +----------------^--------^---+ +-----------------+--------+--+ | | +---------------------------+ +--------------+ +------------------<---------+ +------------+ | | +-------------+-------------+ +-------------+-------------+ +-------------+-------------+ +-------------+-------------+ | tH_MPC_BRANCH(tHA || tHB) | | tH_MPC_BRANCH(tHC || tHD) | | tH_MPC_BRANCH(tHE || tHF) | | tH_MPC_BRANCH(tHG || tHH) | +----------------^------^---+ +----------------^------^---+ +----------------^------^---+ +----------------^------^---+ | | +--------------+ +-----+ +--------------+ +- ---+ +--------------+ + ----+ +--------------+ +-----+ | | +-------+--------+ +---------+------+ +-------+--------+ +---------+------+ +-------+--------+ +---------+------+ +------+---------+ +--------+-------+ | tH_MPC_LEAF(A) | | tH_MPC_LEAF(B) | | tH_MPC_LEAF(C) | | tH_MPC_LEAF(D) | | tH_MPC_LEAF(E) | | tH_MPC_LEAF(F) | | tH_MPC_LEAF(G) | | tH_MPC_LEAF(H) | ``` -------------------------------- ### Taproot Output Key (No Script Path Spend) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the construction of a Taproot Output Key (Q) when only an Internal Key (P) is present, signifying no pre-existing Script Path Spend. This serves as the baseline for Tapret incorporation. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | m | * | G | +---+ +---+ +-^-+ +---+ | +-------------+ | tH_TWEAK(P) | +-------------+ ``` -------------------------------- ### RGB ContractId Derivation Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Shows how to derive the ContractId from the Genesis OpId by reversing the bytes and applying Base58 encoding. An example ContractId is provided for illustration. ```rust // ContractId = Base58(reverse_bytes(genesis_OpId)) // Example: "2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o" (chunked for readability) ``` -------------------------------- ### Taproot Output Key Structure (No Tapret) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the structure of a Taproot output Key 'Q' with a Spend Key Path and a 3-script tree in the Spend Script Path, before Tapret incorporation. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | +----------------------------+ | tH_TWEAK(P || Script_root) | +---------------------^------+ | +-------------+----------+ | tH_BRANCH(tHAB || tHC) | +------------^-------^---+ | | +---------+ +---------+ | | +------------+----------+ +------+-----+ | tH_BRANCH(tHA || tHB) | | tH_LEAF(C) | +------------^------^---+ +------^-----+ | | | +------+ +------+ | | | | +-----+------+ +-----+------+ | | tH_LEAF(A) | | tH_LEAF(B) | | +-----^------+ +-----^------+ | | | | +-+-+ +-+-+ +-+-+ | A | | B | | C | +---+ +---+ +---+ ``` -------------------------------- ### Taproot Output Key Structure (With Tapret) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Shows the modified Taproot Output Key 'Q' structure after incorporating the Tapret commitment at the 1st level of the Script Tree. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | +--------------------+ | +---------------+------------+ | tH_TWEAK(P || Script_root) | +---------------------^------+ | +--------------+----------+ | tH_BRANCH(tHABC || tHT) | +-------------^-------^---+ | | +-------------------------------+ +-------+ | | +----------+-------------+ +-----------------+--------------------+ | tH_BRANCH(tHAB || tHC) | | tH_BRANCH(64_byte_Tapret_Commitment) | +------------^-------^---+ +--------------------------------------+ | | +---------+ +-----------+ | | +------------+----------+ +------+-----+ | tH_BRANCH(tHA || tHB) | | tH_LEAF(C) | +------------^------^---+ +------^-----+ | | | +------+ +------+ | | | | +-----+------+ +-----+------+ | | tH_LEAF(A) | | tH_LEAF(B) | | +-----^------+ +-----^------+ | | | | +-+-+ +-+-+ +-+-+ | A | | B | | C | +---+ +---+ +---+ ``` -------------------------------- ### RGB Single-Use Seal Operations (Pseudocode) Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the three core operations of a single-use seal: defining, closing, and verifying. In RGB, seals map to Bitcoin UTXOs, closing involves spending the UTXO and committing to an MPC tree root, and verification confirms the witness transaction's commitment. ```pseudocode # Pseudocode representing the three seal operations seal <- Define() # Alice creates a promise to commit once, pointing to a UTXO witness <- Close(seal, message) # Alice spends the UTXO and embeds a hash of the RGB message # into the witness transaction (via Opret or Tapret) bool <- Verify(seal, witness, message) # Bob checks that the seal was closed exactly once, # and that the witness transaction contains the correct # commitment to the message # In RGB, seal definitions map to Bitcoin UTXOs: # - seal definition = a specific Bitcoin UTXO # - seal closing = spending that UTXO and committing to an MPC tree root # - seal verification = validating that the witness tx contains the correct DBC output ``` -------------------------------- ### Generate RGB Transfer Consignment Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Create a transfer consignment file that includes the state transition history and the unsigned PSBT with RGB anchor. This consignment is sent to the recipient. ```bash alice$ rgb transfer tx.psbt rgb:2whK8s5O-...-aba0V_o/RWhwUfTM.../cR/bc:utxob:x8H6O_~H-...-gaGhQ consignment.rgb ``` -------------------------------- ### Generate RGB Invoice with CLI Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/annexes/contract-transfers.md Use the rgb CLI tool to generate an invoice for a specific contract, requesting a certain amount of assets. This invoice contains instructions for the recipient to make the transfer. ```sh bob$ rgb invoice --amount 100 ``` -------------------------------- ### Bundle ID Construction Flowchart Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/annexes/commitments.md Illustrates the process of constructing a Bundle ID by hashing the input map of assignments. Known transitions are not included in the Bundle ID. ```mermaid flowchart TD subgraph Discarded id((" ")) end subgraph TransitionBundle inputMap knownTransitions end inputMap -- encode \n hash --> BundleId knownTransitions --x Discarded ``` -------------------------------- ### Taproot Output Key (With Script Path Spend) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Shows the modification of the Taproot Output Key (Q) to include a Script Path Spend with a Tapret commitment. This involves a modified tweaking factor and a script root derived from the commitment. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | +----------------------------+ | tH_TWEAK(P || Script_root) | +---------------------^------+ | +-------------------------+------------+ | tH_BRANCH(64-byte_Tapret_Commitment) | +--------------------------------------+ ``` -------------------------------- ### MPC Tree Construction Algorithm Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Outlines the algorithm for constructing an MPC tree, including determining the minimum depth, finding a suitable cofactor, and retrying with increased depth if necessary. ```plaintext # Tree construction algorithm: # 1. Start with smallest depth d such that 2^d > C (minimum depth = 3) # 2. Try cofactor values 0..w/2 (capped at 500) until all C contracts have distinct positions # 3. If no cofactor works, increment d and retry ``` -------------------------------- ### RGB State Transitions in Lightning Network Funding Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the structure of a funding transaction for a Lightning Network channel that includes an RGB state transition. This involves a standard Bitcoin multisig output and an OP_RETURN or Taproot output for the RGB anchor. ```plaintext # Lightning channel lifecycle with RGB assets: # 1. FUNDING TRANSACTION # - Standard Bitcoin 2-of-2 multisig output (channel UTXO) # - RGB state transition sending assets to the multisig UTXO # - OP_RETURN output (or Taproot output) containing the RGB anchor # Example: Alice opens channel with Bob providing 10,000 sats + 500 USDT ``` -------------------------------- ### RGB Rust Crates Dependencies Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Lists the necessary dependencies in Cargo.toml for building projects on top of the RGB protocol, covering various aspects from consensus to API and tooling. ```toml # Cargo.toml dependencies for building on top of RGB: [dependencies] rgb-consensus = "*" # Core consensus types: Schema, Genesis, Transition, Anchor, MPC # https://crates.io/crates/rgb-consensus rgb-ops = "*" # Higher-level operations: consignment construction/validation # https://crates.io/crates/rgb-ops rgb-invoicing = "*" # Invoice encoding/decoding (rgb: URL format) # https://crates.io/crates/rgb-invoicing rgb-api = "*" # Wallet integration API # https://crates.io/crates/rgb-api rgb-psbt-utils = "*" # PSBT manipulation for embedding DBC commitments # https://crates.io/crates/rgb-psbt-utils rgb-cmd = "*" # rgb CLI tool (invoice, transfer, accept, check commands) # https://crates.io/crates/rgb-cmd rgb-schemas = "*" # Standard contract schemas: NIA (fungible), UDA (NFT), etc. # https://crates.io/crates/rgb-schemas rgb-aluvm = "*" # AluVM register-based VM for contract validation scripts # https://crates.io/crates/rgb-aluvm rgb-strict-types = "*" # Strict type system for deterministic data encoding rgb-strict-encoding = "*" # Strict serialization (deterministic, byte-aligned) # https://crates.io/crates/rgb-strict-types rgb-ascii-armor = "*" # .rgba armored encoding for binary RGB objects (schema, consignment) # https://crates.io/crates/rgb-ascii-armor ``` -------------------------------- ### Check Signature and Publish Transaction Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/annexes/contract-transfers.md Alice uses the signature provided by Bob to check its validity. Subsequently, she publishes the witness transaction to the Bitcoin network to finalize the transfer. ```bash alice$ rgb check alice$ wallet sign —publish tx.psbt ``` -------------------------------- ### Tapret Commitment Uniqueness Proof (tHABC < tHT) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the Taproot output key structure when the hash of the Tapret commitment (tHT) is greater than the top-level hash of the Script Path Spend (tHABC), placing the commitment on the right side of the script tree. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | ``` -------------------------------- ### RGB Consensus Change Mechanisms Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Explains the 'fast-forward' and 'push-back' update mechanisms for RGB contracts, detailing their properties, use cases, and implications for wallet compatibility. ```plaintext # Fast-forward update (some previously INVALID rule becomes VALID): # # Use case example: enabling a new assignment type or increasing a size limit # Tracked via: Ffv (fast-forward version) field in every Contract Operation (2-byte integer) # # Properties: # - Existing owners are NOT affected # - New beneficiaries MUST upgrade their wallets to process new operations # - Analogous to a Bitcoin soft-fork in directionality but NOT a network-wide consensus change # - Scoped entirely to the contract level # # Example: contract at Ffv=0 introduces Ffv=1 to allow a new transition type # Old wallets: can still validate Ffv=0 history; reject Ffv=1 operations # New wallets: validate both Ffv=0 and Ffv=1 operations # Push-back update (some previously VALID state becomes INVALID): # # Properties: # - Existing owners CAN LOSE ASSETS if they upgrade their wallet software # - This is effectively a NEW incompatible protocol — not an update to the same RGB version # - Requires issuers to reissue assets on the new protocol # - Users need two separate wallet instances for old and new protocol versions # - Analogous to a hard-fork: the old and new chains diverge permanently # # Recommendation: avoid push-back updates; prefer fast-forward upgrades ``` -------------------------------- ### RGB Commitment ID Hashing and Types Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the BIP-340-style tagged hashing for RGB commitment IDs and lists various commitment types with their URN tags and construction procedures. ```rust // All RGB commitment IDs use BIP-340-style tagged hashing: // hash = SHA-256(SHA-256(tag) || SHA-256(tag) || data) // Summary of commitment types and their tag URNs: // SchemaId — uniquely identifies a compiled schema // Procedure: strict serialization of all schema fields // Tag: "urn:lnp-bp:rgb:schema#2024-02-03" // OpId — uniquely identifies a Genesis or State Transition // Procedure: via OpCommitment structure (concealed assignments + merklized collections) // Tag: "urn:lnp-bp:rgb:operation#2024-02-03" // ContractId = Base58(reverse_bytes(genesis OpId)) // BundleId — uniquely identifies a Transition Bundle // Procedure: SHA-256 of strict-serialized input_map (known_transitions excluded) // Tag: "urn:lnp-bp:rgb:bundle#2024-02-03" // SecretSeal — concealed form of a BlindSeal // Procedure: SHA-256 of (txptr || vout || blinding) // Tag: "urn:lnp-bp:seals:secret#2024-02-03" // MerkleHash — node hash in any Merkle tree (leaves, branches, root) // Tag: "urn:ubideco:merkle:node#2024-01-31" // mpc::Commitment — final MPC tree root commitment embedded in Opret/Tapret // Tag: "urn:ubideco:mpc:commitment#2024-01-31" // OpCommitment construction (produces OpId): // flowchart: Ffv + TypeCommitment + StrictHash(Metadata) // + Merklize(Globals) + Merklize(Inputs) + Conceal+Merklize(Assignments) // => OpCommitment => SHA-256(tagged) => OpId // Strict Type System fingerprint example: // "RWhwUfTMpuP2Zfx1~j4nswCANGeJrYOqDcKelaMV4zU#remote-digital-pegasus" // Human-readable mnemonic suffix aids manual verification of schema identity ``` -------------------------------- ### Tapret Commitment in Script Path Spend (Leaf Case) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the integration of a tapret commitment when the old root of the Script Path Spend is a leaf node, and the tapret hash is smaller than the Script Path Spend hash. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | +--------------------+ | +---------------+------------+ | tH_TWEAK(P || Script_root) | +---------------------^------+ | +--------------+----------+ | tH_BRANCH( tHT || tHC)| +-------------^-------^---+ | | +------------------+ +------------------+ ``` -------------------------------- ### Accept Consignment and Sign Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/annexes/contract-transfers.md Bob uses this command to accept and validate the terminal consignment received from Alice. If successful, it adds data to Bob's stash and produces a signature over the consignment. ```bash bob$ rgb accept consignment.rgb sig:DbwzvSu4BZU81jEpE9FVZ3xjcyuTKWWy2gmdnaxtACrS # <— signature over consignment ``` -------------------------------- ### RGB State Transitions in Lightning Network Commitment Transactions Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Details the structure of commitment transactions within a Lightning Network channel, showing how RGB assets are allocated between parties and anchored to state transitions. Includes initial state and updates. ```plaintext # 2. COMMITMENT TRANSACTIONS (initial state: Alice=500 USDT, Bob=0 USDT) # Each party holds a version signed by the other: # - to_local output (Alice's, timelocked) # - to_remote output (Bob's, immediately spendable) # - OP_RETURN output with RGB anchor to state transition: # input: multisig UTXO (funding) # output: to_local allocation = 500 USDT, to_remote allocation = 0 USDT # 3. CHANNEL UPDATE (Alice sends 100 USDT to Bob) # New commitment transactions replace the old ones: # - OP_RETURN output with RGB anchor to NEW state transition: # input: multisig UTXO (same funding UTXO — channel is still open) # output: to_local allocation = 400 USDT, to_remote allocation = 100 USDT # - Old commitments are invalidated by exchanging revocation secrets ``` -------------------------------- ### Construct PSBT Transaction Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/annexes/contract-transfers.md Use this command to construct a Partially Signed Bitcoin Transaction (PSBT) for spending an RGB asset's seal definition. This is the first step in preparing for a contract transfer. ```bash alice$ wallet construct tx.psbt ``` -------------------------------- ### Generate RGB Invoice Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Use this command to generate an invoice for an RGB asset transfer. Specify the recipient's blinded UTXO seal definition and the amount. ```bash bob$ rgb invoice 2whK8s5O-b1LG4rR-OhXpDq1-SjyHvKx-OhTEFjQ-aba0V_o --amount 100 ``` -------------------------------- ### RGB Contract Operation Structure Diagram Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt An ASCII diagram illustrating the common structure of RGB contract operations (Genesis and State Transitions). It details fields like Ffv, ContractId/SchemaId, TransitionType, ChainNet, Metadata, Global State, Inputs, and Assignments, along with the final OpId. ```ascii # Contract Operation structure (ASCII diagram): +-----------------------------------------------------+ | Contract Operation | | | | Ffv (2B) ContractId/SchemaId (32B) | | TransitionType (16-bit, transitions only) | | ChainNet (genesis only): Chain + Network | | | | Metadata: Structured data (max 64 KiB) | | | | Global State: | [ GlobalStateType | Data ] ... | | | | Inputs (transitions only): | [ PrevOpId (32B) | AssignmentType (2B) | Index (2B) ] ... | | | Assignments (new state): | [ AssignmentType | Owned State | Seal Definition ] ... | | | | | | v v v | | (e.g. assetOwner) (Fungible/ txptr + | | Declarative/ vout + | | Structured) blinding) | | | +-------> OpId (32-byte SHA-256 tagged hash) <--------+ ``` -------------------------------- ### RGB BundleId Computation Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Illustrates the computation of BundleId using SHA-256 hashes of the bundle tag and the serialized input map. The input map is serialized in a specific format with a 16-bit count followed by Opout-OpId pairs, sorted lexicographically for deterministic output. ```rust // BundleId = SHA-256(SHA-256(bundle_tag) || SHA-256(bundle_tag) || input_map) // bundle_tag = "urn:lnp-bp:rgb:bundle#2024-02-03" // // input_map serialization: // | N (16-bit LE) | Opout_1 (32+2+2 bytes) | OpId_1 (32 bytes) | ... | Opout_N | OpId_N | // Opouts are sorted lexicographically for deterministic BundleId ``` -------------------------------- ### RGB Transition Bundle Structure Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Defines the structure for collecting all transitions for a single contract within a witness transaction. It maps spent assignments to their spending transition ID and includes a subset of transitions with revealed details. ```rust TransitionBundle { input_map: Map, known_transitions: Vec, } ``` ```rust Opout { op: OpId, ty: AssignmentType, no: u16, } ``` -------------------------------- ### Sign and Publish Witness Transaction Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Sign the PSBT and publish the witness transaction to the Bitcoin network. This step completes the RGB asset transfer once the transaction is mined. ```bash alice$ wallet sign --publish tx.psbt ``` -------------------------------- ### Tapret Commitment Structure Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Defines the exact 64-byte structure of a Tapret commitment, which includes a prefix of OP_RESERVED operators, OP_RETURN, a push byte for the commitment, the MPC commitment itself, and a nonce. This structure must be matched precisely. ```text 64-byte_Tapret_Commitment = OP_RESERVED ... ... .. OP_RESERVED OP_RETURN OP_PUSHBYTE_33 |___________________________________| |_________| |______________| |_______________| |______| OP_RESERVED x 29 times = 29 bytes 1 byte 1 byte 32 bytes 1 byte |________________________________________________________________| |_________________________| TAPRET_SCRIPT_COMMITMENT_PREFIX = 31 bytes MPC commitment + NONCE = 33 bytes ``` -------------------------------- ### Input Map Serialization Format Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/rgb-state-and-operations/state-transitions.md Describes the byte-level serialization format for the input_map, including the map size, and the structure of each map element (Opout and OpId). Opouts are sorted lexicographically. ```plaintext input_map = N Opout_1 OpId_1 Opout_N OpId_N |__________||_____________________________________||____________| ... |_____________________________________||____________| 16-bit LE 32-byte hash + 16-bit LE + 16-bit LE 32-byte hash 32-byte hash + 16-bit LE + 16-bit LE 32-byte hash |__________||___________________________________________________| ... |___________________________________________________| MapSize MapElement_1 MapElement_N ``` -------------------------------- ### Tapret Commitment in Script Path Spend (Diagram) Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the placement of a tapret commitment within a Script Path Spend when the tapret hash is smaller than the Script Path Spend hash, specifically when the old root is a branch node. ```text +---+ +---+ +---+ +---+ | Q | = | P | + | t | * | G | +---+ +---+ +-^-+ +---+ | +--------------------+ | +---------------+------------+ | tH_TWEAK(P || Script_root) | +---------------------^------+ | +--------------+----------+ | tH_BRANCH( tHT || tHABC)| +-------------^-------^---+ | | +------------------+ +------------------+ | +--------------------+-----------------+ +------------+-----------+ | tH_BRANCH(64_byte_Tapret_Commitment) | | tH_BRANCH(tHAB || tHC) | +--------------------------------------+ +------------^-------^---+ | | +------------+ +--------+ | | +------------+----------+ +------+-----+ | tH_BRANCH(tHA || tHB) | | tH_LEAF(C) | +-----------------------+ +------------+ ``` -------------------------------- ### Tapret Commitment Structure in Script Path Spend Source: https://github.com/rgb-protocol/rgb-documentation/blob/master/commitment-layer/deterministic-bitcoin-commitments-dbc/tapret.md Illustrates the hierarchical structure of Tapret commitments (tH_BRANCH and tH_LEAF) within a Script Path Spend context. This is a conceptual representation. ```text +--------------------------------------+ | tH_BRANCH(64_byte_Tapret_Commitment) | +--------------------------------------+ +------------+ | tH_LEAF(C) | +------------+ ``` -------------------------------- ### Extra Transaction Proof (ETP) Structure Source: https://context7.com/rgb-protocol/rgb-documentation/llms.txt Defines the Extra Transaction Proof (ETP) structure used for Tapret commitments, including the internal public key and partner node information for proof. ```plaintext # Extra Transaction Proof (ETP) for Tapret commitments: ETP { InternalPubKey: P # Taproot internal key PartnerNode: tHABC # right-side proof: only the top-left hash or (tHAB, tHC) # left-side proof (branch case) or tH_LEAF(C) # left-side proof (leaf case) Nonce: optional byte used to place commitment on right side of tree } ```