More Viable Plasma

new-extension

#42

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.


#43

Thanks, this would be helpful. If time permits, I will help you out.


#44

@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?


#45

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.


#46

@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?


#47

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.


#48

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


#49

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.


#50

Note: Some of the stuff in this post is super confusing. Much of this work is currently being simplified, rewritten, and edited here.


#51

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:

  1. Bob sends atx1 to Mallory spending his input1 to output1.
  2. The tx1 is inflight. The operator stops publishing blocks, but still submits root hashes.
  3. 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 newtx2 and challenge Bob successfully.

Is this seen as a concern?
The way around this might be:

But this would introduce another signature.


#52

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).


#53

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?


#54

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.