I’ve made some very rough sketch of how it can work based on @kfichter explainer from above. Will extend it in the next few days, now it’s 90% test-broken and completely not optimized.
Thanks, this would be helpful. If time permits, I will help you out.
@kfichter if operator creates a “out of nowhere” output (UTXO1), then he spends it and creates UTXO2 and then spends this new one and creates UTXO3. All transactions will be included in the blocks, and these blocks will be withheld. So, the UTXO3 will have a “youngest” valid input (with m.proof), and should it be processed before the rest? How it can be challenged or can be there any competitors?
If the transaction that created UTXO3 only had one input (UTXO2), then it will be successful processed with a priority based on the position of UTXO2. It cannot be challenged because it appears to be a valid transaction. This is generally the security model of Plasma MVP - we can’t avoid these transactions but we can create conditions so valid exits will be processed before UTXO3.
1 Like
@kfichter thank you for clarifying!
Is it right, that after withholding starts, any user started to exit with UTXO in in-flight tx could be grieved with doublespend tx by the user, who sent him funds?
E.g. Alice created tx1 with input1 and output1 to Bob, and it becomes “inflight” due to data withholding.
Then Bob is starts to exit with tx1 and piggybacks to output1. Then Alice challenge him with tx2 with input1 and output2.
Is it possible in this construction?
Yes, this is possible. Note that Bob will only lose the “original bond” required to submit the exit and not the “piggyback bond.”
Also, there are alternative versions of this protocol in the case that all outputs are cooperating. In that case, the outputs can relinquish all rights to the transaction and allow the inputs to exit/piggyback. I imagine this will be useful for merchants who want to quickly refund users in the case of withholding.
So, it looks like every user, who has a output in inflight tx, could loose his bond and exit nothing. And on other side - every user spending funds in inflight tx motivated to claim honest exiter’s bond
There are two bonds here - an exit bond required to start the exit and a “piggyback” bond placed by owners of the inputs/outputs. Only the exit bond is slashed. The output owners will exit nothing but will have their piggyback bonds refunded.
Note: Some of the stuff in this post is super confusing. Much of this work is currently being simplified, rewritten, and edited here.
If the output owner will not be able to exit anything out of this exit-game, then he should always wait for an inclusion of the transaction in a valid plasma block, before handing over any good/ service for this payment.
Especially, the following scenario would be a problem, as Mallory does nothing illegal:
- Bob sends a
tx1to Mallory spending hisinput1tooutput1. - The
tx1is inflight. The operator stops publishing blocks, but still submits root hashes. - Mallory tells Bob that he can not see the blocks and that he would not accept the tx1, as he does not know that it is canonical.
Now, how does Bob gets his money back?
If Bob exits tx1 and piggybacks on his input, then the operator(Mallorie’s friend) can make the block available, Mallory can suddenly accept the payment and spend output1 in a new tx2 and challenge Bob successfully.
Is this seen as a concern?
The way around this might be:
But this would introduce another signature.
Bob knows that Bob hasn’t spent UTXO1 in any transaction other than TX1. Bob can start an exit (but not piggyback) and ask Mallory to piggyback. Mallory would then receive the funds at the end of the exit period. If Mallory does not piggyback, then this is Mallory’s fault. This is the same as Bob sending funds to Mallory and not receiving anything in return - would need to figure out some other way (e.g. escrow).
1 Like
Regarding the following paragraph (found at the end of the MoreVP Exit Protocol Specification in morevp.md)
The MoreVP protocol can be combined with the Plasma MVP protocol in a way that simultaneously preserves the integrity of exits and minimizes gas cost. Owners of outputs on the Plasma chain should be able to start an exit via either mechanism, but not both. Implementers can check this whenever an MVP exit is being submitted or whenever a MoreVP exit is being piggybacked. Although the two protocols use different determinations for exit priority, we still need a total ordering on exits. Therefore, every exit, no matter the protocol used, must be included in the same priority queue for processing.
Are there any suggested total orderings that could be used on UTXOs in this context?
We use a total ordering based on UTXO position. In MVP this means the position of the UTXO being exited, in MoreVP this means the position of the youngest input to the transaction referenced.
For me, priority queueing based on youngest input doesn’t seem enough for honest exits to be processed before invalid exits.
At first, a malicious operator sees the following two tx’s published by honest users.
- tx1: [[UTXO0], [UTXO1]]
- tx2: [[UTXO1], [UTXO2]]
Then the operator creates the following invalid two tx’s.
- tx3: [[], [UTXO3]] (out of nowhere tx)
- tx4: [[UTXO3], [UTXO4]]
Then the operator builds the following block and submits it to rootchain.
At last he immediately initiates an exit of tx4(UTXO4).
- block: [tx3, tx4, tx1, tx2]
Now tx4’s youngest input is tx3 and tx2’s youngest input is tx1, the honest exit of tx2 loses to the invalid exit of tx4?
Probably I misunderstand something.
Please correct me if I’m wrong.
Hi, you haven’t misunderstood anything. MoreVP doesn’t allow for simple chained transactions for exactly this reason.
Thank you for your response!
Excuse me, still I have a question.
What do you mean by “simple chained transactions” ?
I guess this means that a pair of directly chained transactions can’t be included in a single block, am I correct?
If correct, is this limitation specific to MoreVP and not applied to MVP?
It means that you can spend only timestamped outputs (i.e. included in the plasma block and committed to root chain). This limitation is true for both MVP and MoreVP.
1 Like
This point has been a mystery for me for several days, and resolved at last now.
Thank you!
Hi Kelvin
I think saw a mistake in these statements.
- We’ve already shown that:
- o ∈ E ( T n + 1 ) ⟹ O ( t n + 1 ) ∩ E ( T n + 1 ) = ∅ ∧ o ∉ d o u b l e _ s p e n t ( T n + 1 ) ----------- (1)
- We can negate this statement to find:
- o ∉ E ( T n + 1 ) ∧ ( O ( t n + 1 ) ⊆ E ( T n + 1 ) ∨ o ∈ d o u b l e _ s p e n t ( T n + 1 ) ) ---------------- (2)
From my understanding right now (2) is negate of (1), right ?
So let
p is “o ∈ E ( T n + 1 )” ,
q is “O ( t n + 1 ) ∩ E ( T n + 1 ) = ∅” ,
r is “o ∉ d o u b l e _ s p e n t ( T n + 1 )”.
Then rewrite (1),(2) in the form of p,q,r.
p ⟹ (q ∧ r) --------- (1)
~p ∧ (~q ∨ ~r) -------- (2)
but the negation of (1) should be ~(p ⟹ (q ∧ r)) , and I got
~(p ⟹ (q ∧ r)) ≡ ~(~p ∨ (q ∧ r)) ≡ p ∧ ~ (q ∧ r) ≡ p ∧ (~q ∨ ~r).
So I think (2) should be “p ∧ (~q ∨ ~r)” not “~p ∧ (~q ∨ ~r)”.
please correct me if I’m wrong.
1 Like
I believe you’re correct. We noticed a few minor mistakes in the statements and are maintaining an updated (fixed) version here: elixir-omg/docs/morevp.md at e98c52246cee99ec1631075ff785613bc228b187 · omgnetwork/elixir-omg · GitHub.
1 Like