Initializing the network with the genesis block

• Release the script used to create Rhoc/Rev conversion data
• Script together with validator list, can be used to create a local copy of the genesis block. This will be used by validators when approving the genesis block and thus launching the network (see protocol below)

Is there a risk of the network launching early?

• Not really. Would require most of our own chosen validators to decide to carry out the protocol below before the actual launch. Why would they do that?

Protocol for validators approving a block

An important assumption in this protocol is that such users will be able to reliably learn who the validators are. This assumption means that an attacker generating their own "approved block" using fake validators will not be successful as users will know that the validator set is not correct. We also assume that the block being approved, B, already exists from some other process; this protocol merely creates proof that enough validators agreed in its correctness. The protocol proceeds in the following steps:

1. A bootstrap node exists and will distribute B to those that connect to it.
2. The validators participating in this approval process know the bootstrap node address in advance and have also set up their own nodes with a copy of what they believe B and the minimum number of signatures should be. They also generate a signature based on this information and give it to the node.
3. B (a BlockMessage Protobuf) is communicated as part of a special message (UnapprovedBlock Protobuf) which contains additional information:
   
   1. The minimum number of signatures needed for B to become approved
   2. The timestamp this message was sent
   3. The amount of time during which signatures in excess of the minimum requirements will be accepted 
4. The bootstrap node will send these messages to any other node that connects to it. From the time the first message is sent, it will wait the specified amount of time for responses. After this time has elapsed, the bootstrap will check if enough signatures have been accumulated. If no then it will continue waiting for signatures, repeating the check with each new signature received. If yes, then it will send a special message (ApprovedBlock Protobuf) to all participants containing B and the following additional information:
   1. The minimum number of signatures needed for B to be valid
   2. The signatures obtained
5. When a validator's node receives the UnapprovedBlock message, the contained BlockMessage is compared with the version specified by the validator at setup. The minimum number of signatures is also compared. If they match then the signature – generated by signing B's blockHash field using validator's private key (corresponding to the public key used as their identity) and adding the minimum number of signatures given during the setup to the resulting hash treated as an unsigned integer – is sent along with the validator's public key as a response to the bootstrap node.
6. Once created, the ApprovedBlock message will then be available to for others to obtain, thus allowing them to also setup the blockchain network. An ApprovedBlock is valid if there are at least the minimum number of signatures, and each signature was obtained by one of the bonded validators signing in the way specified above.

Impacts on the Node software

• When starting in stand alone mode, no Casper instance is created. Instead new peers are sent the UnapprovedBlock Protobuf (will need to ask Pawel Szulc (Unlicensed) about adding in this hook). Moreover, the node will execute the signature accumulation logic. Once the ApprovedBlock message has been created, it will distribute it to all peers, then create a Casper instance based on the contained BlockMessage and become a normal bootstrap node (as per how the software works today).
• An additional flag must be available to start the node in "initial validator mode". This mode must follow the behaviour of point 4 above. When the ApprovedBlock block is received, a Casper instance is created from the underlying BlockMessage and normal node operating behaviour is resumed.
• When the node is started in all other conditions, it will not create a Casper instance until it has received a valid ApprovedBlock block. It will query each new peer for such a message until one is received.  After getting a ApprovedBlock block, it will create a Casper instance based on the contained BlockMessage and resume normal operating behaviour. Note that this can also be used to address "weak subjectivity" if we regularly issue newly updated ApprovedBlocks based on recently finalized blocks.