RCP-250113A: Unify single-use seals

[dr-orlovsky]

author: @dr-orlovsky
layers: consensus
targets: v0.12
breaking: consensus

Background

RGB since v0.7 (introduction of taproot-based commitment scheme called tapret, released in June 2022) allows two commitment schemes. The reason was the following:

1. tapret commitments save on transaction cost and privacy;
2. but OP_RETURN based commitments opret are needed for Lightning and hardware wallets.

The immediate issue appeared: if we have two commitment schemes, nothing prevents from creating two distinct single-use seals under each of commitment schemes using the same UTXO. And with that a wallet gets blocked and have no choice other than to burn some assets (all assets under one of commitment schemes). Thus, we had to allow two, not one commitment and anchor per bitcoin witness transaction, so transaction may have both tapret and opret commitments present.

In autumn 2023 in Viareggio we also have found a vulnerability of simultaneous use of tapret and opret in v0.10. So, before Viareggio 2023, in v0.9 and v0.10 we thought “well, we just need to prohibit a wallet to create different seal types”. But it was naive. The real problem is that an adversary can do an inflation attack, by creating two commitments in one transaction and never exposing them both: the first in taproot and the other in an op-Return output following taproot (since he can claim the first taproot do not have tapret, while it actually has).

So the moment you have two commitment schemes you must assume they are both present in the same transaction. I spent three months fighting it, got v0.11 with HUGE complexity of dealing with different double commitment cases [1], - and we spent whole 2024 testing and debugging it.

In Lugano last Autumn we decided to make contracts monotonic on commitments, so we can be sure there are no inflation bugs possible. In v0.12 I have implemented it, and everything was fine (and much simpler) in the consensus layer (so each contract is either opret or tapret), but it has stroke back in wallet: tapret wallets need to work with both opret and tapret contracts, and other types of wallets - just with opret. Right now in v0.12 contracts commit to the seal type via generic constant parameter - which is a safety measure. It is impossible to put contracts of different seal types into the same wallet, preventing from completing tests and releasing v0.12.

Motivation

1. Have a single RGB-related deterministic bitcoin commitment (and anchor) per witness transaction, and not two
2. Simplify the audit and formal analysis by getting rid of multiple commitment schemes and supporting just one (per blockchain)
3. Reduce codebase
4. Reduce attack surface

Proposal

Unification means that from now on in v0.12 there will be not two commitment schemes (seal closiing methods), but a single one. Thus, neither contracts nor seal definitions commit to a closing method, and receiver doesn't need to provide one via invoice. Witness transaction will always have just a single anchor and commitment - and not two as before. This is a great simplification, since reduces attack surface by a lot, and simplifies a lot of code, business logic and workflows.

The single unified commitment scheme can be described as "look for the first explicit commitment in OP_RETURN output or assume tapret commitment in the first taproot output".

The algorithm details are the following:

1. iterate over tx outputs
2. if an output is OP_RETURN, check opret commitment to all the seals (remember seals definitions are commitment-agnostic). Stop
3. if an output is taproot, assume tapret commitment, and require proof. Stop
4. if neither, process to the next output

Rationale

Unification of commitments results in:

• removal of a concept of a seal closing method/commitment scheme (since just one exists);
• removal of contract commitments to the seal closing method;
• removal of method field in seal definition (anyway already happened in v0.2);
• removal of method from invoices;
• differentiation of contracts into two unrelated sets (opret and tapret), which would be never able to interact (basically two independent "RGB protocols");
• differentiation between tapret and opret wallets, providing a single RGB wallet API;
• all contracts will have access to Lightning network (before it was not possible for tapret contracts);
• all contracts will have access a simplified use of hardware wallets via bitcoin apps (before it was not possible for tapret contracts).

FAQ

• No, this doesn't introduce requirement for a specific ordering of outputsl; this requirement was as well present before for opret and tapret schemes;
• No, this doesn't mean a client software needs to change; since it is related to a new v0.12 version, which is a consensus breaking and requires changes to software integration anyway.

Implementation

Tracking issue for the implementation in v0.12 is RGB-WG/rgb#275

Appendix

[1] The complexities of two commitment schemes

[2] Ideas tried alognside the idea of unification

[St333p]

One possible downside of this proposal is forward compatibility in case different seal close methods will be developed in the future. I think we cannot exclude that new bitcoin TX output formats (or new protocols) may be developed and that they could require creating new close methods to have RGB work on them.

This may be solved by having contracts commit to a set of supported close methods, which for now will be {tapret, opret} in the vast majority of cases. This way new close methods won't affect existing contracts and it will be possible to introduce them in a backwards compatible way.

The algorithm to identify the output in which commitment is found would become:

1. iterate over contracts that are involved in the tx
2. iterate over tx outputs
3. iterate over close methods committed by the contract
4. if an output corresponds to the close method (e.g.: op-return<->opret, p2tr<->tapret):
   • check the commitment to all the seals involving the current contract
   • proceed to the next contract
5. if neither, proceed to the next output

As proposed by @fedsten, one could also achieve more flexibility by committing to a more specific seal closing logic than just a set of commitment schemes, for instance:

• LastTapretThenOpret: pick the last taproot output if there is one, otherwise pick the last opreturn
• FirstOpretTapretKeytweak: pick the first output that is either opreturn, taproot or wpkh (with key tweak)

These two approaches probably result in different levels of added complexity to the code, it's not entirely clear to me which one is better.

[dr-orlovsky]

The whole point of a proposal is to remove even the ability to have multiple commitment methods in RGB. This was preventing us from moving stable for the last two years.

Strong concept NACK to allowing different seal closing methods in different contracts: it invalidates the whole value of seal unification.

Anyway, different seal close methods are simply different and independent RGB protocols. Thus, if Bitcoin changes, a new protocols may be created.

There is no backward compatibility issue since the contract commits to the protocol at creation time; once created new seal methods can't be added anyway.

[adambor]

ACK - I think this is a clever solution for the opret/tapret dichotomy issue and it simplifies reasoning about possible attacks.

Just throwing in some more (quite possibly unnecessary) ideas here:

1. Proving that taproot output doesn't contain any commitment

According to Constructing and spending Taproot outputs section of BIP341 wiki:

If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. This can be achieved by computing the output key point as Q = P + int(hashTapTweak(bytes(P)))G.

Not sure if this is implemented in practice, but if yes, it could be used to prove that a given taproot output doesn't contain any commitment and should therefore be skipped in the iteration.

2. Skipping OP_RETURNs of invalid size

i.e. if the OP_RETURN output script is not of size 34 (OP_RETURN OP_PUSH32 <32 bytes commitment>) we can also skip it, as it for sure cannot contain a valid commitment. This might be useful for some scritpless swap protocols swapping between assets that use OP_RETURN (such as Runes, Omni) and RGB assets.

[dr-orlovsky]

Yeah, basically one can always prove that a specific transaction output doesn't contain a valid DBP - in for both OP_RETURN and P2TR outputs. For OP_RETURN one just need to provide the source data (or, in case of length check, no data are needed). For P2TR, one can show that there is no script tree, or that it doesn't contain on level 2 any DBC script (this is already done using TapretProof structure anyway).

But I think such "proving no commitment is present" are useful for fallback seals, - but should not be used in the happy path, since they need consensus validation more complex with no benefit (giving fallback mechanism).