Quote from: iamnotback on April 10, 2017, 04:08:18 AM

Quote from: dinofelis on April 09, 2017, 12:06:10 PM

Satoshi's creation contains too many blunders (mathematical, cryptographic, economical, game-theoretical and programmatic) to be made by a genius like Nash.

I have refuted you in another thread. You had some really dumb errors in your analysis such as claiming that RIPE160 reducing security. No it only reduces the space of addresses increases potential collisions but only astronomically small probability yet saves a lot of scaling space.

Given that that thread is closed, I won't reply there of course. But your rebuttal is wrong, most probably because you didn't see the point I was making.

Here is your rebuttal:

Quote

Sorry but you are incorrect. Math theoretic bitlength security is not comparable to hash function bitlength security. Also RIPE160 comes after SHA256, thus you lose no security, only collisions. The hash only obscures the public key. Still need to provide the public key on spending, so 160-bit collision won't help you spend because hashing also with SHA256.

There are different forms of attack on a bitcoin UTXO, some more theoretical than others, but here it goes.

In order to spend an UTXO in an attack, you have to provide a digital signature and a public key that allows to verify that signature, in such a way that:
1) that signature corresponds to the transaction as verified with the given public key
2) the hash of that public key corresponds to the given address.

Of course, 1) is not difficult by itself: just any key pair (P,S) will allow you to use S to generate a valid signature, that can be verified by P. The hard part is 2), the fact that the public key has to hash to the given address.

Essentially, we need to find a P such that
1) P corresponds to an S that can generate a signature to be verified by P
2) P ultimately hashes to A, the address.

In this problem, A is the only given. ANY P that hashes to A and that has a corresponding S, will do.

The cryptographic assumptions are that we have an easy elliptic function ell(S) = P, and an easy hash function hash(P) = A. Note that the fact that hash() is a compound hash function of two standards, SHA-256 and RIPE160, doesn't matter in the theoretical description.

ell() is a 256 -> 256 bit function
hash is a 256 -> 160 bit function.

In the end, the only thing that we need, is to find an S, such that hash(ell(S)) = A.

As hash o ell = full is a 256 -> 160 bit function, to brute-force this, your security is essentially 160 bit. After on average 2^160 trials, you will have found an S. 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. Only one of those is the true owner's key pair, but the whole point is that that doesn't matter. The transaction can be satisfied by 2^96 different key pairs, because the only thing that is needed for such a key pair, is for its public key to be hashed to the address.

So the effective security of bitcoin's signature scheme, is 160 bit on the condition that all cryptography is perfectly safe. There's no point in going to 256 bit for the key pair, because 96 bits of that are lost, given that 2^96 key pairs hash to the same address, and are interchangeable.

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. I'm even not sure that you really maintain the 128 bit security if 2^96 key pairs are possible, even though for most general attacks I know about, you need to know the explicit public key and not just a hash test of it.

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.

The error you (and probably Satoshi) make is to think that because at a certain point we have 256 bits, that this level of security is "locked in". 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. That is, an idiot programmed a log-in system such that, for reasons of security, your password is hashed with a 20-bit output hash, and only this hash is stored. (that's like bitcoin's address). Now, to log on, you provide your password, the hash is calculated, and if it fits with the 20-bit hash, you are allowed to log on. You remember that one should use long pass phrases. So you type a sentence of 60 characters, nobody can guess. You think that you have ~300 bit security if we take 5 bits of entropy on average for a typed character. However, the hash of that long phrase is only 20 bit.
If I want to brute-force your log on, I only need to try about a million passwords. I will NOT guess your password. I don't need to. I will find a password (a different one) that will hash to the same hash as yours. And I will be able to log on.

By limiting the hash of the public key to 160 bits, Satoshi has limited the security of that key to 160 bits in any case. Providing 256 bits is not meaningful, not any more than your long pass phrase was meaningful security. You could have taken a password of only 4 characters, you would have had about the same security. Satoshi could have taken a public key of 160 bits, that would have given the same security ; apart from the small time lapse between rendering the key public (broadcasting the transaction) and its inclusion in the chain.
And one would have saved 96 bits per input on each transaction.

What is even more, if for one or other reason, Satoshi was of the opinion that the key needed its security by itself, then it is even stranger to have a key with 128 bit security, and an address with 160 bits of security. If Satoshi considered 128 bits sufficiently secure, there was no reason to keep 160 bits of the hash in the address. 128 bits on the address would have been good enough.

In other words, the word length choices make not much sense, security wise.

A) Satoshi wanted 160 bits of security only for addresses --> a 160 bit (80 bit security) elliptic curve signature would have been good enough, and 96 bits of saved room per input

B) Satoshi wanted 128 bits of key security overall, also with public key --> the 160 bit hash of the address is too long, he could have won 32 bits per output with addresses of only 128 bits

C) Satoshi wanted 160 bits of key security overall -> his 256 bit elliptic curve signature is not good enough, it has only 128 bits of security, and maybe even less.

==> clumsy crypto.