16 ms·
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 astronomicall
by theden 5y ago
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 futile, since no matter what you're basically rolling the die and hoping RNG lands on your side in your lifetime and your universe of all possible universes.
1. https://github.com/theden/btc-heist https://github.com/theden/btc-heist
2. https://bitkeys.work/download.php https://bitkeys.work/download.php has a weekly updated CSV of all known addresses with nonzero BTC balance
- saalweachter 5y agoHave you explored the space of "poorly generated keys"? I assume someone has screwed up their key generation at some point in a predictable way, and that's a much smaller space than every possible way.
- shim__ 5y agoThere used to be brain wallets which were private key derived from a password. A lot of those got brute forced back in the day
- faebi 5y agoI always wanted to make a lottery which randomly bruteforces against Satoshis initially mined coins. Therefore you won't harm a financial institution on the way to win.
- HPsquared 5y agoThat's what mining is too, basically. It's just that a mining rig can "buy a lot more tickets".
- theden 5y agoSolo mining yeah definitely, but with pool mining one can at least generate some fraction of a BTC.
- kosinus 5y agoMake me wonder, at what point does brute forcing private keys become more lucrative than mining?
- IronIvan 5y agohttps://odysee.com/@3Blue1Brown:b/how-secure-is-256-bit-security:f https://odysee.com/@3Blue1Brown:b/how-secure-is-256-bit-secu... or more briefly: never
- echelon 5y agoYou're assuming the crypto is flawless and forever hard, even with new computational paradigms. We've shown time and time again that our undefeatable algorithms aren't. Would you be comfortable if the Blockchain was frozen in time for a hundred years, after which you could withdrawal your balance? Would it be impervious over that time frame?
- temp0826 5y agoI mean...btc will eventually hit the supply limit. Sort of hilarious if all mining hardware was repurposed at that point to work on brute forcing instead
- tromp 5y agoTransaction fees will dominate the block subsidy long before that. Probably within the next 2 decades (in which the subsidy drops 32x).
- MereInterest 5y agoThe supply limit is irrelevant in this case. In order to remain secure, the cost to attack Bitcoin must be proportional to the value represented by Bitcoin. Currently, when proof of work is performed, it is funded in large part by increasing a ledger value without a corresponding decrease elsewhere (aka "minting"). In the future, when proof of work is performed, transaction fees will need to increase in order to provide a similar incentive. If the sum of the block reward and the transaction fees decreases, then that would result in fewer groups willing to perform proof of work calculations, and would be followed by a decrease in the proof of work difficulty in order to maintain ~1 block every ten minutes. That lowered difficulty then results in a lower cost to attack Bitcoin. So, there must always, always be profit in running proof of work calculations. Not only that, but to maintain the security of the ledger, any increase in Bitcoin valuation must result in a proportional increase in proof of work expenditure across the entire network. It's an absolute disaster of a system.
- mritchie712 5y agoLuabase has SQL access to this type of data. It’s in beta but email mike@luabase.com if you’d like to check it out.
- ssl232 5y agohttps://github.com/TheDen/btc-heist/blob/5cf0ef73857277f1321f06dafc5723b584ea087a/btc-heist.py#L43 https://github.com/TheDen/btc-heist/blob/5cf0ef73857277f1321... You don't need the f.close() here - the context manager does it for you.
- bspammer 5y agoThis is a rare care where "astronomically low" is actually underselling how unlikely something is.
- noasaservice 5y agoI've already ran across 4 (albeit drained) BTC addresses in the last 4 hours. Sooo... what's 4 astronomicals?
- flatline 5y agoEffectively zero is the term in probability: it will not happen, but is technically not impossible.
- s5300 5y agoI mean, I found 10 used wallets not within 1000 pages of the first nor last page of his website in roughly 5 minutes. I’m fully aware behind the math of finding a wallet actually holding anything… but I was fairly weirded out to come across 10 wallets that quickly. Most had their last txn out roughly 2019.
- teaearlgraycold 5y agoYou didn’t come upon those wallets by chance. Whatever rules the site uses to order wallets isn’t unique and some other (insecure) wallet generator uses the same technique. That or someone is actually using the site to come up with wallet keys.
- hjorthjort 5y agoI've noticed that there are a few hardcoded ones on the final page, where the account exists and the key is wrong. I'd say odds are that the website is wrong, but you can always load those keys in a wallet and see if they give you control over the actual address. If that works, I'd assume it's the case that some people have used weak keys (for example, a popular Ethereum wallet would actually generate 256 bits of entropy but accidentally truncate it to 32 bits in an operation), and any funds in those wallets will have been snagged long ago. Point being: generate a private key properly, and no one will ever find it. EDIT: I realize this is another page then the one I've seen previously, but I think the same idea applies. That one had support for Ethereum, too, and on the final page was an account with a balance.
- teekert 5y agoAnd then, when you "hit the jackpot", will you become a thief? Or will you just feel like you picked a lock, smile and pull the door back shut.
- alex77456 5y agoAverage wallet won't have much in it. On the other hand writing an article with a semi proof of this would affect the bitcoin economy, whether deservedly or not.
- Yizahi 5y agoAs they say "the unstoppable law of unbreakable code". You will become the "rightful" owner of those tokens, unless they happen to belong to one of the Not-The-Owners of that particular blockchain. If they are, they will just fork a blockchain removing your money from your wallet. Vitalik and Co already did this with Ethereum after TheDAO contract execution as designed, because their own funds were affected.
- henvic 5y agoWhy a thief? Bitcoin is a silly idea based on scarcity that doesn't exist. If someone generated the right numbers by chance and had luck, I wouldn't say they'd be doing anything wrong getting whatever is there. It's not the same as stealing data, and is not the same as hacking into a banking system. It's decentralized, and there isn't the concept of real scarcity. It's not even hacking. https://henvic.dev/posts/bitcoin/ https://henvic.dev/posts/bitcoin/
- 5y ago
- uniqueuid 5y agoIgnoring the prospects, this is a neat case to explain sharing memory in multiprocessing. You're reading the file in every process, this needs mem x N for N processes. If you first read in the file, create the set, and then use multiprocessing, you will get forked processes sharing the parent's memory, i.e. only need 1 x N the memory.
- theden 5y agoI haven't grokked shared memory in python yet to implement it (https://docs.python.org/3/library/multiprocessing.shared_memory.html https://docs.python.org/3/library/multiprocessing.shared_mem...). Apparently there is also a known bug? (https://stackoverflow.com/questions/14124588/shared-memory-in-multiprocessing https://stackoverflow.com/questions/14124588/shared-memory-i...), but an improvement I'd like to learn and implement. Though the file I have is just over 1GB, so it's not prohibitive yet. Funny thing is even though it's throwaway code, ensuring everything worked as expected felt really high-stake since a bug would mean a found key would be lost! Edit: Also not sure if shared memory would be slower in python3 (or if it was, whether it would matter in this use-case), but an interesting thing to profile.
- wyldfire 5y agomultiprocessing relies on the OS' fork() to share the memory transparently to the child(ren). The pages containing the memory will refer back to the same physical page until they're written to. This is what grandparent meant by "sharing memory". multiprocessing also provides a way to access the OS' explicit shared memory usually used as an IPC mechanism.
- uniqueuid 5y agoRight, thanks for clearing that up. multiprocessing's "shared memory" facility is for writable memory. What I described is extremely handy as you simply move the parsing code up in the script, before your function definition, and "magically" gain memory efficiency.
- bspammer 5y agoThat CSV is actually really interesting. The median wallet holds about $30, the largest holds $10b, and the standard deviation is over $2m. >>> import pandas as pd df = pd.read_csv("btc_balance_sorted.csv") df['balance'].apply(lambda x: x * 36902.7 / 100e6).describe() count 3.359206e+07 mean 1.838824e+04 std 2.819739e+06 min 3.690270e-04 25% 2.871768e+00 50% 2.943913e+01 75% 2.652168e+02 max 1.063263e+10
- tomputer 5y ago> That CSV is actually really interesting. The median wallet holds about $30, the largest holds $10b, and the standard deviation is over $2m. Top 100 Richest Bitcoin Addresses: https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html https://bitinfocharts.com/top-100-richest-bitcoin-addresses....
- rogue7 5y agoI agree with your comment, just FYI you could avoid apply on a pandas Series since it loops over every row in Python space. It's much faster to use vectorized operations directly e.g.: df["balance"].mul(36902.7).div(100e6) See [0] for explanations [0] https://stackoverflow.com/a/52674448 https://stackoverflow.com/a/52674448
- bspammer 5y agoThanks for the tip! You weren't kidding... %time df['balance'].apply(lambda x: x * 36902.7 / 100e6).describe() Wall time: 12.6 s %time df["balance"].mul(36902.7).div(100e6).describe() Wall time: 2.33 s
- headmelted 5y agoSort of. It's like being in the world's biggest ever lottery syndicate, except if you pick the winning numbers it gets sent to a specific other person who's website you're on. If someone, eventually, hits the jackpot then the owner of playxo.com is going to be very, very rich. I mean, I'd assume, cynically. The chances of anyone hitting a green wallet are still incredibly narrow, but you never know.
- vmception 5y agoIt get sent to your own private key which everyone else would also have trouble finding. Playxo.com wouldn't get anything out of it, anyone and everyone can have all the private keys of everyone else, playxo's operator or server wouldn't know which private key things are going to, and neither would any other human.
- stavros 5y agoPlayxo.com is showing you if a wallet has a balance. Before it ever shows you anything, it can clear that wallet, and that's that.
- 1phone1 5y ago[dead]
- vmception 5y agobut anyone can do that. you don't need an API to tell you if the address has a balance if you have the private key, you just check your own copy of the blockchain.... just like they are doing... fgsfds
- stavros 5y agoWhen you visit a page, they generate all the private keys on the page and check for balances. If you happen upon a key that actually has a balance, they will clean it out before you can.