Chain Commit gives first Entry exclusivity for 1 hour

[carryforward]

When the federated server first sees a chain commit, it should add it to a list and start a countdown. It should keep track of all the Chain Commits for each ChainID hash. multiple different commits of a single ChainID hash are allowed, however only one first Entry will be allowed.

When a chain/entry reveal appears, the ChainID which the Entry is tagged with should be checked against the list of pre-existing chains. If a chain does not exist, the ChainID hash should be checked to see if a Chain Commit for it exists. The ChainID will have been revealed at this point. All the Chain Commits of this can be checked for validity.

To check for validity, the Commit Weld must be be a SHA256d result of the Entry Hash concatenated with the ChainID. Any commit welds that fail will invalidate that Chain Commit and it should be ignored. The first valid commit seen (not as timestamped by the user) within the past hour should have the Entry Hash it commit be the first entry. If there is a valid reveal with a valid commit, but a different valid unrevealed commit was seen earlier, but less than an hour prior, then the reveal cannot be made into a first entry. The federated server must wait for the reveal of the first valid commit, or wait for an hour to pass from the first valid commit.

An attacker who knows your ChainID can delay a chain creation for an hour.

See the attached diagram.

[drobertbaker]

transferred to Pivotal Tracker 1/18/2016