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
    • Contract Implementation in RGB
    • Schema
      • Schema example: Non-Inflatable Assets
    • Interface
      • Standard Interfaces by LNP/BP Association
      • Interface example: RGB20
    • Interface Implementation
  • 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

PreviousCommitment Schemes within Bitcoin and RGBNextOpret

Last updated 8 months ago

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 is valid for each commitment scheme (Opret and Tapret):

The only valid outputs that can contain an RGB message commitment are:

  1. The first output OP_RETURN (if present) for the Opret commitment scheme.

  2. The first taproot output (if present) for the Tapret commitment scheme.

It is worth observing that a transaction can contain both a single Opret and a single Tapret commitment in two separate outputs. Due to the deterministic nature of the , these commitments will commit to different client-side validated data which, as we shall see , explicitly indicate the commitment method used to refer to themselves.

Seal Definition
later