Child chain doesn't watch "Exit" event

[kr8534]

It seems that child chain doesn't watch the RootChain.sol's exit event.

child_chain.py only has apply_deposit, apply_transaction but it needs a function for watching exit event and mark UTXO to spent after exit event come downs to log in RootChain.sol's

If I miss something, please let me know :)

[smartcontracts]

Yep, this definitely needs to be implemented.

Open question: Are events good enough? Events will be triggered even if the user's node experiences a reorg. The user should only ever receive the event if it's definitely going to be included in the child chain.

For example: 1) Alice submits an exit in Ethereum block N. 2) Bob (the operator) receives block N, an event is triggered marking Alice's UTXO as spent. 3) Alice's tx is reorg'd out of existence. 4) Alice can no longer spend her UTXO on the child chain (assuming Bob is honest), so Alice must exit.

That isn't awful from a security perspective, but it's definitely not good UX.

Another example for deposits: 1) Alice submits deposits 001 and 002, each for 1 ETH, in block N. 2) Bob's receives receives N and events for both deposits. 3) Deposit 002 is reorg'd out of existence, deposit 001 stays. 4) Alice now "has" two deposits on the child chain. She spends 002. 5) Bob's node doesn't recognize the discrepancy and accidentally publishes an invalid block.

This is more obvious.

Basically, I think we need to come up with a better mechanism that waits for root chain events to become "final" before they're included in the chain. Easiest way to do this is only to process events that are N blocks old.

[kr8534]

Thanks for kind reply. :)

open more question, as you said, how can we force child chain to apply plasma contract's event? how can end users assure that (deposit / withdraw) are reflected correctly to child chain with protocol layer? It seems to be a answer that if we use plasma cash, but have no idea with plasma MVP. :)

[smartcontracts]

Honestly I think the answer for Plasma MVP is that users can't be sure the operator has included their deposit/withdraw. In either case it's basically just generalized to operator misbehavior. If a user makes a deposit and the operator fails to include it, then it's sort of like if the operator is censoring the user's transaction and the user is forced to exit from the deposit.

The operator could send the user a confirmation that the deposit was included in the child chain, but that basically just adds blame in case the operator later removes (or loses somehow) the deposit.

[kr8534]

Sure. It would be the answer :) just as the simple withdrawal mechanism.

[kasima]

From IRL conversation with @kfichter, also abstract out Event Listener service.

[smartcontracts]

Fixed in #137