RCP-240406A: Fallback single-use-seal

[adambor]

layers: consensus
consensus: fast-forward

Fallback single-use-seals are a way for the RGB state to be re-assigned to a different fallback single-use-seal in case the original single-use-seal is closed in a way which would burn the RGB state. This includes:

• no commitment - single-use-seal closing transaction provably doesn't contain any commitment
• no contract id commitment - single-use-seal closing transaction provably doesn't contain MPC commitment with contract id of the specific RGB contract
• assignment not spent - single-use-seal closing transaction contains a valid commitment for state transition for contract id, but doesn't spend a specific assignment (this means multiple assignments are assigned to the same seal but this specific one is not spent)
• spending script not satisfied - RGB spending script is not satisfied

There might also be other ways how the RGB state can be burned (such as invalid state transition - e.g. spending more assets than the user has, or using an OP_RETURN unspendable UTXO as a seal), maybe these also need to be covered, however I currently cannot think of a reason for that to be useful.

Motivation

If a seal is closed without including the proper state transition for the specific assignment in the witness transaction the state is burned and unrecoverable, this also applies for the case when locking script of the assignment is not properly satisfied by spending script (this can also happen because of dynamic nature of the locking script, such that it depends on blockheight in which the witness tx is included or any other dynamic blockchain data).

Especially the lightning use-cases allows for massively scaling RGB lightning, allowing batched splice-ins adding new assets to hundreds or thousands of channels all committed in a one single on-chain transaction of as small as 110vB (if using tapret), just for comparison hundred vanilla lightning splice-ins would require ~10kvB if all were batched in a single transaction, ~21kvB if no batching were used. This essentially solves the inbound liquidity issue of lightning, since splice-ins are basically free (just 1.1vB ammortized with batches of 100).

Use cases

Coloring existing lightning channels

Currently it is unsafe to color existing lightning channels (adding RGB assets to existing lightning channels) - this is due to the fact that the counterparty can publish old lightning commitment transaction (from the time when the channel was vanilla lightning) which doesn't include commitment to any RGB state transition as specified during seal definition (no opret or no tapret) - effectively burning the seal (lightning funding input) with all the RGB state assigned to it. This becomes safe with fallback seals since we can specify a fallback seal to use in case the single-use-seal is closed with provably no commitment (no opret output for opret seals or a proof that tapret doesn't contain any commitment for tapret seals). In this case if the evil counterparty publishes an old lightning commitment transaction (without any RGB commitment) the assets can be automatically re-allocated to the fallback seal of the honest party who deposited the RGB assets in the first place. This is an example of using fallback seal in case of no commitment - the single-use-seal closing transaction provably doesn't contain any commitment.

Adding more RGB asset types to existing colored lightning channel

It is also unsafe to add new assets of different type (different contract id) to an already existing RGB lightning channels for much the same reason as outlined in the example above - because it is possible for a malicious counterparty to publish old lightning commitment transaction (from the time when the channel was only used for a single RGB asset) which doesn't contain a valid MPC commitment for the contract id of the newly deposited RGB asset. Here the solution is again to use a fallback seal for the newly deposited RGB asset, such that the RGB state is re-allocated to the fallback seal if it can be shown than the MPC commitment of the witness transaction closing the single-use-seal doesn't contain a valid commitment belonging to that contract id. This is an example of using fallback seal in case of no contract id commitment - the single-use-seal closing transaction provably doesn't contain MPC commitment with contract id of the specific RGB contract.

Adding more RGB assets of the same type to the existing colored lightning channel

Another unsafe practice is adding more RGB asset of the same type to an already existing RGB lightning channel. The issue here is that old commitment transactions only contains commitment to RGB state transition spending old assignments that were assigned to the lightning funding output single-use-seal before the new assignment was added (more tokens were deposited). With fallback seals we can make sure that if that happens the assets in the new assignment are re-allocated to the fallback seal. This is an example of using fallback seal in case of assignment not spent - single-use-seal closing transaction contains a valid commitment for state transition for contract id, but doesn't spend a specific assignment (this means multiple assignments are assigned to the same seal but this specific one is not spent).

Scriptless atomic swaps with bounded expiry

Scriptless atomic swaps as presented LNP-BP/discussions #125 run into issue of the 2nd swap signer having a free option to broadcast the swap transaction anytime he wants in the future (where only way to prevent it is for the 1st signer to double spend the input - which costs on-chain fees). This cannot be solved with bitcoin locking script since that only allows locktimes in one direction (blockheight > X) and doesn't allow transactions to expire (blockheight < X). This could however be solved with locking script on the layer of RGB, such that the locking script will only allow the asset exchange to happen if witness tx blockheight < timeout (see my comment). Problem is that with this RGB locking script alone the 2nd signer has an option to burn the assets for both users (if the bitcoin transaction doesn't confirm before timeout block), therefore there is a need to supply a fallback seal where the state is re-allocated in case the RGB locking script is not satisfied. This is an example of using fallback seal in case of spending script not satisfied - the RGB spending script is not satisfied.

Implementation

Implementation needs to provide a way to prove that the specific assignment was spent in an invalid way and in that case re-assign the assignment to the fallback single-use-seal. This proof is different for all the specified cases:

• no commitment - implementation needs to check single-use-seal closing transaction:
  • in case of opret seal - check that the tx contains no OP_RETURN
  • in case of tapret seal - a proof that taptree doesn't contain OP_RETURN in the expected position of its scriptpath spend
• no contract id commitment - implementation needs to check that MPC commitment for given contract id is missing in the expected position in the MPC tree of the transaction closing the single-use-seal:
  • in case there is no data (entropy) at the expected position - proof is an entropy pre-image that hashes to the leaf
  • in case there is data for different contract id - proof is revealed contract id (that differs from expected contract id) + bundle id
• assignment not spent - implementation needs to check that a committed bundle in the witness transaction doesn't contain a state transition spending the assignment
• spending script not satisfied - implementation needs to check that the spending script of the state transition (which is correctly committed in the witness transaction) spending the assignment evaluates to false

Challenges

Implementation complexity

It would seem like all this would be very complex to implement - @dr-orlovsky can provide better input on the exact complexity.

Inefficiencies in lightning fallback seals

Ordering of lightning commitment transaction outputs makes it hard to use the commitment transaction output a fallback seal, since the position of the output (and its locking script) isn't static and depends on the output value & lexicographical ordering. This means a user has to have a separate UTXO to be used as a fallback seal - meaning at least 2 UTXOs per user (one for lightning channel & another one to be used as a fallback seal) in the best case. Good thing is the user can live with just 1 UTXO to be used as fallback for many channels, so UTXO per user requirement scales as 1 + number of channels.

[dr-orlovsky]

As was discussed, I like the idea.

BTW, with v0.11 it is not a pushback but fast-forward: we have fields reserved.

The exact complexity is hard to estimate, other than to say it is high.

Inefficiencies in defining a fallback seal can be overcome by providing existing UTXO outside of the lightning channel.