I've been reading about the problem of front-running, especially in the Bancor case (https://hackernoon.com/front-running-bancor-in-150-lines-of-python-with-ethereum-api-d5e2bfd0d798). One proposed solution is using CREATE2 opcode (from EIP-86) - http://hackingdistributed.com/2017/08/28/submarine-sends/ But I am not sure I understand the whole concept, so it would be nice if someone could elaborate on this.
CREATE2 will compute the address of the newly created smart contract C as H(addrCreator, salt, codeC), where addrCreator is the address of the contract’s creator, salt is a 256-bit salt value chosen by the creator, and codeC is the EVM byte code of C’s initcode
So this basically means that you can "reserve" an address without revealing the contract there or what? And you can even send ether to it? CREATE2 then basically "turns" this seemingly random address into a smart contract?
The "submarine receiver" uses CREATE2 to instantiate a forwarder contract for himself but because the code is part of the hash he can just create the exact forwarding contract "submarine sender" had in mind (so both have to be synchronized in that sense)?
But that whole stuff doesn't happen atomically, does it? In the sense that when the nonce/salt is revealed the same block could also contain a "normal" send that would front-run the "submarine send"? Or that doesn't matter anymore because the timestamp of the original transaction that sent ether is used?
