The position in the Merkle tree tells you which coin the tx is allowed to spend. So the location of the empty transaction is what tells you that it’s the proof of the non-spend of that coin.
But when you send proof for other, there won’t be any information about position, isn’t it?
As other will also store the part related to their coin, how they know the part you send is really that particular coin?
The proof of non-spend in each block is a Merkle path to the empty slot. That Merkle path, by its nature, shows the location of that slot in the Merkle tree.
I see now. Thank you very much.
Hello I’m looking into using plasma cash for enterprise side-chains. Have you considered using fixed size coins with fixed splits ? For example the only coins that can be deposited are 80 ETH and it can only be split into halves. This way every body knows that if you try to exit a 2nd level split, it can only be worth 20ETH.
We could also define that only 2 splits of same value can merge into a new id M1, and M1 can also merge again with another M2 of the same value. This way someone receiving a merged coin (M1M2) will use it like any other coin because it splits back into the halves M1 and M2.
Deposits of 40ETH, 20ETH … could also be accepted and quarters can be used instead of halves… all defined in plasma contract.
With this construction, coins can be merged into new ids (requires on-chain TX so that plasma is aware of it). But we could also make a protocol for easy swap of splits between users so that they can merge back to parent without paying the on chain merge fee (useful for small coin denominations). Users shouldn’t care which coin they have as long as it is of the same value.
I’m hoping we wouldn’t have to rely as much on change providers if coins can be merged and split …
I wrote about that here One proposal for plasma cash with coin splitting and merging, but I think getting the exit game right is tricky. For instance you have to protect against two 20-ETH coins being double spent, and the recipient of the double-spends merging them into one 40-ETH coin and then exiting that coin.
Thanks, your post helps a lot.
You mean it’s tricky to challenge because merging two splits back to their parent happens off-chain ?
Hmm the game can become very long as an attacker can challenge with an invalid split that has to be challenged…
Does that make sense ?
If only parent merging is possible, an attack might be to own a very small split of each coin and prevent everybody from merging.
I’ve found myself to be pathologically overoptimistic about the workability of various splitting and merging schemes, but I definitely think it’s possible to do equal-value splits and sibling merges without significantly changing the Plasma Cash exit game.
If someone attempts to exit an outdated splitted or merged coin, you can reveal a subsequent spend, merge, or split of that coin, just like you can with a normal coin.
If someone attempts to reveal an invalid coin in your coin’s future (i.e. if the Plasma Cash chain operator has gone byzantine), you can reveal your currently held coin and challenge them to provide the subsequent spend, merge, or split of that coin.
The difficulties come when you start having non-equal splits and (especially) non-sibling merges.
I might be wrong but only having equal splits seems ok. If merging is only done with equal value coins, when you split a merged coin again, users always get the same result, looks more like cash with fixed denominations… Also, different value split coins prevent convenient coin swapping for merging back to parent.
Non-sibling merges can only be done with an on-chain transaction, otherwise a byzantine chain can withdraw new random coin ids and we have data availability problem like in plasma MVP. However if exiting non-sibling merges requires specifying input splits then we can skip the on-chain merging transaction as data is made available to exit and input splits can be challenged (with merges of merges both the splits and intermediate merges should be specified to exit the parent merge)
If we have predetermined coin and split values with free sibling merges and cheap on-chain/free merging to new ids, I feel this is good enough to work… no ? At this point I don’t see the benefit of custom split values ~
After giving it some more thought, I don’t see why you couldn’t challenge the exit of the 40ETH parent coin with the last valid 20ETH split transaction like in Karl’s blog at “Exit double spend challenge”.
So looking again at Karl’s spec, I’m not sure I see the possibility of the “Exit Double Spend” happening.
It is my understanding that for someone to spend a transaction, it must be signed over to them by its previous owner. As a result, if Charlie (Block 4) has a transaction signed to him from Bob (Block 3), who has a transaction signed over to him from Alice (Block 2), Charlie is only able to exit Bob’s transaction, since that was the one which was signed to him. If he tries to use Alice’s transaction as the previous one, the signature check should fail, as Alice explicitly signed her transaction over to Bob.
For reference, (imagine that there is also an arrow going from 4 to 3)
You can imagine that Charlie is another name for Alice, who is also related to the operator. After sending the token to Bob, Alice signed another transaction for Charlie and although it’s invalid, the operator let it through the check.
The signature check will passed, because it’s valid signature.
2 Likes
Got it, that works, thanks. Was missing this case for some reason.
It looks to me that Plasma Cash (similar to MVP) is vulnerable to a self-transfer-then-exit vulnerability.
If Alice has a coin and she transfers it to herself 1000 times, and then she cooperates with the Plasma operator, she seems to be able to exit intermediate UTXOs without a challenge, since only she will be possessing the fraud proofs.
I wonder if it has been addressed anywhere ? In my understanding users are not supposed to store unrelated transactions, so it seems that if Alice sends money to herself, then no one will have proofs because no one will care to save the proofs for these transactions.
In plasma cash the coin id does not change between transactions, and the plasma contract enforces that every coin can only be withdrawn once
Thank you - what about exiting once then ? What does prevent Alice to exit one of intermediate self-payment transactions (lets supposed the coin is now owned by Bob.
May be one needs to amended exit procedure so that it accepts as a fraud proof any future transaction involving the coinid? (not just the subsequent one?)
The exit game as written here only lets you cancel an exit by showing a “direct” spend of the exiting coin; if you modify the game to allow cancelling an exit by showing any future spend of that coin (and don’t change anything else), the construction becomes broken
The exit game here is secure because there is a client rule that a coin owner should be aware of (have inclusion proofs of) all transactions involving the coin, so that whatever intermediate payment Alice tries to exit, Bob knows how to cancel it
I think this system needs to be modified so that the user explicitly burns the coin before exiting it and provides proof of burn
The current mechanism seems to be incredibly computationally consuming. How can I use a system where for each 1c coin I got, I need to check a linearly increasing set of Merkle proofs. If I am paid a $0.01 coin and then I have to first to dowload megabytes of Merkle proofs and then keep on monitoring it forever, how viable is this solution?
If I have $10 as 1000 coins 1c each, the amount of dowload, storage, verification and monitoring I need to do seems overwhelmingly huge and growing linearly with time.
Explicit burn proof solves all these issues, you simply do not need to store anything
The linearly increasing set of proofs for 1 coin is indeed a downside. Note that there are some mitigations like Plasma XT: Plasma Cash with much less per-user data checking.
If you have a design that modifies plasma cash with “proof of burn” that solves this problem, feel free to create a separate post (I feel like this one is getting long) and I can look at it
Xuanji - I will, thank you
An alternative way to accomplish this might be for the operator to construct a merkle tree T committing to the number of times every coinid has been spent since the genesis plasma block, and to use snarks to verify the integrity of the root hash of the tree. Then a client checking the validity of a coin can download the witness for the branch of this tree that tells him that his coin has been spent h times, and then download h inclusion proofs.
For clarity, an example of this is shown below for 2-bit coinids. The top row shows the transactions in each block, and the bottom shows T after those transactions have been applied.
This has the advantage that the prover only needs to construct one proof per plasma block (I’m not sure what the prover burden is for the scheme where a snark is constructed for each coin).
We can also place the verification on-chain, for instance both the transaction root and T would be placed on-chain for every plasma block, and the plasma contract verifies a proof that T was correctly computed. @JustinDrake points out that this is a case where we can use cryptoeconomic verification, i.e., the operator just places the proof on-chain and makes a bonded claim that the proof will verify, and anyone can collect the bond by paying the gas cost to refute the validator.
Also, we can include T once every n blocks, and just force clients to download the (at most n) exclusion proofs for the blocks that were included after the last time T was included.
1 Like