Live data from Hacker News

All Bitcoin private keys are on this website

playxo.com

71–80 of 398 posts

Re: All Bitcoin private keys are on this website

#71
post #48
post #35

Earlier quoted context omitted.

You could check a lot more than 1B address per second.

Not easily, as you need to do an elliptic curve point x scalar multiplication, which takes tons of cycles on a CPU and even tons of gates on an ASIC. Please provide a link to hardware that can do it much faster...

I'd guess a GPU at 2Ghz (2. Billion per second) might run parallel enough to compensate for the number of cycles required for a given point.

I doubt whether this would get far past 1 billion a second though.

Re: All Bitcoin private keys are on this website

#72
post #26

It's like passively playing the world's worst lottery in terms of odds, but hundreds of thousands of times every second. It's fun but the odds are astronomically low. I have a script[1] that generates a pub+private key and checks against a massive file of addresses with BTC[2]. The list of addresses is loaded in memory as a python `set` so checking is O(1), but I feel like optimisations at increasing the rate are fut…

https://github.com/TheDen/btc-heist/blob/5cf0ef73857277f1321...

You don't need the f.close() here - the context manager does it for you.

Re: All Bitcoin private keys are on this website

#74

Earlier quoted context omitted.

If I had some coins on my machine and the fees were low enough I'd be tempted to put a few bucks on a new key and test this theory.

How will you test the theory? It would be easy to just not sweep small amounts. Then when someone checks a wallet with a large amount, joink!

what would be the incentive for trying a second time with another wallet?

Re: All Bitcoin private keys are on this website

#77

> Finding an active wallet is hard, but not impossible. Every time you open a random page, you have a chance of finding someone else's fortune. Good to know I have a 1/2^256 chance to find a bitcoin billionaire's wallet. This feels only slightly more ludicrous than the guy who lost his bitcoin in a hard drive and went looking for it in a dumpster.

It is not 1/2^256. It is "number of wallets with balance"/2^256.

Re: All Bitcoin private keys are on this website

#78
post #26

It's like passively playing the world's worst lottery in terms of odds, but hundreds of thousands of times every second. It's fun but the odds are astronomically low. I have a script[1] that generates a pub+private key and checks against a massive file of addresses with BTC[2]. The list of addresses is loaded in memory as a python `set` so checking is O(1), but I feel like optimisations at increasing the rate are fut…

This is a rare care where "astronomically low" is actually underselling how unlikely something is.

Re: All Bitcoin private keys are on this website

#79

Earlier quoted context omitted.

... not even close. 2^256 is a very large number. If you could build a computer that required a single atom, and could test the balance of a single account in a single nanosecond, and then converted the entirety of the earth into such computers, it would take ~2.8 million years for you to check 0.01% of all accounts. Brute-forcing modern cryptography isn't something that can happen. The magnitude of 2^256 is close to…

This reminds me of a discussion a few years ago where someone was extremely adamant that you'd have to handle the chance of a key collision in a random 256-bit key for the system to be secure :)

I might agree with them because your random process could be weaker than you think without having any indication until you hit the colision.

Anything past detection and panicking might be overkill tho.

Re: All Bitcoin private keys are on this website

#80
post #72
post #26

It's like passively playing the world's worst lottery in terms of odds, but hundreds of thousands of times every second. It's fun but the odds are astronomically low. I have a script[1] that generates a pub+private key and checks against a massive file of addresses with BTC[2]. The list of addresses is loaded in memory as a python `set` so checking is O(1), but I feel like optimisations at increasing the rate are fut…

https://github.com/TheDen/btc-heist/blob/5cf0ef73857277f1321... You don't need the f.close() here - the context manager does it for you.

Thanks, fixed
Post reply on HN