[Investigate] Use MVP instead of MoreVP on batch settlement

[boolafish]

In previous design, we need complex games and have batch size limit because we need to prove tx format-wise valid (eg. does settlement correctly represent the orders' will) on chain in in-flight exit.

However, if we can use MVP here, then it's just checking signatures. Also, confirmation signature is not a UX degradation because it is the venue re-signing that, traders are not impacted.

So to do an exit, we can submit a tx hash, inclusion proof of an utxo belongs to such tx, and standard exit. Since we are using inclusion proof of utxo inside tx, we do not even need to worry about amount of utxos.

[boolafish]

[Note] we would need to define how to transform crossing MoreVP and MVP between our normal tx and settlement tx. (Quite likely needs to carefully design our deposit tx and withdrawal tx)

[boolafish]

Analysis on using output in different exit games protocol (MoreVp and MVP)

In fact, it is easy to switch between the two. Basically, the protocol of next transaction would decide how to define the predicate for using the output.

If next tx is using MoreVP protocol, to use the output in such tx, it just need to show an existing tx (no need to be mined) that is correctly signed (or any other logic depends on app).

On other hands, if the next tx is using MVP protocol, it needs to show the next tx is mined and confirmed.

An interesting thing is that, a single output can possibly go to two different protocol without issue. (So a single output can possibly be consumed in MVP tx type 1 and MoreVP tx type 2. They would not conflict)

Analysis of using in MVP

If next tx is using MVP, it is pretty clear that next tx would not impact much on the previous tx. Everything only exits on output and would have clear priority (must be mined --> utxo_pos is clear)

Analysis of using in MoreVP

If next tx is using MoreVP, that means it can in-flight exit and would have the possibility of exiting from input.

1. the output used in next tx is not double-spent, and in-flight exit of next tx is canonical. Exit from next tx's output.
2. the output used in next tx is not double-spent, but the in-flight exit of next tx is non-canonical. The output (input of next tx) can exit.
3. the output used in next tx is double-spent with higher or equal (both in-flight) priority, so the in-flight exit of next tx must be non-canonical. Since double spent, the output's piggyback would be challenged since double spent.
4. the output used in next tx is double-spent with lower priority, the in-flight exit is canonical. However, the piggyback of such output (input of the in-flight exit tx) would be challenged since double-spent.

So actually it is totally fine and being the same as normal scenario.

@paulperegud can you try to see if there is any logic hole on the above statement?

Funding

Case 1: funding with a funding tx (MoreVP Normal Output --> Funding TX)

We can choose we want to allow IFE on funding tx or not. Might be better to allow IFE because traders does not need to double sign the funding tx in this case.

In this case, Normal Output can be used in the funding tx as long as the funding tx exists and correctly signed.

Trick here is to change from MoreVP to MVP is the funding tx output (that holds the custody) need confirm signature from exchange to be able to be used in settlement tx. Also, the settlement tx need to be mined (has utxo_pos) by operator. So the predicate would check the two things above (possibly more for DEX logic).

Case 2: funding without a funding tx. MoreVP Normal Output --> Settlement Tx

As we have some ideas (eg. #84) to do some tricks to hide the funding tx, this might be possible scenarios.

To support the change from MoreVP to MVP, we would need different definition about how can the normal output be used in different tx types. For a normal output to be used in a normal tx, it just need such tx exists and with correct signature (MoreVP). However, for a normal output to be used in settlement tx, it would need the settlement tx mined and has confirm signature (MVP).

Meanwhile, I believe it would be secure enough (RC) for the exchange to sign the confirm signature in this case (A normal MVP would need this to be signed by input owner, which is trader in this case). Of course, there must be some data that shows the trader allows exchange to create tx on his/her behave. (Offline message with sig or the output ownership explicit the exchange info as in #84)

Settlement

Case 1: Settlement tx returns funds to user directly (So the output is a normal type)

As analyzed before, just depends on which protocol the next tx is using we can define the predicate accordingly.

Case 2: Settlement tx keeps funds in RC mode (The output is DEX special output type)

As analyzed before, just depends on which protocol the next tx is using we can define the predicate accordingly.

Withdrawal

Case 1: Happy path

Trader ask exchange to sign-off the withdrawal and send to operator directly. The transaction can be in MoreVP for better UX.

Since MoerVP, we define the predicate of using a DEX output type in withdrawal tx by showing an existing withdrawal tx correctly signed by trader plus exchange.

Case 2: notification + execution tx

Notification tx does not matters.

Execution tx can be MoreVP for better UX. Since MoerVP, we define the predicate of using a DEX output type in withdrawal tx by showing an existing withdrawal tx correctly signed by trader plus inclusion proof of notification tx at certain age.

[paulperegud]

My intuition tells me that this works - that we can switch between MVP and MoreVP protocol on the same chain. Although we definitely need to define whole thing more formally.

[boolafish]

Closing this as it seems it works. If we want to document a formal proof, let's do it in a separate task.