| 1. | there's no point in making the hash bigger than 128 bits @dinofelis claims that since it is known that the true security of Bitcoins 256-bit ECDSA (elliptic curve digital signature algorithm, i.e. a form of ECC aka elliptic curve cryptography) is only 128-bits, then if we hash the ECDSA public key, then we only need a 128-bit hash. Thus he claims that Satoshi was wasteful and not genius. Although Satoshi's long-term priorities were not prioritized on not consuming too much block size given 1 MB was deemed more than sufficient for Bitcoin's planned future as block chain for the $billionaires only, Satoshi did minimize the length of the hash function by choosing 160-bit RIPE160 instead of SHA256 for the final hash of Bitcoin addresses (as they appear on the blockchain, but note that publicly distributed addresses also have a checksum for eliminating user typos but afaik this checksum is or could be discarded from what is stored on the blockchain). He did this minimization because it is good design sense, it is sufficient security and collision resistance, it provides an extra layer of protection against any unknown cryptanalysis interaction between SHA256 (or RIPE160) alone and ECDSA, and it helps to market the product to the n00bs as scalable (even though Satoshi was deception in this regard) in Bitcoin's nascent stage. Also SHA256 before RIPE160 provides an extra layer of protection against any unknown cryptanalysis breakage on collisions for RIPE160 alone. For example, SHA256 has a Merkle-Damgard length extension weakness when not doubled with itself or another hash, which tangentially btw would provide someone with a strong hint as to where to look for inventing the AsicBoost to make SHA256 mining 30% more efficient. 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. ... 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. Yet @dinofelis is incorrect to claim that 128-bits would have been sufficient for the hash function, because of at least two reasons:
Also the larger bit length of the hash may also provide competitive economic security compared with the block reward of using the SHA256 resources to mine the blockchain. And as I had pointed out upthread, the 160-bit reduces the collision attack space of the 256-bit ECDSA from 128 to 96 bits. | ||||
| 2. | @dinofelis claims that quantum computing resistance with the hash is futile because if the ECDSA is broken via Shor's algorithm, because he claims the attacker can crack the transaction signature and double-spend it when it is published before the bonafide signature becomes final in the blockchain. I already refuted this argument based on two reasons. 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 (nascent 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. So the day that one finds the "Euclidean division" in an ECC, it is COMPLETELY BROKEN. You are describing future cryptanalysis breakage of the math theoretic security of the intractability of the discrete logarithm over certain fields. But you're analogy does not apply, because Shor's algorithm (a form of cryptanalysis) is already known! It is not a future unknown. 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: You are uninformed. Crypt-analysis breaks on hash functions typically lower the security in bits, but don't lower it to 0 bits. 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. Thus... --> if we assume that ECC will be broken one day, bitcoin's crypto scheme is IN ANY CASE not usable. Not only are you failing to assimilate the fact that Shor's breakage is already known (not a future thing not knowable as you are arguing) which is sufficient slamdunk on why you are incorrect, but you are also claiming that hash functions can typically be entirely broken in one swoop which afaik not the case (and I studied the cryptanalysis history on past SHA submissions from round 1 to final rounds). Now, what is the reason we can allow LOWER security for the exposed public key, than for the long-term address in an output ? The reason is a priori (and I also fell into that trap - as I told you before, my reason for these discussions is only to improve my proper understanding and here it helped) that the public key needs only to secure the thing between broadcasting and inclusion in the chain. But as you point out, that can take longer if blocks are full than 10 minutes. This can be a matter of hours. Now, if we are on a security requirement of days or weeks, then there's essentially not much difference between days or weeks, and centuries. The factor between them is 10000 or so. That's 16 bits. A scheme that is secure for days or weeks, only needs 16 bits of extra security, to be secure for centuries ====> there is no reason to nitpick on 16 bits if we are talking about 128 bits or so. There is no reason to introduce "short term security" if this is only 16 bits less than the long term security level. You have incorrect conceptualization. The point of long-term security is not the difference in the time it takes to crack with a given level of technology, but rather that over the long-term we can't know when that moment comes that cracking has become sufficiently fast enough. The Bitcoin UTXO from 8 years ago that Satoshi has not spent, could have been under attack for the past 8 years. By having the hash for the long-term security, then we force all attacks to begin only when the UTXO are spent. This enables us to restrict damage to a very few number of transactions and the community will become alarmed and take corrective action. I already told you that if the public key were exposed for a longer (indefinite!) time, so you would need to increase the security of the public key. But to what level given quantum computing may be coming? And 256-bit was about the upper limit of what was available and well accepted in 2008. I remember seeing that 256-bit was only expected to be recommended security for ECC for only another decade or so. https://www.keylength.com/en/3/ https://www.keylength.com/en/compare/ ... Another reason (in addition to the compression of UTXO) to hash the values on the block chain is because when the use of a quantum computer is detected, we have some protection against chaos and can map out a strategy for burning the values to a new design securely. Hashes are much more likely to be quantum computing resistant. 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. |