Commitment Schemes within Bitcoin and RGB

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

As mentioned in the previous chapter, 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: Seal Definition and Seal Closing. 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:

  • Sigtweak - the commitment is placed within the 32-byte random $r$ component that forms the ECDSA signature pair $<r,s>$ of an input. It makes use of Sign-to-contract (S2C).

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

• Transaction Output (scriptPubKey):

  • Keytweak - It uses the Pay-to-contract 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.

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

  • Tapret (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 taproot transaction which then modifies the value of the PubKey.

The different seal closing methods in Bitcoin transaction.

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. First of all, Alice has a UTXO that refers to some data client-side validated and known only by her.

A seal definition is applied to a specific Bitcoin UTXO.

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

The UTXO is associated to some meaning agreed between Alice and Bob.

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 spending event of the UTXO triggers some meaningful consequences for the parties involved.

1. In fact, the UTXO spent by Alice through the witness transaction 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.

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 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 UTXO being spent contains the seal definition. A precise kind of transaction output contains the message.

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.

---