Ok so a naive attack would work this way:

1. Create many certs for many different domains, each with a different Bitcoin address.

2. Send an amount of bitcoins to each address.

3. If in the future legitimate domain owners create legit certs, the attacker could present his own malicious cert and victims could potentially accept the malicious one as legit even when they are aware of the more recent legit cert, because the malicious one is older.

Pros and cons of the attack:

- Pro: There are no permanent costs to this attack, only temporary ones. Bitcoins have to remain in these addresses for the duration of the attack(s), but the attacker can get his coins back afterward.

- Con: The attacker can attack only a limited number of domains, as more and more coins become needed.

- Con: Malicious certs must be created earlier than the legit certs

So perhaps users should not trust certs that have been created earlier, but those that have the most coins locked in. But then nothing prevents an attacker from creating a cert with many coins (more than what the legit owner spent) to perform an attack for a few days, then later get his coins back when he doesn't need the cert any more.

So really there should be a fine balance when evaluating these 2 properties: trust old certs that have many coins locked in. But sometimes trust newer certs if they have more coins locked in. But not too new or else it might just be a sign of an attack. This fuzzy logic would probably cause many false negatives or false positives that ultimately could make end-users not trust the system.