Quote from: addrstore.com on June 20, 2017, 08:15:28 AM

The author, there is no need to go to the 256-bit address. 160 bits is enough to ensure the security of the address.

The problem is completely contrived.

In order to get a collision with a probability of 1.77636E-15 (and this probability is negligible, there is a higher chance of winning the lottery) there must be a blockchain in which 2 ^ 56 addresses will be used, each address being 20 bytes (160 bit). In total, the blockchain with such an amount of addresses will occupy not less than 2 ^ 56 * 20 = 1441151 TB (this is the lowest estimate), by the way, at the moment, the blockchain is only 126 GB.

Did you even think about reading the thread before wasting your time writing your post?

There is a bigger concern with 160 bit P2SH addresses than a collision with an address in the blockchain. The concern is that an attacker can create two separate addresses that BOTH DO NOT exist in the blockchain, but which collide with each other. With 160 bit addresses, there is a reasonably good chance that an attacker could do so within 2^80 attempts.

While 2^80 is a big number and probably more than you're going to do with your CPU today, it isn't big enough to be considered "secure".

As for the storage requirements:

Quote from: gmaxwell on May 03, 2017, 08:24:34 AM

- snip -
A cost optimized solver will make some time/memory tradeoff and usually end up using a couple times more computation . . . in exchange for little to no storage. (google floyds cycle finding algorithim)

And yes, thats the risk-- that your counterparties degree of freedom in choosing part of the contract will let them find an alternative contract with only collision like work, rather than with second-preimage like work.
- snip -