Bitcoin address exhaustion

[JoelKatz]

Long before this kind of attack would be possible, much simpler attacks would appear in the literature. For example, until the first RIPEMD-160 collision appears, there is really no point in worrying about this attack. Creating a RIPEMD-160 collision with control over both inputs is so much easier than this attack and nobody has even done that yet.

For this attack, you actually don't even have control over *either* input. Even if you found a public key that produced that necessary RIPEMD-160 hash to claim someone else's coins, you still wouldn't have the corresponding private key, which you'd need to produce the signature.

To summarize:

1) Find a RIPEMD-160 collision with full control over both inputs.
2) Find a RIPEMD-160 collision with full control over one input.
3) Find a RIPEMD-160 collisions with limited control over one input.

None of these are possible yet, 3 is needed to make this attack work, and 3 is much harder than 2 which is much harder than 1.

And the fix would simply be to switch from RIPEMD-160 to SHA-256. The protocol already supports that. It would just make our bitcoin addresses longer.

[netrin]

As long as http://blockexplorer.com/q/decimaltarget divided by the number of addresses with a balance is greater than one, it will be more profitable to generate a block than attack the key space.

17248274092338559882155796390905381469049315669915374897.332224 > 1

[Rob P.]

As long as http://blockexplorer.com/q/decimaltarget divided by the number of addresses with a balance is greater than one, it will be more profitable to generate a block than attack the key space.

17248274092338559882155796390905381469049315669915374897.332224 > 1

That's our point.