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.
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:
- uses the seal definition: use of the address in the locking script or spending of the UTXO;
- 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.
- Sigtweak - the commitment is placed within the 32-byte random
-
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_RETURNstring placed in a leaf of theScript pathof a taproot transaction which then modifies the value of the PubKey.
The different seal closing methods in Bitcoin transaction.
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.
- 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.
- 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.
- 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.
- 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.