Skip to content

Update text of Commitment Schemes, DBC, Opret and Tapret pages #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MariJJhodl wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update text of Commitment Schemes, DBC, Opret and Tapret pages #27

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
11be819
Update text of Commitment Schemes, DBC, Opret and Tapret pages
Nov 3, 2026
52ba4f9
Hash the Tapret commitment as a TapLeaf in formulas and diagrams
Nov 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion commitment-layer/anchors.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ If a [Tapret](deterministic-bitcoin-commitments-dbc/tapret.md) commitment is use

* Internal Public Key `P` of the Taproot output used.
* Partner node(s) of the [Taproot](../annexes/glossary.md#taproot) `Script Path Spend` which is either:
* The top left branch (in the [example](deterministic-bitcoin-commitments-dbc/tapret.md#tapret-incorporation-in-pre-existing-script-path-spend): `tHABC`) if the `Tapret` commitment is on the right side of the tree.
* The top left branch (in the [example](deterministic-bitcoin-commitments-dbc/tapret.md#tapret-incorporation-in-a-pre-existing-script-path-spend): `tHABC`) if the `Tapret` commitment is on the right side of the tree.
* The left and right nodes of the upper right branch (in the same example they are: `tHAB` and `tHC`) if the `Tapret` commitment is on the left side of the tree.
* The [nonce](deterministic-bitcoin-commitments-dbc/tapret.md#nonce-optimization), if used, to optimize the Partner node part of the proof.

Expand Down
40 changes: 20 additions & 20 deletions commitment-layer/commitment-schemes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,45 +1,45 @@
# Commitment Schemes within Bitcoin and RGB

In this chapter we will explore the application of Client-side Validation and [Single-use Seal](../annexes/glossary.md#single-use-seal) to Bitcoin Blockchain, introducing the main architectural features behind **RGB protocol related to the commitment layer (layer 1)**.
In this chapter, we will explore the application of client-side validation and [single-use seal](../annexes/glossary.md#single-use-seal) to the Bitcoin blockchain, introducing the main architectural features of **RGB protocol that are related to the commitment layer (Layer 1)**.

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.
As mentioned in the previous chapter, the cryptographic operations above can be generally applied to different blockchains and different publication media. However, the outstanding properties of the Bitcoin consensus algorithm (particularly those that enable decentralization, censorship resistance, and permissionless access) make it the ideal technology stack for the development of advanced programmability features: the kind required by digital bearer rights and smart contracts.

From the previous section, we recall that the creation of Single-use Seals is subject to two basic operations: [Seal Definition](../distributed-computing-concepts/single-use-seals.md#seal-definition) and [Seal Closing](../distributed-computing-concepts/single-use-seals.md#seal-closing). We will now explore how these two operations are implemented **using Bitcoin Transactions as a publication medium** for the RGB protocol. A a more generic overview on single-use seals constructions on the bitcoin blockchain can be found [here](../annexes/single-use-seals-bitcoin.md).
As shown in the previous section, the creation of single-use seals is subject to two basic operations: [Seal Definition](../distributed-computing-concepts/single-use-seals.md#seal-definition) and [Seal Closing](../distributed-computing-concepts/single-use-seals.md#seal-closing). We will now explore how these two operations are implemented **using Bitcoin transactions as a publication medium** for RGB protocol. A more generic overview of single-use seals constructions on the Bitcoin blockchain can be found [here](../annexes/single-use-seals-bitcoin.md).

### Single-use Seals in RGB

RGB seals are represented by bitcoin unspent transaction outputs (UTXO), so that:
- A seal is **defined** by some **state** that points to a UTXO that identifies its owner
- A seal is **closed** around a **message** when a transaction spends the UTXO and commits to a message
RGB seals are represented by Bitcoin unspent transaction outputs (UTXOs), so that:
- A seal is **defined** when some **state** is linked to a specific UTXO which identifies its owner
- A seal is **closed** around a **message** when a transaction spends the UTXO and commits to that message

These two operations are then chained together by including a seal definition in the message around which the previous seal is closed, so that the [witness transaction](../annexes/glossary.md#witness-transaction):
- spends the UTXO on which a seal was defined, thus closing the seal
- has an output that contains a commitment to a new seal definition
These two operations are then chained together, in that the message which closes the previous seal also includes the new seal definition, so that the [witness transaction](../annexes/glossary.md#witness-transaction):
- spends the UTXO on which a seal was defined, thus closing the seal;
- has an output that contains a commitment to a new seal definition.

### RGB Client-side Validation

In the next paragraphs, we will focus on client-side validation combined with the above construction of a single-use seal, showing them step by step trough the usual cryptographic characters: Alice, who deals with a seal operation, and Bob as an observer.
In the next paragraphs, we will focus on client-side validation, as applied to the above construction of a single-use seal, showing it step by step through the usual cryptographic characters: Alice, who performs a seal operation, and Bob as an observer.

1. First of all, Alice has a [UTXO](../annexes/glossary.md#utxo) **that is linked to some client-side validated data** known only by her.
1. First of all, Alice has a [UTXO](../annexes/glossary.md#utxo) **that is linked to some client-side validated data** that only she knows.

<figure><img src="../.gitbook/assets/txo2-1.webp" alt=""><figcaption><p><strong>A seal definition is applied to a specific Bitcoin UTXO.</strong></p></figcaption></figure>

2. Alice informs Bob that the spending of these UTXO represents a sign that some seal was closed.
2. Alice informs Bob that the spending of this UTXO signals that some seal was closed.

<figure><img src="../.gitbook/assets/txo2-2.webp" alt=""><figcaption><p><strong>The UTXO is associated to some meaning agreed between Alice and Bob.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/txo2-2.webp" alt=""><figcaption><p><strong>The UTXO is associated with a specific meaning agreed between Alice and Bob.</strong></p></figcaption></figure>

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

<figure><img src="../.gitbook/assets/txo2-3.webp" alt=""><figcaption><p><strong>The spending event of the UTXO triggers some meaningful consequences for the parties involved.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/txo2-3.webp" alt=""><figcaption><p><strong>Spending the UTXO triggers some meaningful consequences for the parties involved.</strong></p></figcaption></figure>

4. In fact, the UTXO spent by Alice through the [witness transaction](../annexes/glossary.md#witness-transaction) contains a commitment to a change in the client-side validated data. By passing the original data to Bob, she is able to prove him that it is properly referenced by the commitment that Alice included in the witness transaction. Bob can independently verify that the new seal definition is unequivocally bound to the seal closing, so that no other players can be convinced to accept a different one as valid, effectively **preventing double spend**.
4. In fact, the [witness transaction](../annexes/glossary.md#witness-transaction) that spends Alice's UTXO contains a commitment to a change in the client-side validated data. By sharing the original data with Bob, she can prove to him that the commitment correctly corresponds to that data. Bob can independently verify that the new seal definition is unequivocally bound to the seal closing, so that nobody can receive a different one and mistakenly accept it as valid. This way, the protocol effectively **prevents double-spending**.

<figure><img src="../.gitbook/assets/txo2-4.webp" alt=""><figcaption><p><strong>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.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/txo2-4.webp" alt=""><figcaption><p><strong>Alice can deterministically prove to Bob the uniqueness of the committed message. In addition, the message may contain another seal definition, extending the chain of commitments.</strong></p></figcaption></figure>

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.
Combining single-use seals with client-side validation guarantees two properties: the spending event is unique, and the committed data in it (i.e., the message) cannot be changed in the future. The whole operation can be summarized as follows.

<figure><img src="../.gitbook/assets/txo2-5.webp" alt=""><figcaption><p><strong>The UTXO being spent represents the seal closing. A precise kind of transaction output contains the message, which represents a new seal definition.</strong></p></figcaption></figure>
<figure><img src="../.gitbook/assets/txo2-5.webp" alt=""><figcaption><p><strong>The UTXO being spent represents the seal closing. A specific kind of transaction output contains the message, which represents a new seal definition.</strong></p></figcaption></figure>

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.
The next important step is to illustrate precisely how the two commitment schemes adopted in RGB protocol on Bitcoin, **Opret** and **Tapret**, work and which requirements they must meet, particularly concerning commitment determinism.

***
12 changes: 6 additions & 6 deletions commitment-layer/deterministic-bitcoin-commitments-dbc/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,15 +1,15 @@
# Deterministic Bitcoin Commitments - DBC

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

> 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):
Due to this requirement, it is not possible to construct an "alternative history" of the client-side data committed to the same transaction. Thus, the message which the single-use seal encloses is unique. To meet the above requirement, regardless of the number of outputs in a transaction, a valid commitment (either Opret or Tapret) must be contained in _one and only one output_:

> 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
> The only valid output that can contain an RGB message commitment is the first DBC-compatible output, i.e. the first that either has:
> 1. an OP\_RETURN output; in this case the Opret commitment will be encoded inside it
> 2. a Taproot output; in this case the Tapret commitment will be encoded 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.
It is worth observing that a transaction has to **only contain either a single** `Opret` **OR a single** `Tapret` commitment in the first applicable output. This approach guarantees that the seal closing strategy is always unique, no matter how the seal was created in the first place. As a consequence, if a witness transaction contained both a Taproot and an OP\_RETURN output, the second one would be ignored by the RGB validation process.

***
10 changes: 5 additions & 5 deletions commitment-layer/deterministic-bitcoin-commitments-dbc/opret.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
# Opret

This represents the simplest and most straightforward scheme. The commitment is inserted into the first `OP_RETURN` output of the [witness transaction](../../annexes/glossary.md#witness-transaction) in the following way:
Opret represents the simplest and most straightforward scheme. The commitment is inserted into the first `OP_RETURN` output of the [witness transaction](../../annexes/glossary.md#witness-transaction) in the following way:

```
34-byte_Opret_Commitment =
OP_RETURN OP_PUSHBYTE_32 <mpc::Commitment>
|_________| |______________| |_________________|
1-byte 1-byte 32 bytes
OP_RETURN OP_PUSHBYTES_32 <mpc::Commitment>
|_________| |_______________| |_________________|
1-byte 1-byte 32 bytes
```

`mpc::Commitment` is the 32-byte Tagged hash resulting from the [MPC tree](../multi-protocol-commitments-mpc.md#mpc-tagged-hash) which is covered in detail [later](../multi-protocol-commitments-mpc.md). Hence an opret commitment will have a total size of 34 bytes.
The `mpc::Commitment` is the 32-byte tagged hash resulting from the [MPC tree](../multi-protocol-commitments-mpc.md#mpc-tagged-hash) (this concept is covered in detail in the [next section](../multi-protocol-commitments-mpc.md)). Hence an opret commitment will have a total size of 34 bytes.

***
Loading
Loading