That’s not a problem. If the operator challenges the exit, in that process they reveal the Merkle branch that then allows the recipient to exit with the funds unimpeded.
(And I’m not assuming that there are large penalties for attempting an exit that gets challenged here)
All right, although then there’s a griefing/deanonymization/YOLO attack where you make spurious withdrawal attempts on large deposits to force a challenge. But maybe the numbers work out OK.
Along with Vitalik’s suggestion: you can actually include security deposits, but modify the protocol to avoid the griefing attack. Suppose A wants to transfer to B- the idea of the protocol is to give A a way to burn her ownership of a coin once a transfer has been made. A will only burn her coin if data of her transaction is made available from the operator. Let me know your thoughts:
So, A makes a transaction to B. A also sends the operator a signed hash of a random number that is to be included in the leaf node of her coin along with all the other stuff mentioned.
To prove ownership of a coin: B must now also prove that he has the random number that hashes to that value. Now, A will wait until data is available before she gives B the pre-image. As soon as Bob gets the pre-image he broadcasts it to the rest of the network.
If A attempts to exit, we only slash her deposit if the pre-image of her committed hash is revealed by someone.
What’s nice about this scheme is also that no one else can generate a proof of ownership if A is still the real owner, even if the operator misbehaves. A is in complete control of her coin, regardless of the operator’s actions. We can still disincentivise dishonest withdrawals by slashing balances.
This seems equivalent to what I call a “confirm message” in minimal viable plasma; though there is an important optimization here: you just need to reveal a hash preimage instead of verifying a signature.
Has anyone written about how operators of Plasma Cash take fees? I immediately see a few possibilities:
Here’s a very simple proposal:
Every transaction must include a “total fee” in its body. The Plasma chain operator only accepts transactions if their total fee exceeds that of their parent tx, and prioritizes by total_fee - parent_total_fee. When a coin is withdrawn, the amount that can be withdrawn is equal to deposit_size - total_fee.
Though this certainly would ruin nice clean exact-denomination coins.
Another missing alternative here is transaction fees through channel payments.
One potential complexity I see with this construction is the realization of fees. Operators could “exit” on a fee by referencing a specific coin. We’d have to also maintain a mapping on the root chain of coin IDs to total fee claimed. The owner of that coin could then challenge if they prove that latest total_fee - total_fee_claimed is less than sum of all fees claimed on that coin by the operator.
This works for a single operator but becomes more complex if the chain is operated in some way that different operators claim fees individually.
But it definitely does ruin clean exact-denomination coins.
Another possibility is accepting a fee from a separate “fee balance” on the root chain. You’d deposit X ETH (or whatever) into the root contract specifically to be used for fees. Each Plasma Cash tx would specify a fee. Users can then only ever withdraw the fee balance minus the total fees they’ve specified on each transaction. This is never more than what they’ve deposited initially.
A withdrawal from the fee balance would be followed by a challenge period where anyone can prove that the total fees specified by the user is greater than the total fees the user claims to have specified. Operators are the only ones harmed if a user tries to withdraw more than they’re allowed to withdraw because withdrawals can never exceed the current fee balance. Operators already have to validate the entire chain, so they’d have the information required to challenge. Operators just wouldn’t accept a transaction if the user tries to specify a fee that’s greater than their current available fee balance.
Other options:
I think payment channels and cross-chain atomic swaps are pretty difficult on Plasma Cash (even if the spending conditions supported time locks and hash locks) because the channel operator has the power to both censor transactions and withhold data (i.e. a revealed preimage). But I guess you could use a regular ETH payment channel and forget atomicity because the fee amounts are so small.
A lot of this discussion is assuming the possibility of atomic transactions that simultaneously transfer multiple coins.
Does the operator even need to maintain connections with every coinholder? Could we put the storage burden on the chain operator, and have it provide the history validity proof to the recipient after a transaction is confirmed, at the same time it provides the Merkle path to the new coin? (Or on request of the coinholder, if they just need to prove possession to someone.) Then the only burden on the coinholder would be to verify their coin’s history at the time that they receive it, and to monitor the parent chain for attempted withdrawals of that coin.
Could we put the storage burden on the chain operator, and have it provide the history validity proof to the recipient after a transaction is confirmed, at the same time it provides the proof of the new coin?
I suppose that can work. Though the storage burden could be large, so operators may want to forget it after some short period of time.
Hey Plasma-Fans,
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.
So am I right that the capability that this adds to Plasma Cash is that coins can be split? I think there are ways to add coinsplitting to Plasma Cash without making as many changes… for example, every time a coin is split, its ID could accumulate an additional hex digit (so each transaction could split a coin up to 16 times). You would then only have to monitor withdrawals of your own coin and its descendants (i.e. coins whose leading digits match your coin’s ID), rather than all of its cousins.
Additionally, unlike in your scheme, you would not have to keep up to date with all of the transactions involving the “cousin” coins. As soon as you saw any withdrawal claiming to be a descendant of the coin you currently hold, you would immediately know it was invalid, and could challenge it just by revealing your coin and challenging them to provide its immediate child (which they couldn’t, because you never authorized a transaction from your coin).
Here’s a new blog post from Karl Floersch describing an in-progress specification of Plasma Cash. (It has diagrams!)
Thanks for reviewing my proposal. Yes, your solution for coin splitting seems a lot simpler. 
Will there be any restriction on how often an output can be split with the solution you mentioned? Because if we enlarge the ID with every split, the ID’s might become quite long. Is that an issue?
You could also implement this with decimals, i.e. all coin IDs must initially end with X 0s, and we simply increment the trailing 0s until they hit some max after which they can no longer be split. In this case the coin IDs aren’t being lengthened after each tx.
Plasma cash and all the coin splitting mechanisms can be generalized into Sharded Plasma.
Idea is somehow similar to tree of Plasma chains but offers izolation of deposits like Plasma Cash and it might be possible to combine those two.
Sharded Plasma consists of Root Plasma blockchain, smart contract on Ethereum and Plasma Shards.
Only thing sharding adds to withdrawal process is specifying shardId and providing proof inclusion of each referenced shard data in Root Plasma.
Like in Cash user only needs to keep track of history of shards it has a stake in.
This way basically any Plasma design can be sharded as long as there is no need of inter shard communication. Also shards can be heterogeneus, for example person making first deposit to a shard could choose if it’s a single coin, can it be split or should it have Original Plasma in it.
See more at Roast this Concept: One big off chain shard
Generalizing the proof of publication concept here, what if the inclusion in the main chain requires n-number of random validators to reconstruct a root.
Result: proof that tx list / collation is available across the network.
Attack; main chain cheats and distributes hash in network so validators don’t have to retrieve data and do work.
Mitigation: Some kind of slashing game where validators can be slashed if the main chain lies to them and they believe the main chain. Ie. Main chain gets more than commit reward if it can trick validators therefore no validators trust artificial hashes.
Edited: merging does not guarantee a slot knowledge beforehand and thus user has to monitor more aspects.
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.
Hello,
many people are claiming that plasma cash is a great protocol for decentralized exchanges. I am currently trying to design one with plasma cash and running into a fundamental problem.
Here it is:
Assume I posted an order and someone trade against this order and hence sends his coin with AttackerID to me. In order to get the full possession of coin with AttackerID, I want to download all historical data and verify all merkle proofs that this received coin is legit. But what happens, if I can not download the data?
If we design the protocol that anyone can just claim, “uh there is not data, I want to reverse the trade”, then people would call so, everytime they are making a bad trade.
If we design the protocol so that we can challenge the attacker to publish all the data to the rootchain, then the attacker will just sometimes also make legit data not available and a user is required to pay the whole challenge process.
Does anyone sees a way how to solve this issue? Or do we have to request the guy posting an order to first check the whole chain against data unavailability?