Clarify and make complete the 0-block-confirmations behaviors of child chain blocks

[pdobacz]

Preface

This issue aims at explaining the current behaviors of the child chain server and watcher implementations, with regards to the (perceived, but not accurately precise) feature dubbed "0 block confirmations" for child chain (plasma) transactions.

tl;dr Watcher presents plasma txs with 0-confirmations, but it's up to Watcher's consumer to wait confirmations for important plasma txs. There are edge-cases where Watcher's behavior can be improved to protect the user more.

Context

Child chain (plasma) transactions are submitted to the child chain server by users. They are included (gathered) into child chain blocks, which then become submissions to the root chain contract. Submissions are root chain transactions mined in root chain blocks.

As such, every such root chain transaction/submission/child chain block/child chain transaction can be attributed an ethereum height, which is where that thing ended up being mined (and anchored) in the root chain blockchain (that is, Ethereum ;) ).

As such, all of those things can have their finality and confirmations considered.

Current implementation

The Watcher (both security-critical and info flavors) doesn't wait for confirmations before processing and acknowledging child chain transactions from blocks (NOTE documentation improvements for this module underway #1410).

That is, the moment the submission is mined, the (valid) child chain block downloaded and processed, the tx is visible to the user.

On the other hand, Watcher presents the ethereum height with every child chain transaction, allowing the user to wait a suitable number of confirmations.

Rationale

Allowing the user to wait their specific number of confirmations is necessary, because every user might have their own stakes attached to any transaction considered. The user makes their best judgement on the # of confirmations required.

The reason why confirmations for child chain transactions are peculiar, is the following: An operative and "honest" child chain server will never "change its mind" on the contents (and child chain block root hash submitted in the submission) of a child chain block. Such "change of mind" would be considered a fault of the child chain server/operator/authority account.

Even if, due to a reorg of the root chain, the submission's ethereum height changes a little, the block itself shouldn't.

For a "change of mind" attack to happen (which would mean that a particular child chain transaction gets rolled back), the child chain would need to be compromised. On top of that, some form of a "double-sign" attack on the root chain would need to be orchestrated in simultaneity. Either: 1/ a 51% attack, allowing to trick other users into watching a "temporary" submission/block, that is later rolled back 2/ opportunistically leveraging a reorg and manipulating with the gas price do do the same as (1/) but with less certainty

What next?

There's a couple of things that could be done, to improve things (all tentative and possibly need to mix&match):

1. Improve user-facing docs to explain the status quo (where @Pongch? is the copy presented here OK for the audience?)
2. Detect the "change of mind" attack post-factum, in the Watchers (it is described in the Watcher specs BTW :tada:, called critical reorgs there). I'll file a separate issue for this (-> #1422)
3. Allow configurability of the "child chain block confirmations margin", which is now brutally hard-coded to 0 - to cater for the needs of clients who don't want it.
4. Decide on the opposite course of action: call this a mis-feature and require >0 confirmations for child chain blocks (!)
5. Market (or the opposite - un-market and discourage) the 0-confirmation facilities accordingly. Describe the risks attached and/or risk management necessary