Enable chaining txs in a block under MVP mode

[boolafish]

TL;DR

The idea here propose a solution to chain txs within a block under Plasma MVP protocol. All txs within a block would be consider successful or failed atomically.

Why

Similar to #85, trying to solve the problem of plasma tx cannot be chained within a block.

Concept

By design, to use a MVP tx, it would need the confirm signature of the tx from the sender. This is the proof that user double checked the result of the tx inside the block. This two step design gives user the control to finalize the tx after block submitted.

Leveraging the same design, we can make user finalize all txs within a block instead of finalizing a single tx. By finalizing the whole txs within a block, user can decide not to finalize anything within the block and exit from previous blocks.

This does not provide fast finality, but remove the issue of plasma tx cannot be chained together within a block.

Design

1. Each tx add a field: targetBlock. This need to be the same as the block that the tx is mined into.
2. If a tx is using an input in previous block, it would need confirmation signature of the input owner signing-off previous block.
3. If the tx input is from same block (chained within a block), do not need the confirmation signature of input block (it will be the same block anyway).
4. To exit an output or to use an output in next tx which is in differenttargetBlock, the user needs to disclose the confirmation signature that sign-off the whole block (signing block hash). So in any case, the proof information to finalize the txs within the block would be disclosed at once.

[paulperegud]

First, the context on why we need something like targetBlock in place.

1. We require confsigs to challenge the exit to protect exits from inputs of in-flight tx.
2. This requirement opens an attack venue where I spent to myself and exit from the input. After it's finalization, I exit from the output. We protect against that by introducing special challenge type for the second exit. This works only because the length of such chain of spends is one. And that is true because operator requires user to provide confsigs for inputs when spending.
3. Now, multiple spending to yourself in single block would imply that the length of the chain is longer than one. This breaks the security.

EDIT: I'm basically reiterating things you wrote above here ~To fix this, we introduce two changes.~ ~a) We allow Alice to confirm the all her tx in a block as a whole. We modify contract to allow usage of this confsig in exits or challenges for every input owned by Alice in the block. If Alice will try to cheat and use attack described in #2, confsig she revealed can be used to challenge all of her exits from the block except for the exit from the youngest utxo of her in the block.~

~b) To prevent Alice from building long chains of transactions of dubious status, operator will not accept inputs from older blocks without confsig.~

With this mechanism in place, we don't need a targetBlock field.

[paulperegud]

~This affects first solution in #88, making it a bit simpler.~

It's applicable. We can validate blocks just as we are confirming blocks.

[boolafish]

[Note with Pepesza's call] It is not necessary to explicit the targetBlock. We can just rely on the fact where the transactions is mined to implicit get the targetBlock. So an output can be used in same block without confirm sig or in another block with confirm sig.

For example, a user submits A->B->C->D, let's say operator mined A->B->C in next block. User can confirms the block to finalize A, B, C. Now D is basically trash. It would never be valid. To keep on chaining, user needs to re-generate D' which includes confirm sig of the block containing A->B->C.

[boolafish]

[Note]

Extra Challenge for MVP

As mentioned in Pepesza's comment previously:

We protect against that by introducing special challenge type for the second exit.

We would need to same challenge for chained txs as well. It is to protect the following situation:

block1: [A]
block2 [B->C->D]

where A->B->C->D are chained together from same owner. Now the owner can choose to not confirm B->C->D first and exit A. Later, after the exit of A is finalized, confirm the block and exit from D. This creates a double spending situation via exit.

As a result, we need an extra challenge for this. I'd like to propose a challenge for "confirmation signature invalid". We challenge such confirmation signature is invalid by:

1. We found a previous finalized exit output
2. We prove there exists another tx in the same block of the confirm sig that is using the already-exitted output.

Now, whatever exit that is using this confirmation signature is invalid.

Limitation of chaining

The whole chain must be in the same owner. We probably cannot chained payments: Alice sends to Bob and sends to Carol. Because, what if Carol confirms the block without Bob's confirmation ?

[paulperegud]

@boolafish @chriskohlhoff

BTW, this one also solves https://github.com/omisego/docs/issues/22