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]
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.
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.)
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
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.
What proof are you referring to?
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? 
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
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! 
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.)
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?
This is my attempt at making a comprehensive document about Plasma Cash, feedback much appreciated!
Abstract:
Plasma is a framework for scalable off-chain computation. We describe and evaluate Plasma Cash, an improved Plasma construction which leverages non-fungible tokens and Sparse Merkle Trees to reduce the data storage and bandwith requirements for users. We analyze the cryptoeconomic exit and challenge mechanisms used to keep user funds secured, even when the Plasma Cash chain’s consensus algorithm is compromised. A reference implementation is provided for evaluation. Finally, we briefly discuss further improvements that can be made to the Plasma Cash protocol such as arbitrary denomination
payments, less user data checking, fast and optimistic exits.
Wolk just released a code-complete implementation of plasma-cash/debit, along with a new Anchor Transaction type that supports Layer 3 chain’s provenance on Layer 1.
https://github.com/wolkdb/go-plasma
We encourage everyone to clone it and Build something awesome with Plasma!
Is it possible? Please correct me if I’m wrong.
I think users can skip the amount of history data of their coins if they want to, by adding new lock transaction type to Plasma Cash. The transaction is like “this coin cannot be sent until Nth PlasmaBlock”. In this case, I think user need not to send and store history between the block include lock tx and Nth block.
And we have to modify challengeExit and respondChallenge in the RootChain contract and ensure that the challenger and exitor can’t use invalid transactions.
example)
tx1: Alice lock her coinA until 150th Plasma Block. This tx1 is in 100th Plasma Block.
Off course Alice sign this tx1. She can’t send coin A to anyone between 100th and 150th PlasmaBlock.
In case of that Alice send coin A to Bob before 150th PlasmaBlock as tx2
challengeExit like this.
In case of that Alice send coin A to Bob after 150th PlasmaBlock as tx2
challengeExit
I’ve been thinking that the Sparse Merkle Tree used for membership and non-membership proofs can be probably replaced by Vector Commitments which can be aggregated and batched, as described in https://eprint.iacr.org/2018/1188.pdf.
Is anyone working on this, and/or a onchain Vector Commitment verifier?
What ultimately happened with the “merge/split” mechanism you’re referring to here? I.e., is there are a more detailed write-up somewhere / did it get ultimately get “split/merged” into some new variant, etc.?