RGB Docs
  • RGB Protocol Documentation
  • Distributed Computing Concepts
    • Paradigms of Distributed Computing
    • Client-side Validation
    • Single-use Seals and Proof of Publication
  • Commitment layer
    • Commitment Schemes within Bitcoin and RGB
    • Deterministic Bitcoin Commitments - DBC
      • Opret
      • Tapret
    • Multi Protocol Commitments - MPC
    • Anchors
  • RGB State and Operations
    • Introduction to Smart Contracts and their States
    • Contract Operations
    • Components of a Contract Operation
    • Features of RGB State
  • RGB Contract Implementation
    • Schema
      • Schema example: Non-Inflatable Assets
  • RGB over Lightning Network
    • Lightning Network compatibility
  • Annexes
    • Glossary
    • Contract Transfers
    • Invoices
    • RGB Library Map
Powered by GitBook
On this page
  1. Commitment layer

Deterministic Bitcoin Commitments - DBC

For RGB commitment operations, the main requirement for a Bitcoin commitment scheme to be valid is that:

The witness transaction must provably contain a single commitment.

With this requirement, it is not possible to construct an "alternative history" related to client-side data commitment in the same transaction. Thus, the message around which the single-use seal is closed is unique. To meet the above requirement, regardless of the number of outputs in a transaction, one and only one output contains a valid commitment (either Opret or Tapret):

The only valid output that can contain an RGB message commitment is the first DBC-compatible output, i.e. the first that has either:

  1. an OP_RETURN spending script; in this case it will encode its Opret commitment there

  2. a taproot spending script; in this case it will encode its Tapret commitment in the corresponding taproot tree

It is worth observing that a transaction only contains either a single Opret OR a single Tapret commitment in the first applicable output. This approach guarantees uniqueness of the seal closing strategy without committing to it at seal creation, allowing to avoid the complexity of transfers involving multiple commitment schemes. This means that, in case a witness transaction contains both a taproot and an OP_RETURN output, the second one will be ignored by the RGB validation.


PreviousCommitment Schemes within Bitcoin and RGBNextOpret

Last updated 14 days ago