. . . Start with a 256 bit counter, set to any number you like. On the secp256k1 curve, do an EC multiply of the value in the counter by the point at (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8). Now hash that result in RIPE-MD160. If you got 0x759d6677091e973b9e9d99f19c68fbf43e3f05f9 as the result, you found the pubkey for the bitcoin eater address. If not, increment the counter and try again . . .
I think you missed a step. After determining the public key from the private key, isn't the resulting
public key hashed using SHA-256, and then that result is hashed using RIPEMD-160 to generate the address?
So isn't this more accurate?
. . . Start with a 256 bit counter, set to any number you like. On the secp256k1 curve, do an EC multiply of the value in the counter by the point at (0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8). Now hash that result in SHA-256. Now hash that result in RIPE-MD160. If you got 0x759d6677091e973b9e9d99f19c68fbf43e3f05f9 as the result, you found the pubkey for the bitcoin eater address. If not, increment the counter and try again . . .
Oh, probably. I didn't check my notes on the process, I just happened to have the file with the curve constants open. It doesn't change anything fundamental either way. And no one is reading this thread for a tutorial on how to create addresses, they already know to look
elsewhere.
. . . figure we double the amount of work done in each year. That means one bit per year, which means 90 years between today and 2160 . . .
While you might be able to imagine that the speeds necessary to calculate hashes and/or perform EC multiplication might double each year, you'll eventually find that you run into a limit in the amount of energy required to change a binary state. When you multiply the minimum possible amount of energy required by the number of bits that have to have their state changed to perform the necessary calculations, you encounter a situation where you can't increase speed any further because all the available energy is used at the current speed. When that energy requirement is higher than the total energy output of the sun, you can feel pretty secure in saying that it won't be possible to calculate any faster.
For the next 50 or 100 years or whatever, the issue is going to be engineering more than physics.
The Schneier quote is
here if you want to read it. The problem really is in the 2
160. A Dyson sphere around the sun for a year is plenty to iterate 2
160, because 160 is puny compared to 256. In physics terms, I'm not sure how many operations are required for the other parts of finding an address. At the limits, the resources in our solar system appear to be capable of breaking 160 bit systems, but we are far,
far from approaching those limits. Maybe our grandchildren, or great-grandchildren will ask us some day if saving 16 bytes was worth it. But I'm not worried about it tonight.