The plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.
I don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.
What if Bob, Alice and chain operator are a single entity 
? Chain operator deposits 1ETH and gets 2ETH out .
Alice (operator) first exits the chain while Bob doesn’t challenge her.
After that Bob (operator) exits the chain by using Alice’s commitment.
Nobody else can challenge Alice’s (operator) and Bob’s (operator) exit.
After exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.
Alice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.
You are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.
Hi @denett,
thanks on your help with all of this. 
Really appreciate it.
Could you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.
As far as I can tell there is only one method to challengeExit.
After Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.
Let us assume some UTXOs where made after this.
So then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.
@denett Could you please help me to understand this?
As I said here:
To proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.
I think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.
One thing which is unclear in my head is why does one need to allow bad exits at all?
One can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …
This seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …
Why is a validator-based approach good for Casper and bad for Plasma ?
Actually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …
@denett Oh, I’m sorry, I’ve missed that part of your previous answer.
Correct, you’ve said it It’s hard for me to discuss these things over forums.
It would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.
I believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.
What is the downside of a solution to have two colored UTXOs on plasma chain?
One can exit both red and blue UTXOs.
Only red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.
If exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.
I guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.
Yeah, that was my thought as well.
I was referring to:
One can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …
What do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.
This is probably also an interesting link
https://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ
not sure why nobody posted this here.
Some people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.
What I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain
Plasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released
Cryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …
Heads up: this might be a naive question, and might have been discussed somehere else.
One great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.
Am I wrong? Or is the solution to deploy B to P_A if this is needed?
If this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?
Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.
Nothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.
Your question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?
When I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.
In theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?
under MVPlasma this is indeed something we sacrifice, or don’t care about.
Yes. Moreover, I doubt anybody is going to implement Minimal Viable Plasma. See Plasma Cash.
What do you mean by a dapp’s plasma contract? On which chain does this dapp reside? What does this dapp do with Plasma?
Sorry I was under the above conditions where we had one dapp per chain. So what I meant is that Chain A can be settled to both main chain and chain B. Not sure how that would work, but I guess nothing stopping you from doing it.
Chain A can be settled to both main chain and chain B.
That sounds like either two parents, or a parent and a grand parent.
Two parent chains sharing one child chain would cause some complications. I don’t know why that would be wanted, except that it sounds fun.
A parent and a grandparent will appear in the Plasma story, but Minimal Viable Plasma is minimal, and it doesn’t have a grandchildren chains because the child chain does not contain code.
In more complicated versions of Plasma with a grandchild chain, users should be able to exit to the grandparent chain, in case the parent chain is not working.
I think the current version of Plasma is not meant to be running dapps … It is a bitcoin-like UTXO chain and it is not so easy to run Turing-complete statefull smart contracts on UTXO