Correct the intractable brute force collision attack is reduced to 2^160 bits.
That is the definition of the security level.
Yes for the brute force attack, but when attempting to find a cryptanalysis break (i.e. break the internal mixing of the hash function) we have to consider the fact that SHA256 does internal mixing in 2^512 bits space.
Satoshi outsmarted you.
I suggest you consult with Daniel Bernstein or perhaps @johoe. Raise the issue in the Bitcoin Technical Discussion forum, if you want to have a serious technical discussion about it.
Here we aren't concerned about an intractable brute force attack. We are concerned about cryptanalysis breakage. And non-brute force, cryptanalysis collision attacks require attacking the input (and output relationship) of the RIPE160, not attacking the input of the SHA256 whose output in the input of the RIPE160.
Of course not. The *naming* of different steps in the process is just this: a matter of naming. The combined SHA-256 / RIPEM160 hash function is a hash function by itself.
Agreed it is but collision attacks based on distinguishers, boomerang attacks, and other forms of cryptoanalysis which attempt to reduce the intractability are what concern us.
The 160-bits is more than sufficient for a brute force attack defense and greater than the 128-bit security of the 256-bit ECC.
It will not be the owner's S, but that doesn't matter.
This particular S will:
1) provide a P that will be able to verify the signature generated by S
2) have the P hash to A
and that's all that is needed.
In fact, 2^(256 - 160) = 2^96 different (S,P) key pairs will satisfy the needs to spend the transaction output.
Although you try to make that big number of potential duplicates sound like a big deal, it is in fact
intractable to find one because of the 2^160 bits of collision space in the brute force attack case.
The whole point is that if you consider a security level of 160 bits sufficient (which it most probably is), then there is no need to go to a 256 bit key.
Disagree. It is needed because the effective security is as you stated only 128-bits due to rho attack.
Now, ONCE the public key is exposed (which is normally, if no address re-utilisation, only when the payment is broadcast), the security of a 256 public key scheme with full cryptographic security is 128 bits (all schemes are vulnerable to Pollard's rho attack which halves the number of bits). As such, it seems at first sight that a 160 bit hash doesn't seem to decrease the security of the key pair, a 256 bit key is in any case not more secure than 128 bits.
That is why we need the 256 bitlength security for the ECDSA. That has been my point. Don't conflate hash function attacks with ECC attacks.
There is, again, an incoherence in the required security levels, as I pointed out.
There is no incoherence. The 160-bit hash brute-force security greater than the 128-bit security level of the ECC.
However, such security is not needed. The public key only needs to be secure from the moment of broadcast until the moment of integration in the block chain, that is, about 10 minutes. There is no need for 128 bit security in that case.
If you would have taken 80 bits of security, that is, an elliptic curve crypto system with 160 bit keys, then there would be only a single key pair that corresponds to the address. You wouldn't have wasted 96 bits for each input. The long time security would still be 160 bits, because of the security of the (combined) hash function. And 80 bits of security would be more than sufficient to keep the secret the time between broadcasting the signature and the key, and its inclusion in a block.
Incorrect. Think about it.
Correct ; think about it
And if your transaction fee is too low and doesn't get into a block? Or if there is a chain reorganization?
You're advocating reducing to 80 bits, so that means in the future if someone has to computational capacity to break 128-bits in
2.814749767×10¹⁴ / 60*24*365.25 years, then then at your suggested 80 bits they could break it in 1 minute.
This error comes from thinking that one has to crack the scheme "backward" one by one: first one has to crack RIPEM160, then one has to crack SHA-256, then one has to crack elliptic curve discrete logs on 256 bits. But that is not necessary. You can see the system as a whole, and you shouldn't see it as reversing several individual steps. You can easily see the problem with that notion. Suppose that passwords are protected with a 20-bit hash.
Please don't lecture me. I understand all that. But you got lost in the trees and didn't see the big picture point.
==> clumsy crypto.
Nope. Your analysis was clumsy.
--> no argument yet.
My argument is a slam dunk already.
In the whole system, you have incoherent security levels, which cost in terms of room on the block without added security, as I demonstrated. Simply saying that it is wrong is not an argument.
If you are going to be disingenuous then we can't have intellectual discussion.
Please stop thinking Satoshi made mistakes. He was more clever and exacting than you. You really want to believe the global elite didn't create Bitcoin. And you really want to believe Bitcoin is going to fail. But your beliefs do not align with objective reality.
I am not trying to insult or demean you. I know you are very smart and I have appreciated all your very high-quality analysis. As well you turned me more on to the concept that PoW is a crab mentality immutability game theory.
I am just noting that your confirmation biases for wanting Bitcoin to fail, are I think causing you to be overconfident and not skeptical enough on your analysis.
I don't want anything. But I see an adulation of Satoshi which is based upon self-referential beliefs as if the guy was a genius.
No my opinion is based in fact of the genius game theory and concept. And I see no math flaws. You have shown none.
When I present simple arguments of where he made mistakes, and demonstrate that with obvious simple mathematical arguments, the only way to counter that, is with better mathematical arguments, not with the self-referential belief that
I have refuted your misunderstanding of hash cryptanalysis security. If you don't believe me, go ask a recognized expert. You are simply wrong. I've tried to explain why. If you don't believe me, go consult with a recognized expert such as Daniel Berstein.
Maybe I'm missing something. But my analysis is basic cryptographic design methodology.
1) fix your security level you want to attain, in what cases.
2) design the crypto so that this security level is reached *consistently* throughout the design.
He didn't make any mistake in the crypto design. I have explained it to you above.
There is no reason to overdesign (nowhere), and there is no reason to underdesign (nowhere). The first is a useless penalty on computing resources ; the second is putting into danger the overall security.
The point of using 160 bits is compression of block size. What is the #1 issue of Bitcoin right now? Block size.
The 160 bits is more than the 128-bit security level of the 256-bit ECC.
It is a perfectly balanced and clever choice.
One has to make assumptions about the cryptographic soundness of the cryptographic primitives used. There's no reason to assume a finite loss due to crypto-analysis: a system is considered broken, or not broken. Not broken means that up to a few bits, the known security level / key length is accepted as a given ; broken means that anything can break down, so you simply cannot design for that.
You are uninformed. Crypt-analysis breaks on hash functions typically lower the security in bits, but don't lower it to 0 bits. By frustrating crypt-analysis with the prehashing with SHA256, this RIPE160 is deemed to be a perfect balance of compression and brute force collision resistance.
We have to be assuming that the combined hash function SHA-256 / RIPEM160 is cryptographically secure*, of an UTXO is 160 bits. There are (as you point out) good reasons that this combined hash function will remain for quite a while secure (that is, will withstand cryptographic analysis). It is hence at a security level of 160 bits. Not more. Not less.
Ok great so you acknowledge that I was correct on that point. Thanks.
We also have to accept that elliptic curve crypto has a security level of half the key length. If the specific group is broken in the future, depending on how it is broken, anything can happen, and a 256 bit key system can just as well have 100 bit remaining security, as 32 bit remaining security. So one cannot design anything on that basis.
Hence, 256 key length is 128 bit security.
There are a few possible security design criteria that Satoshi could have proposed:
1) overall security 160 bit. As I indicated, his 256 bit key has only 128 bits security, so this is under-designed --> failure.
He didn't have any choice to increase the ECC security. The industry acceptable established choices were 256 bit and less at that time.
Also that would increase the block size because of signatures.
He made the most ideal choice.
2) overall 128 bit security. The hash is over-designed. --> failure
I already explained in this post that it is not overdesigned.
3) 160 bits security for long term, 128 bits for short term (key exposure). This corresponds to the actual bitcoin design, but makes no sense, I will tell you why.
4) overall 160 bit security for the long term, highest possible short term security with no room penalty. This is the most sensible economic design, which results in an elliptic curve signature with 80 bits security, matching the 160 bit key length.
Nobody would have invested long-term in Bitcoin with 80-bit public keys. And I don't even think there was an established 80-bit ECDSA curve available.
Also the differential between 160-bit and 128-bit is 2^32 which is a factor of 4 billion longer to crack with brute force. So you argument about not being balanced between long and short-term seems incorrect.
There is another factor too which you might not be considering, which is that afaik the public keys of the wallet are stored on the user's machine while the private keys may be stored in a paper wallet which is much more secure. So 80-bit public keys would be very insecure to store on user machines with all the viruses and hackers we have these days. If I am mistaken about this point (actually I never studied any wallets), then my other points remain.
==> Only 1, 2, and 4 make cryptographic sense. 4 is the most economical design even though it is cryptographically not coherent, and 1 and 2 are the most coherent designs.
That doesn't make any sense. You are admitting the long-term hash should have a greater security than the short-term ECDSA. Thus #3 is most sensible.
I will now explain you why the actual design doesn't make sense. The ratio between 160 long term security, and 128 short term security, would make sense if the long term is 2^32 times longer than the short term. If you take the short term to be 10 minutes (the shortest term that the 128 bit security has to withstand an attack), then the "shortest" long term with 160 bits is 81715 years. If the short term is longer, this long term becomes even longer.
So there is no adequacy between both security levels. Or 128 bits is too short, or 160 bits is too long.
It is not dramatic. It works. It wastes space, that's all.
Reducing 160-bits by 16 bits only saves 10%, and for that miniscule size reduction you are not factoring the exponential loss in randomized collision resistance:
http://preshing.com/20110504/hash-collision-probabilities/Gotcha.
But a mathematical genius wouldn't make such errors, that's my point.
All the errors in analysis are yours. So now we know you are not a mathematical genius, but your own rule of exclusion.
Now, if there was a smart crypto analysis why this was nevertheless done this way, and not another way, that would maybe explain things. I've not seen Satoshi explain anything about this
Because you are supposed to think he was only a lone hobbyist in his garage. And you fell for it so gullible you are.
Satoshi was a smart guy, but he was by no means a mathematical genius, and he did quite some things a mathematical genius wouldn't be capable of thinking of.
That sentence is internally inconsistent.
If your view of the world needs that, and you have to resort to circular proofs of his genius, be my guest, I don't want to destroy your view of the world.
I'd be happy if you could prove he made a mistake. You haven't yet.
You are the one trapped in irrational subjectivity of what you want to believe. The detail of your analysis has been refuted above with even more detail that you apparently didn't think of.
And even I might be missing some of Satoshi's additional reasons. I seem to find more and more reasons to agree with his design as I go forward.
