John Nash created bitcoin

[Duzter]

From the wiki and general articles related to bitcoin understood that more of the bitcoin legendary cryptograph developers claim themselves to be Satoshi.

[1713252015]

1713252015

[1713252015]

1713252015

[1713252015]

1713252015

[1713252015]

1713252015

[1713252015]

1713252015

[1713252015]

1713252015

[dinofelis]

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:

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.

[iamnotback]

Readers I am not admonishing @dinofelis. I respect him very much. Please read all the way to the end of this post.

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:

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.

Correct the intractable brute force collision attack is reduced to 2^160 bits.

And that is you're mistake. Shocked?   I had thought of that of course and was waiting for you to make this mistake.

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. Such as for distinguishers, boomerang attacks, etc.

I have studied hash functions and their cryptanalysis some, so I became aware of this.

  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.

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.

As I had originally pointed out you are conflating two entirely different systems of security and each can benefit orthogonally from increased bit lengths when we are not concerned about an intractable brute force enumeration attack and instead concerned with math theoretic cryptanalysis breakage.

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.

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.

You're thinking about it entirely incorrectly per my points above.

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.

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".

You presume we are simpletons, because you have made a Dunning-Kruger mistake.

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.

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.

[Dorky]

I am thoroughly convinced that iamnotback is a total moron.

[iamnotback]

I am thoroughly convinced that iamnotback is a total moron.

You are suffering from the Dunning-Kruger effect.

The Dunning–Kruger effect is a cognitive bias in which low-ability individuals suffer from illusory superiority, mistakenly assessing their ability as much higher than it really is. Psychologists David Dunning and Justin Kruger attributed this bias to a metacognitive incapacity, on the part of those with low ability, to recognize their ineptitude and evaluate their competence accurately.

Dunning and Kruger have postulated that the effect is the result of internal illusion in those of low ability and external misperception in those of high ability: "The miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others."

@dinofelis will acknowledge the correctness of my rebuttal, unless he is disingenuous. And I don't think he is.

@dinofelis's mistake was thinking that something that is intractable is worth worrying about. Cryptanalysis attempts to reduce the intractable bitlength security to a tractable attack. But I explained the staging of the SHA256 before the input of the RIPE160, in theory makes cryptanalysis attacks on the collision equivalent to attacking the 256-bitlength collision security of SHA256. Cryptanalysis attacks don't collapse to 160-bits. I possess more knowledge about hash function security than @dinofelis.

[Dorky]

Maybe iamnotback is not suffering from the same (Dunning-Kruger effect), that he is really superior and somewhat legendary.





You know, sometimes it can be fun "praising" the truly foolish, and watch in glee the fool nodding in agreement.

[iamnotback]

Maybe iamnotback is not suffering from the same (Dunning-Kruger effect), that he is really superior and somewhat legendary.

You know, sometimes it can be fun "praising" the truly foolish, and watch in glee the fool nodding in agreement.

Dorky keep digging more into your Dunning-Kruger facepalm.

There will plenty more coming for you because you seem to feel it is necessary to try to prove something against me.

Seriously dude, you are not competent. So much so, that you can't distinguish competence. Sorry if you are butthurt. I am simply stating facts.

The difference between the uninformed and the stupid, is the stupid insist even after they've been informed.

The best advice I can give you is to read more, and type much less.

[dinofelis]

Correct the intractable brute force collision attack is reduced to 2^160 bits.

That is the definition of the security level.

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.  

  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.  

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:

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  

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.

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.  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.  

[edden]

You speaking nonsense. Satoshi Nakamoto is not an apple that you pick from a basket full of developer. Satoshi Nakamoto is some body else. iamnotback You know that you are not Satoshi Nakamoto but you have got your moniker  from Satoshi Nakamoto. Satoshi will come back soon with a new moniker iamback but not adamback.  He will resurect the dead from the compartment and will empower the poor with more Bitcoins to establish social justice that's has been  hijacked by the alien hypocrites. John Nash even could not imagine about Bitcoin. The real architect of Bitcoin and Blockchain is not a dead man but an immortal.

[iamnotback]

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.

[iamnotback]

You speaking nonsense. Satoshi Nakamoto is not an apple that you pick from a basket full of developer. Satoshi Nakamoto is some body else. iamnotback You know that you are not Satoshi Nakamoto but you have got your moniker  from Satoshi Nakamoto. Satoshi will come back soon with a new moniker iamback but not adamback.  He will resurect the dead from the compartment and will empower the poor with more Bitcoins to establish social justice that's has been  hijacked by the alien hypocrites. John Nash even could not imagine about Bitcoin. The real architect of Bitcoin and Blockchain is not a dead man but an immortal.

Lol, I told my angel investor last month that the great thing about my username is it would make people think of adamback, but in reality the motivation of was Michael Jordan. And yes I used both @iamback and @iamnotback, but the former has a scrambled password and I can't access it. And also I think some users misread it as @iamnotbLack which I like so that it can cause SJWs to become hyperventilated.

[Dorky]

Dorky keep digging more into your Dunning-Kruger facepalm.

There will plenty more coming for you because you seem to feel it is necessary to try to prove something against me.

Seriously dude, you are not competent. So much so, that you can't distinguish competence. Sorry if you are butthurt. I am simply stating facts.

The difference between the uninformed and the stupid, is the stupid insist even after they've been informed.

The best advice I can give you is to read more, and type much less.

Well, it's not that I don't read more.
It's just that I am not interested in your subject of interest (who is satoshi nakamoto? john nash is!) and couldn't care less about it.

I can identify who (or what) is behind the force of bitcoin even without taking the path of understanding who is satoshi nakamoto.
So what if you have all the information that john nash could very likely be satoshi nakamoto?
The NSA already has a complete research paper on cryptocurrency way back in 1996, do you know that?
And back in 1988, The Economist magazine already touted a "phoenix" world currency.
What is most important is not whether john nash has a role in bitcoin.
What is most important is what's the intention of the shadow elite with bitcoin on us, how their plan will play out, and how it will affect our lives.
Your path of tracing bitcoin's root back to the shadow elite is just one way out of several.
And just because your way is through john nash does not mean your way is the only way or that other people's way is not.
If you think people will eventually know bitcoin was by the shadow elite thanks to your research, then I say you are very full of yourself.

Edit:
Besides, if you think bitcoin will be rejected in favor of one or some of the alts out there, that shows you don't understand the shadow elite well enough.
Yeah, I can see you are a thinker. No sarcasm here. But I believe you need to think even more.

[IadixDev]

In my analysis, there is definately contradictory aspect to bitcoins. When I do analysis, I try to grasp at person intention, what they spend time on, what they care about , and what are their motivation and state of mind.

Because you get on one side still a super smart concept, well polished, well thought, very deep etc.

And on the other side, the code who seem to be really rushed.


On one side something that definately involve Nash like math. I have read the last post of iamnotback im convinced Nash theories and bitcoin are connected.

But to write blockchain problem, mathematician would express as something like a set of nodes, and matrixes / tensors applied on them to get some kind of statistic informations or whatever.

It's generally easy to spot when code is made out of math theories, because the variables and functions and organized with mathematics thinking.

Here you get code who originally used openssl crypto, and most of the work on the code is glueing different part of framework together.

Basically, it's not math code.

It's not code made to be easily upgraded, or developped collaboratively GPL style.

When people want to launch gpl projects, they install bugzilla, and tracking tools, doxygen,  and lot of other things to manage collaborative developpement on large scale. No such thing with btc right.

More or less the base was laid once for all, from the first time, with method that remind completely of software industry, one whitepapper, one shot release made once for all, and not thought to be developped GPL style. Not too much documentation. Something targeted at end user more than to developpers.


And ive been tweaking with my share of blockchain code, on bitcore, monero and blackcoin, and they are incredibly hard to modify safely. There are threads everywhere, even you could say the whole thing would only make sense if someone wanted to make the threading such that it's very hard to change anything because  of all the different concurent access from different things.

it's so messed up you would almost think there is some game theory in it

But the whole way the code is produced really look like something out of a company or start up. Or from people who think in term of commercial software, not mathematician or gpl guys.

From the post attributed to him, you see he still had a plan in mind, but more something based on trading/gambling shared profits and personal profits rather than something really made out of mathematics theories.



If I had to make a bet, id say there was on one side some sort of think tank crunching on the concept of trustless security, decentralized currency, and distributed database is also huge interest for IT due to the economic impact, and adding some twist of crypto on top of distributed database is not necessarily super new either, there are things like hibernate who already deal with this sort of problem, and the infrastructure of blockchain is a distributed transactional database.

The part in itself with distributed database, and signed operation/transaction is not totally new.

But what is very smart with btc is that it's completely made to take in account interest game, speculation, reward, and is completely sound commercially.

It's clear to come up with something like this, need to have at least heard of the kind of math of Nash, and the problematics involved, with decentralized authority, conflict of interest, to get something that is successful and reliable.

But to me it seem it's more like someone like smart buisness man from IT world, from the world of startup and software companies, who would have been introduced to game theory, maybe in the context of gambling, or probability based games, but fundamentally someone from IT industry, and maybe he came into Nash throught online gambling industry.

[iamnotback]

Well, it's not that I don't read more.
It's just that I am not interested in your subject of interest (who is satoshi nakamoto? john nash is!) and couldn't care less about it.

Then don't comment. Or try to reason with me as you are doing now, instead of treating me like shit and mocking me as you were doing.

I can identify who (or what) is behind the force of bitcoin even without taking the path of understanding who is satoshi nakamoto.

And so did I, when I wrote Bitcoin : The Digital Kill Switch in March 2013, when I first joined this forum. I also published that at marketoracle as well.

So what if you have all the information that john nash could very likely be satoshi nakamoto?

Because it helps me (us) to understand what exactly their plans are for Bitcoin. Now I know they intend it to be a settlement layer.

The NSA already has a complete research paper on cryptocurrency way back in 1996, do you know that?

I've known about that since 2013.

And back in 1988, The Economist magazine already touted a "phoenix" world currency.

I've known about that since 2007. For example look at when I mentioned it in 2010.

What is most important is not whether john nash has a role in bitcoin.
What is most important is what's the intention of the shadow elite with bitcoin on us, how their plan will play out, and how it will affect our lives.

That is why understanding Nash's role (even if only symbolic) and his Ideal Money is so important.

Your path of tracing bitcoin's root back to the shadow elite is just one way out of several.
And just because your way is through john nash does not mean your way is the only way or that other people's way is not.

Did I ever say anyone else's research on connecting Bitcoin to the shadow elite was worthless?

If you think people will eventually know bitcoin was by the shadow elite thanks to your research, then I say you are very full of yourself.

You underestimate how many dozens if not 100s of people read my posts. Just because a few trolls like you think you are so important, there are more lurkers who at least are interested to read what I have to say. My technical skills are also legit.

Edit:
Besides, if you think bitcoin will be rejected in favor of one or some of the alts out there, that shows you don't understand the shadow elite well enough.
Yeah, I can see you are a thinker. No sarcasm here. But I believe you need to think even more.

I have secret weapons.

Besides the shadow elite are apt to love the altcoin I will launch, because they will see it as yet another speculation that falls under Bitcoin's umbrella.

[Dorky]

Here you get code who originally used openssl crypto, and most of the work on the code is glueing different part of framework together.

Maybe bitcoin was developed by separate groups of programmers working on specific functions before the pieces were assembled together into one.

[iamnotback]

Here you get code who originally used openssl crypto, and most of the work on the code is glueing different part of framework together.

Maybe bitcoin was developed by separate groups of programmers working on specific functions before the pieces were assembled together into one.

You obviously don't understand programming.

[Dorky]

Here you get code who originally used openssl crypto, and most of the work on the code is glueing different part of framework together.

Maybe bitcoin was developed by separate groups of programmers working on specific functions before the pieces were assembled together into one.

You obviously don't understand programming.

I studied programming (Python, C++, Java) on my own.

But of course I didn't check out that bitcoin source code.
What's the point since I am just a user?
And if the shadow elite is behind it, whatever their plan will still going to enrich me financially.
Settlement layer, currency, no problem.

[iamnotback]

Here you get code who originally used openssl crypto, and most of the work on the code is glueing different part of framework together.

Maybe bitcoin was developed by separate groups of programmers working on specific functions before the pieces were assembled together into one.

You obviously don't understand programming.

I studied programming (Python, C++, Java) on my own.

What I mean is you apparently have no experience creating a complex application. It can't be done by separate teams and produce a coherent result.

Mythical Man Month applies.

Programming is an activity that requires coherence of design, unless very well designed modular APIs have been designed between separate components.

People can collaborate on code via open source, but not separate teams isolated from each other.

[Dorky]

What I mean is you apparently have no experience creating a complex application. It can't be done by separate teams and produce a coherent result.

No, no experience in complex application.

I did programming for my futures trading program. And I learned enough for my own application.

[Dorky]

I have secret weapons.

Besides the shadow elite are apt to love the altcoin I will launch, because they will see it as yet another speculation that falls under Bitcoin's umbrella.

Oh, yeah? What secret sauce do you have?

I believe the shadow elite intends to make bitcoin lasts, and certainly will just treat the rest (altcoins) as either sandboxes for improvement on bitcoin or total pump and dumb scam.

Maybe next time you meet Andreas Antonopoulos, you can shoot him a question on bitcoin = rothschilds = phoenix currency and see his facial expression.