Require all seals to be of the same type defined in bundle

[dr-orlovsky]

Here we add to #231 a solution to the potential opret/tapret double-commit ambiguity by requiring that each bundle must use only one type of commitment.

This will lead to the fact that if someone by mistake assigns both opret and tapret seal to the same UTXO under the same contract this state can be lost.

[adambor]

This will lead to the fact that if someone by mistake assigns both opret and tapret seal to the same UTXO under the same contract this state can be lost.

I don't think this is the case, if someone assigns both opret and tapret he will just have to commit 2 bundles (one opret committed in OP_RETURN and one tapret commited in first taproot output) in the witness transaction - so no loss of state occurs.

[dr-orlovsky]

You are right.

But yet still you can't combine them as two inputs in the same transition, so they are "non-fungible". But this is minor since you can transform them into the same type with one tx and than combine next.

[adambor]

But this is minor since you can transform them into the same type with one tx and than combine next.

You can even do it in a single transaction. You just have to assign to the input of the witness transaction in one of the bundles, and then spend the newly created assignment in the other one.

Say you have 1 input UTXO with both seal types defined - opret & tapret. You create 2 bundles such that:

• Tapret bundle: input0:tapret -> input0:opret
• Opret bundle: input0:opret (now has 2 assignments) -> destination seal

[parsevalbtc]

But this is minor since you can transform them into the same type with one tx and than combine next.

You can even do it in a single transaction. You just have to assign to the input of the witness transaction in one of the bundles, and then spend the newly created assignment in the other one.

Say you have 1 input UTXO with both seal types defined - opret & tapret. You create 2 bundles such that:

* Tapret bundle: input0:tapret -> input0:opret

* Opret bundle: input0:opret (now has 2 assignments) -> destination seal

Interesting example. But, how do you close input0:opret seal definition?
Maybe is there some requirement of precedence in the outputs? In this case, would tapret seal closing output preceed opret one? Does this situation is addressed in the current consensus?

[dr-orlovsky]

You close the seal with the tx spending that output. And the same tx defines a second seal of different type in the same utxo, spends it and closes it again.

Like one tx, two operations.

[parsevalbtc]

You close the seal with the tx spending that output. And the same tx defines a second seal of different type in the same utxo, spends it and closes it again.

Like one tx, two operations.

Ah great, indeed I see you can do that without circularity, provided that the destination seal is another UTXO. Do you have other constraints in the verification or in output ordering?

In the edge case in which, by error, you define as a new assignment the same seal being spent, I guess you lose the state. Is this situation prevented at consensus level?