Here is another version of plasma cash: plasma root verification.
Plasma cash is great because the operator can no longer turn the plasma contract on the main chain into a fractional reserve, but he has to steal coins. This is archived by introducing coinIds and requiring the operator to steal a unique coin. Here I want to describe that this can also be archived without the introduction of a coinId, we just need to link every transaction output to its initial deposit into the plasma chain. Instead of requiring the users to check the validity of all transactions, we just require them to ensure that the initial deposit linked to their transaction output, does not turn into a fractional reserve. Hence, the trade-off is that you do no longer need to watch only your coinId, as in plasma cash, but all transaction outputs, which do originate in your initial deposits. If you hold several transaction outputs belonging to initial deposits you need to watch all the transactions shifting a ownership of outputs from these initial deposits.
Here are the details.
Everytime funds are deposited into the plasma contract into the rootchain, we generate a unique depositID and a transaction output relating to this depositID in the plasma chain. These outputs can be split as people wish to, but they can never be merged together.
The transactions for a block of the plasma chain have to be ordered by the depositID of the spend output. If there are several transactions for a unique Id, all of these transactions are next to each other in the tree, but their order does not matter.
If a user wants to send a transaction, he needs to send for all blocks in the past (1) new outputs related to the depositID and (2) Merkle proofs of all outputs and (3) Merkle proof that these are really all transaction outputs belonging to this depositID.
Now if someone wants to leave the plasma chain, he needs to submit the
(1) transaction output [TOW] from a block n in the plasma chain, which he wants to withdraw
(2) the depositID belonging to this transaction output
(3) the transaction outputs [TOW/2] on a block close to n/2, which is one parent transaction output of TOW.
Now every user, who has also an output with the same depositID must check whether this is a legitimate withdraw. There are two ways to challenge it: (1) providing a proof that this output was already spend (2) challenging in a trueBit style, that the transaction output does not belong to the depositID.
The second challenge is a little bit more complex. If there is not such a link between the transaction output and the depositID, somewhere this link needs to break and we can find this with a trueBit style in log(blockheight). Either the user sees that the link breaks between [depositID] <=> [TOW/2] or [TOW/2] <=> [TOW]. Depending on where the link breaks, he can challenge the withdrawer to provide a parent transaction output close to the height n/4 or n/2+n/4 and the challenge game starts again. This way we can prove whether an output belongs to a depositID or not. At the end of the challenge game, we should have two consecutive outputs [TOWn], [TOWn+1], where [TOWn+1] uses [TOWn]’s output and spends it somewhere. If this is not the case, the challenger has won the game. Otherwise, the challenger has lost, if he can not provide a [TOWn+1]’, which spends the output [TOWn] before [TOWn+1] does it. (And thereby proofing a double spend of the chain operator.)
I like this solution since it does not need these change machines from plasma cash. But the drawback is that we need to transfer more data per transaction.