~~Edited: merging does not guarantee a slot knowledge beforehand and thus user has to monitor more aspects.~~

#### Edited #2: simplify, provide reasoning

Most likely there is some flaw in this idea, but something similar should allow merging. @vbuterin Vitalik, would you have a look?

~~User deposits a coin and attaches a public key P_1 = r_1 x G. Hash of P_1 is a slot number in a Plasma Cash. To spent it user takes two points H_0 = v x G and H_1 = (v+1) x G, where v is hash of the P_1, and to make a split provides signatures over P_1 + H_0 and P_1 + H_1. New slot numbers are known before spending and the user only has to monitor a chain once a week by asking an operator for a Merkle proof that such leaf is empty, so there was no spending, otherwise exit. To merge the two outputs with associated public keys P_2 and P_3 he would have to provide a signature over P_2 + P_3 (or some other combination that also includes info about merged outputs, but doesn’t expose private keys).~~

User deposits a coin and attaches a public key P = r x G. An output has hash v and is placed in some slot. To spent it user makes two points H_0 = v x G and H_1 = (v+1) x G, where v is hash of the the output as mentioned above. Another options to have v equal to a slot number of the output. To make a split the user provides signatures over P_0 = P + H_0 and P_1 = P + H_1 and Plasma Cash operator places an output to the slot numbers hash(P_0) and hash(P_1) . New slot numbers are known before spending and the user only has to monitor a chain once a week by asking an operator for a Merkle proof that such leaf is empty, so there was no spending, otherwise exit. This allows splitting, and scales linearly with the number of outputs: every user has to monitor 2 x N slots where N is number of his outputs. An output itself has P = r x G somewhere inside the data for further checks. Of course if user sends a part of his output to some other key P’ = r’ x G, than a new key P’ is included into output.

To merge the two outputs with associated hashes (or slot numbers) v_1 and v_2 (and the same public keys for both) a user has to provide a signature over P’’ = P + v_1 x G + v_2 x G. Such form of merging adds another N^2 / 2 slots for user to monitor once a week.

Effectively user checks an “ownership” on ~ N^2 / 2 + 2N “slots” in a global sparse Merkle tree. Merging is up to the user, but having smaller number of outputs is more convenient.

*This looks a lot like UTXO model, so may be one can make some kind of hybrid model with Minimal Viable Plasma and force an operator to commit not only to block Merkle root hash, but also to the global state tree enumerating all taken slots.*

Rules for recipients do not change, they would have to ask for a full history since the beginning. Unfortunately with merges history of every subchain has to be provided. May be some reasonable limit of the month of history in time or in number of blocks should be established.

**Flaw #1: recipient can not be sure that user didn’t double-spent his output by doing a merge over two outputs and a split over one of them.**

Exit rules also do not change with the additional difficulty of having to follow branches on merge points.