Plasma Cash: Plasma with much less per-user data checking

new-extension

#102

This is very interesting. Is it possible to put this “# of time spent” into the UTXO itself (avoid having a separate tree and increase the block header size)? Meaning the output of the signed tx now is an object.

[blknum1, txindex1, oindex1, sig1,       # Input 1
 blknum2, txindex2, oindex2, sig2,       # Input 2
 newowner1, denom1, #spent1 +1           # Output 1
 newowner2, denom2, #spent2 +1           # Output 2
 fee]

#103

Ah yes, that might be better. Then the snark can prove that # of times spent is nondecreasing.

Plasma cash doesn’t have the two inputs and two outputs scheme you pasted, though.


#104

True, but still, I think it’s possible to have leaves in Plasma Tx Tree as an object with affiliated fields . I haven’t thought it through, but possibly we could put a { historical owners => # tx } object for each output. And a possibility from this is when this coin is being exited, root chain will charge historical owners for the number of tx being done on this coin. So that you could imagine over time, as more coin being exited, the tx will be eventually paid out. (assuming constant tx fee for each tx.)


#105

@danrobinson

Hello Dan.

After the last Plasma call I really liked your idea of “Plasma Debit” with quasi-channels user <-> owner. I work on the More Viable Plasma in parallel, but do you want to join some forces to make a “debit” prototype? The most interesting problem I see there right now is how to supply initial “empty” coins, so a user can get one and be able to accept the payment. One option is just deposit a full one and “split” it to “completely full” and “completely empty”, but I’d like to about splitting operation entirely and leave only transactions of A <-> operator <-> B type.

Sincerely, Alex


#106

Hello everyone. I want to get a better understanding of the proof used in Plasma. I have a very basic understanding of cryptographic proofs at the moment.

Do any of you know of good resources that can help me catch up to the cryptographic proof conversation?

Thank you.


#107

What proof are you referring to?


#108

Do I understand this correctly: if Bob transfers his coin to someone else and then attempts to fraudulently exit to the root chain, anyone including the operator can challenge the exit and claim the bounty (assuming transaction data is available normally from the operator).

In the implementations I could find, only information similar to this seemed to be required to challenge an already spent exit, all of which I understand should normally be publicly available to all observers:

 function challengeSpent(uint coin_id, uint blk_num, bytes tx1, bytes proof)

So as long as there is at least a single honest observer, users do not realistically have to check the root chain every week since the bounties incentivize third parties to do this monitoring. This would seem like a much more friendly situation for end-users, especially if they have only sporadic access to internet for example. Would this seem correct or am I totally on the wrong track here? :smiley:


#109

Indeed, challenges can be done by any incentivized party that has access to the information required to make the challenges happen.

However, delegating challenges (and/or exits) is not trustless - currently. Essentially, if you give a 0.1 ETH bounty to someone for challenging all exits for your 5 ETH coin, that someone can be bribed by any faulty exitor to not challenge for any amount bigger than the bounty, say 0.2 ETH.

Work on trustless delegated challenges has been done on the state/payment channels end in this paper which may interest you by @stonecoldpat et al in https://eprint.iacr.org/2018/582.pdf


#110

Interesting. If I got this straight, in the case the attacker tries to exit a coin worth 10 ETH, there is a bounty of 0.1 ETH and 100 observers are watching the chain, to bribe all observers it would then cost > 10 ETH.

So if the bounty is bigger than the value of the coin attacked / N of observers, either observers will not gain anything by accepting the bribe or the attacker will spend more on the bribes than what he stands to gain from the attack.

Thank you for the paper reference also! :slight_smile:


#111

A perspective change that I think is important for Plasma Cash is to abandon the idea that Plasma chain data is public by default. There should probably be nobody other than the operator who is observing the entire chain.

You might voluntarily provide some third party with your coin history every time you spend a coin, so that they can challenge attempted outdated withdrawals. But the operator shouldn’t just make your coin history public unless you told them to.

(I’ll also note that this only covers outdated-coin exits, as you mentioned. The possibility of a malicious operator means that you need to be online once a week anyway, since you might be the only one who knows that an attempted exit was actually a malicious attack by the operator.)


#112

If the chain data should not be public henceforth, wouldn’t that massively alter the promised future in the original white paper? That we can have more than one operator, they all agree on a state (optionally with MapReduce delegation to child chains) and the resulted blocks are published on Ethereum to obtain its security? Or is it just Plasma Cash which makes these trade-offs in order to achieve fast and reliable coin transfers?