Correct the intractable brute force collision attack is reduced to 2^160 bits.
That is the definition of the security level.
Quote
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.
Quote
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.
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.
Quote
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:
Quote
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.
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
Quote
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.
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.
Quote
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 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. 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
"Because Satoshi is a Genius, He cannot have made mistakes, and if people point out that he made some, they are wrong because Satoshi's genius cannot make mistakes. Given that everybody pointing out mistakes is hence wrong, this is the proof that Satoshi, is, after the fact, a genius." QED.
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.
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.
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.
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.
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.
2) overall 128 bit security. The hash is over-designed. --> failure
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.
==> 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.
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. But a mathematical genius wouldn't make such errors, that's my point. 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, apart from the silly argument against quantum computers breaking ECC, but limiting hash breaking to.... 80 bits effort
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. 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.