Whitepaper - Factom With Cover

Factom uses a delay in claiming the Chain to prevent this attack, similar to Namecoin’s solution
along with a set of revealed secrets to ensure the first one to pay for a ChainID has the right to
create the first Entry in that Chain. The payment includes these three pieces of data:
●
●
●
Hash of the ChainID
Hash of the (ChainID+Hash of the Entry)
Hash of the Entry
An attacker could see the attempt to purchase, but will not know the ChainID. Because they do
not know the ChainID, they cannot create a valid second parameter.
Once this payment is recorded, the user must wait for the Directory Block holding the new Chain
payment to finish, and the next Directory Block, a delay of one to two minutes.
Now the user reveals:
●
●
The Chain Name (series of byte arrays) that hash to the ChainID
The Entry that matches the Entry in the payment
The attacker cannot create a false payment, and insert their first entry without revealing the
ChainID, which will match the earlier payment and invalidate their transactions.
Dictionary Attack
In this case, the attacker runs through all the Chain Names deemed to be possible or desirable
and creates their ChainIDs, and the hashes of those ChainIDs. Then they watch for someone
trying to create those Chains.
Now the attacker can front run on a match. Because on a match, they know the ChainID, so
they can construct a proper, but malicious Entry of their own, create the proper Chain payment
and submit it rather than the users payment.
If the attacker gets ahead of the user, then they will win. The defense against a dictionary attack
is to avoid common name spaces and to submit your payment to multiple, long standing nodes
in the network.
In Factom, the flexibility of defining the Chain namespace makes efforts to hog the namespace
ineffective.
31