Principal-agent problems with tokens hold by the venue

[paulperegud]

In case when venue and operator are both hacked.

1) Trader makes a deposit and issues an order. 2) Venue creates a settlement, operator places into block that steals and withholds the block. 3) Trader attempts to exit a deposit. 4) Venue waits for the last moment to challenge the exit with trade settlement transaction. 5) It is too late for trader to exit from settlement outputs, so hacker steals funds on venue related to orders

This attack works for both MVP and MoreVP. Tx state transition proofs do not help here.

Possible solution - since venue holds funds in the name of the trader, instead of cancelling the exit, replace the exit from inputs of settlement with exit from outputs belonging to the trader, while preserving original exit priority.

The issues with this solution are:

• complicated
• challenge is costly, since it proves not only validity of trade settlement but also finds appropriate outputs
• requires high bond on exit from the deposit or from funds on exchange by trader
• this solution is not really compatible with #86, since the outputs in question can be anywhere in a chain - gas cost of the proof is potentially huge.

[slavamirovsky]

Thanks for sharing @paulperegud . Let's brainstorm on it. FYI @whoisjeremylam @kasima @boolafish

[boolafish]

I will note down the implication of this problem, this means we are at best RC without solving this.

[boolafish]

[throw out some idea] Currently we got three possible proof, multi-sig, SGX, zk-snark. Alternative solution is to protect that on confirm sig.

• With multi-sig, we can make the confirm signature must be multi-signed as well. This would bring us back to same level of trust with multi-sig.
• With SGX, we can let the hardware only sign the confirm sign after verifying the block. This is with the assumption of it is impossible to hack the private key out. Well, with SGX we might even go without operator so.....
• I have no idea how to save zk-snark, unless we prove the whole block with snark. Hmmm, how about zk-snark proof + SGX confirm sig (just going crazy lol)

[slavamirovsky]

Thanks for sharing.

I have got an impression SGX thing looks good for now. I would risk going for it during MVP1. This is practically "Plasma level security". Did we get a feedback from this super hacker from Warsaw? (@paulperegud did our friend get back from holidays?)

Last option is the coolest. But do we have some progress on snarks that let us hope for it?

[paulperegud]

@Nikodemek18 yep, here is the result of my meeting with him: https://github.com/omisego/research/issues/95#issuecomment-499614468

[boolafish]

[Pepesza's idea] Potentially use snark to prove the "chained txs" within a block is valid, so you can replace input with output.

[paulperegud]

This trick might work because: 1) venue has quite a lot of time to compute such snark 2) CPU time is cheap, and venue is well motivated to do that

If we will improve the situation and use recursive snarks, everyone (not only venue) will be able to compute a snark that summarizes mapping between inputs of trades and outputs of trades for a whole block.

[boolafish]

We can probably solve this by decreasing challenge period, or just make sure challenge period is, for instance, half of the period of “exitable” waiting period.

By doing so, trader would have enough time to start next exit when data withheld.

[boolafish]

Ok, that only works when not chaining :(

[paulperegud]

We can probably solve this by decreasing challenge period, or just make sure challenge period is, for instance, half of the period of “exitable” waiting period.

I believe that any challenge period specific to role can be exploited by operator impersonating such role. I.e. this does not work in general. MoreVP restriction that some claims can be done only in first period is something else - it's about limits on claims, not on limits on challenges to claims.

[boolafish]

I believe that any challenge period specific to role can be exploited by operator impersonating such role. I.e. this does not work in general

Can you elaborate the reason for this? I am lost on this statement. @paulperegud Or let's sync in our call session.