==> something got wrong when I tried to post, so here it is, hopefully, again...
Well, this is the kind of cryptographic "common sense" that doesn't make sense. As I said before, one has to assume, in a cryptographic design, that the cryptographic primitives are about at the security level that is known - for the simple reason that one cannot predict the deterioration of its security level by future cryptanalysis. As far as one goes, it can be total.
You're either not comprehending or being disingenuous. Do you not know that Shor's algorithm is known to break ECC but not hash functions? I had already told you as follows, that the hash has greater security for expectations of quantum computing. It is a prudent precaution.
I answered that already. If you think that your system has to work when a component is totally broken, you don't use that component. My answer to your rebuttal was already written out above, as I expected this rebuttal, but you're missing the point I'm making:
if 160 bit ECC is not secure in the long term, then 128 bit ECC is not secure in the REALLY REALLY short term. So this argument backfires.
Note that I'm totally aware that any public key cryptographic system is *potentially* easier to attack crypt analytically than the symmetric-key mixers that are used in things like hash functions. But that doesn't solve the issue on the contrary.
Again: if you need a symmetric-key hash algorithm to keep your public key of 320 bits (160 bit security) safe from a quantum computer (I don't believe in them, but that's another matter), then using a 128 bit public key is going to be cracked before it got included in the block chain.
If a 160 bit secure public key cannot survive 50 years of attack, a 128 bit secure public key cannot stand a second of attacks.
This is what I tried to explain to you: if you think that ECC is going to be fundamentally broken, by quantum computers, DON'T USE IT AT ALL. And if you use it, assume that a certain security level is going to be secure, and apply it. But don't "protect" the broken system with another system ; because you are going to use the broken system at a certain point, and then you're done and that's what happening here.
Again, if 160 bits security ECC won't do where bitcoin is hiding it with a hash, 128 bits security won't do openly in the very short term where bitcoin needs it.
If you argue that it doesn't matter if we have the hashes when ECC is broken by quantum computing, because the transactions can be intercepted and cracked by the attacker before they are confirmed in the network, you would not be thinking clearly. Because quantum computing would at its inception stages likely be only able to break long-term security but not short-term. So there would be a period to transition as I already stated in the above quote from my prior post.
No, you don't seem to understand that if you can crack an ECC of 160 bits security in the long term (say, 50 years of computing), you can crack an ECC of 128 bits security
in a single second *with the same equipment*. There's a factor of 2^32 = 4 billion between them. I was only taking 16 bits, this is why I arrived at an afternoon but between 160 bits and 128 bits there are 32 bits.
Look: 50 years = 50 * 365 * 24 * 3600 = 1.57 billion seconds. If your quantum computer can crack a 160 bit security ECC in 50 years, it can do that 4 billion times faster for a 128 bit ECC, because the search space is 4 billion times smaller. ==> 0.4 seconds.
This is why I tell you that it doesn't make any sense to have (strong hash) 160 bit security in the long term, and (weak ECC) 128 bit security in the short term.
But you're analogy does not apply, because Shor's algorithm (a form of cryptanalysis) is already known! It is not a future unknown.
My point is that if you assume this to work one day, then you shouldn't use ECC. And I just showed you why.
Also (and this is a minor point which isn't really necessary for my slamdunk) you are conflating the breakage of discrete logarithm math theoretic security with the security of permutation algorithms of hash functions. I repeat the distinction between the two which you have failed to assimilate:
I'm perfectly aware of that. But that's not the point I am making. The 160 bit hash security is USELESS if the 128 bit ECC is not secure. I'm perfectly aware that ECC has a higher chance of being broken than a hash function. I'm not believing in quantum computers, though. I have my own reasons to think so on which I will not digress. But that's not even the point. If you THINK that they will exist, simply don't use ECC (nor any known form of discrete log public key crypto) because it is TOTALLY BROKEN in that case.
There's no point in having 300 years of a secure hashed public key on the chain, which is then broken the second after you propagate your transaction and the node you send it to modifies it.
You seem to be focussed on the long term security, but what fails utterly in the consistency of the system is the *short term security* under the assumptions made. (and yes, I also made that error in the beginning of this discussion)
It is not the 160 bits that is insecure: it is the 128 bits after propagating one's signature and public key IF ever one makes the assumption that 160 bits ECC is not long-term secure.
There's no point discussing the rest as long as you didn't see my point here, so I state it once more:
If ever you have a doubt about the security of ECC in the long term with 160 bits, then 128 bits ECC security is gone essentially IMMEDIATELY upon broadcasting your public key and signature, making the entire concept broken. This is why one should never use a crypto primitive of which one has a doubt over its security.