From https://en.wikipedia.org/wiki/Confusion_of_the_inverse:
> Confusion of the inverse, also called the conditional probability fallacy or the inverse fallacy, is a logical fallacy whereupon a conditional probability is equated with its inverse; that is, given two events A and B, the probability of A happening given that B has happened is assumed to be about the same as the probability of B given A, when there is actually no evidence for this assumption.[1][2] More formally, P(A|B) is assumed to be approximately equal to P(B|A).
I think this is what OP meant. If something has been around for a long time it does probably mean it's less likely there is a really obvious security flaw, but it doesn't necessarily mean it is 'rock-solid' as plenty of things that have been seen to be 'rock-solid' in the past have turned out to be insecure.
π(π) = π(contract has been hacked)
π(Β¬π) = π(contract has not been hacked)
π(π) = π(contract is hack resistant)
Relevant conditional probabilities: π(π|Β¬π) =
π(contract is hack-resistant given that it has not been hacked)
π(Β¬π|π) =
π(contract has not been hacked given that it is hack-resistant)
The fallacy of the inverse would be assuming that:> The probability that a contract is hack-resistant, given that it has not been hacked, is approximately equal to the probability that it has not been hacked, given that it's hack resistant.
More succinctly:
π(π|Β¬π) β
π(Β¬π|π)
In https://news.ycombinator.com/item?id=27666484, the fallacy of the inverse was presented as "those contracts not being hacked yet is no proof that they are resistant to hacks" or "NOT (NOT A implies B)", i.e.: Β¬(Β¬π β π)
In summary: π(π|Β¬π) β
π(Β¬π|π) => the fallacy of the inverse
and
Β¬(Β¬π β π) => statement in comment
These two statements are fundamentally different.Note that the first statement is a comparison of probabilities, and the second is not. They're not the same. There might be another fallacy at play here, but it's not the fallacy of the inverse.
> If P, then Q.
> Therefore, if not P, then not Q.
In this case, we could plug in the below values:
P = Contract Hacked Q = Insecure
I.e. if the contract has been hacked the code was insecure. Therefore if the contract has not been hacked, it is not insecure.
Certain systems may have proven themselves somewhat over time but for this I say there is always the possibility for some extremely sophisticated attack and for any other new system they by definition wont have even this proven track record.