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
  • Single-use Seals in Bitcoin Transactions and RGB
  • TxO2 Client-side Validation
  1. Commitment layer

Commitment Schemes within Bitcoin and RGB

PreviousSingle-use Seals and Proof of PublicationNextDeterministic Bitcoin Commitments - DBC

Last updated 8 months ago

In this chapter we will explore the application of Client-side Validation and to Bitcoin Blockchain, introducing the main architectural features behind RGB protocol related to the commitment layer (layer 1).

As mentioned in the , these cryptographic operations can be applied in general to different blockchains and also to different publication media. However, the outstanding properties of Bitcoin consensus algorithm, particularly those related to decentralization, censorship resistance, and permissionlessness, make it the ideal technology stack for the development of advanced programmability features, such as those required by digital bearer rights and smart contracts.

Single-use Seals in Bitcoin Transactions and RGB

From the previous section, we recall that the creation of Single-use Seals is subject to two basic operations: and . We will now explore how these two operations can be implemented using Bitcoin as a publication medium and in particular making use of some elements of Bitcoin Transactions.

There are 2 main ways in which a Single-use Seal can be defined in Bitcoin transactions:

  • Public keys or addresses - the seal is defined by selecting an address or public key that has not yet been used (i.e. it has not been used by any locking script, so it is not locking any bitcoin).

  • Bitcoin transaction outputs – the seal is defined by the selection of a specific UTxO available to some wallet.

The defined methods can be used in a combination of closing methods that differ according to how a spending transaction:

  1. uses the seal definition: use of the address in the locking script or spending of the UTXO;

  2. hosts the message on which the seal is closed according to a commitment scheme (i.e. in which part of the transaction the message is committed and stored).

The following table shows the 4 possible combinations of defining and closing a seal:

Method
Seal Definition
Seal Closing
Additional Requirements
Main application
Possible commitment schemes

PkO

Public key value

Transaction output

P2(W)PKH

none yet

keytweak, tapret, opret

TxO2

Transaction output

Transaction output

Requires Deterministic Bitcoin Commitments

RGBv1 (universal)

keytweak, tapret, opret

PkI

Public key value

Transaction input

Taproot-only - Not working with legacy wallets

Bitcoin-based identities

sigtweak, witweak

TxOI

Transaction output

Transaction input

Taproot-only - Not working with legacy wallets

none yet

sigtweak, witweak

RGB protocol uses the TxO2 scheme in which both the Seal Definition and the Seal Closing use transaction outputs (the term "O2" in TxO2 acronym stands for "2 Outputs").

As shown in the table above, several commitment schemes can be used for each seal closing method. Each method differs in the location used by related transactions to host the commitment and, in particular, whether the message is committed to a location belonging to the input or output of the transaction:

  • Transaction Input:

    • Witweak - commitment is placed within the segregated witness data of the transaction.

  • Transaction Output (scriptPubKey):

TxO2 Client-side Validation

In the next paragraphs, we will focus on client-side validation combined with the definition of a single-use seal and a TxO2 scheme closing operation, showing them step by step below and using the two usual cryptographic characters: Alice, dealing with a seal operation, and Bob as an observer.

  1. Alice informs Bob that the spending of these UTXO represents a sign that something has happened.

  1. Once Alice spends her UTXO, only Bob knows that this expenditure has some additional meaning and consequences, even though everyone (i.e. the Bitcoin Blockchain audience) can see this event.

The key point of using the single-use seal in combination with client-side validation is the uniqueness of the spending event and the data committed (i.e., the message) in it, which cannot be changed in the future. The whole operation can be summarized in the following terms.

The next important step is to illustrate precisely how the two commitment schemes adopted in RGB protocol, Opret and Tapret, work and which features they must meet, particularly concerning commitment determinism.


Sigtweak - the commitment is placed within the 32-byte random rrr component that forms the ECDSA signature pair <r,s><r,s><r,s> of an input. It makes use of .

Keytweak - It uses the construction by which the public key of the output of the output is "tweaked" (i.e. modified) to contain a deterministic reference to the message.

- used in RGB, the committed message is placed as an unspendable output after the opcode OP_RETURN.

(Taptweak) - This scheme, used in RGB, represents a form of tweak in which the commitment is an OP_RETURN string placed in a leaf of the Script path of a which then modifies the value of the PubKey.

First of all, Alice has a that refers to some data client-side validated and known only by her.

In fact, the UTXO spent by Alice through the contains a commitment to a modification in the client-side validated data. By passing the original data to Bob, she is able to prove to Bob that these data are properly referenced by the commitment made by Alice in the witness transaction. The verification operation is performed by Bob independently, using the appropriate methods that are part of the client-side validation protocol (e.g. the RGB protocol). Additionally, as we shall see later, the message may contain an additional seal definition thus extending the ordered sequence of messages through a chain of seal definitions and closing.

Sign-to-contract (S2C)
Pay-to-contract
Opret
previous chapter
Tapret
Seal Definition
Seal Closing
The different seal closing methods in Bitcoin transaction.
A seal definition is applied to a specific Bitcoin UTXO.
The UTXO is associated to some meaning agreed between Alice and Bob.
The spending event of the UTXO triggers some meaningful consequences for the parties involved.
Alice can prove to Bob deterministically the uniqueness of the message committed. In addition the message may contain another seal definition extending the chain of commitments.
The UTXO being spent contains the seal definition. A precise kind of transaction output contains the message.
Single-use Seal
taproot transaction
UTXO
witness transaction