Remove the randomness feature from Honey Badger.

[afck]

A randomness primitive is desirable for a lot of smart contract use cases. Basically it suffices to initialize a (possibly on-chain) PRNG with a new seed in each epoch that cannot be known before that epoch.

This is already achievable with hbbft, by using a separate Coin instance's output value as the pseudo-random seed. However, the coin must not be flipped before the epoch's batch has been determined, otherwise a validator would be able to make their choice of proposed transactions based on the random seed. So currently, the coin would have to be flipped after Honey Badger has output, which adds another round of messages, and therefore decreases block rate/increases lag.

We could make Honey Badger output twice for each epoch: first to notify the user that the new batch has been decided but not yet decrypted, and then, a bit later, to produce the actual batch. That would allow us to initiate the coin flip after the first output, in parallel with the decryption round.

Alternatively, we could make the randomness an optional feature of Honey Badger itself, so it would do the above internally, and just output a random value together with each batch. That might be a slightly more convenient API, but it would be less flexible: there could be use cases where one wants to do something other than flip a coin at the earliest possible moment where a batch is decided.

[afck]

As a zero-overhead alternative:
This value looks like it should be unknowable in advance and independent of the set of validators that provided a share. Maybe we could xor all those values from all accepted contributions, and use that as the random seed?
(It's just going to be a bit ugly to modify the API so that we can extract it without overhead.)

Edit: To clarify, the value we'd use as a source of randomness is sku[0] from #40 (comment), i.e. the result of the interpolation of encryption shares. This is the product of the secret master key and u, where u is the product of a random value (chosen by the encryptor) and the group constructor.

Question: Is this value safe to use as a random seed? I.e. is it unknowable in advance (before f + 1 parties published their decryption shares), and more or less evenly distributed? (The latter is probably not even necessary: we'd just use it as a seed for a PRNG.)

[afck]

I'm pretty confident that this would be suitable: For every individual contribution, we'd get the product of the public master key with the proposer's chosen random value. But we'd sum up (or xor) N - f of those, from different nodes. Some of those are honest and chose a genuinely random value.

With #209, however, we would either not produce a random value in every epochs, or we'd have to resort to another method (use the common coin after all) in those epochs.

[afck]

#170 would probably make it insecure, however, since we'd learn about the other nodes' values before Subset terminates…

[afck]

Let's implement this step-by-step:

• Add a "random value" option to Honey Badger. If it's enabled, a coin is flipped in every epoch, and its result is added as a random value to the batch.
• In every epoch, check whether Subset optimization is disabled and Threshold encryption is enabled, and if that is the case, don't flip a separate coin: use the above value with zero overhead instead.

[afck]

As discussed, we will change random_value to a u16 instead, and use a simpler, safer, more efficient and more flexible way to produce the randomness:

• Each validator puts a random [u8; random_value] into their contribution.
• The random output is the xor of the accepted contributions' values.

This is only secure if threshold encryption is enabled, but it doesn't require an additional coin and provides a configurable number of random bytes, as required by poanetwork/parity-ethereum#34.

So what we'd need to change is:

• Make the random_value parameter a random_bytes: u16.
• Remove SigningState from epoch_state.
• Instead of serializing only the proposal from Honey Badger, serialize (and later deserialize) a tuple (struct?) containing that proposal and a random [u8; random_bytes] (as a Vec?).
• When outputting from EpochState, xor all the accepted contributions' random values and include them as the random_value: Vec<u8> in the batch.

[afck]

As discussed, the above is trivial enough to leave it to the user: Let's remove the random_value option entirely, and just document how to produce len random bytes per block:

• Make sure EncryptionSchedule::Always is selected (default anyway).
• Add a random [u8; len] to each contribution.
• When a batch is received, xor all the contribution's random bytes together to produce a single, random [u8; len].