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 previously, 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 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 seal definition and the seal closure use transaction outputs (the term "O2" in TxO2 acronym stands for 2 Outputs).
As shown in the table, 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 make uses 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_RETURNstring placed in a leaf of theScript pathof a taproot transaction which then modifies the value of the PubKey.
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.
First of all, Alice has some UTXOs that refer to some data client-side validated and known only by her.
Alice informs Bob that the spending of these UTXO represents a sign that something has happened.
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.
In fact, the UTXO spent by Alice through the witness transaction contains a commitment to a change in the validated client-side 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 - seal closing.
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 are the features they must meet, particularly with regard to commitment determinism.
Last updated
