Some random thoughts about this business of 'hacking bitcoin', when I say that remember that the same is also done with Ethereum, and all the other cryptos, BITCOIN is most interesting to researchers, because it has the MOST data, for instance the first 3.5 MILLION block of ethereum were pre-mined to the same 'group' ( person ), I mean what's the point of studying ETH? Later post 5M it gets interesting, but below 4M nada, ... but BITCOIN is fascinating the entire block-chain, ...
***
IMHO, having done this stuff for a solid six months after a double hiatus from bitcoin in 2011, and 2013, I have seen very little to nothing come of these types of 'looking for private keys', just hashes in generals that they them selves came from hashes is just shit from shit, you still get shit, a lucky monkey on a type writer can also generate 'war and peace', given enough time.
There are 10k ways to HACK bitcoin, there are a zillion paths to be taken, one must test them all to find that path that works for them, certainly you don't want to follow the 'pack' in this shit, as it will lead you to NO WHERE.
Probably best advice for people serious about this game is ...
1.) Study the C++ code for bitcoin, as none of the docs are real, its all bullshit, only the code is real2.) roll you own, write your own parsers ( block chain to text, its probably best to do CSV), most of the database programs can-not handle 200GB very well; probably best c/c++ & python; I prefer csv-text, but all the real work is done with bloom-filters so that no text is actually ran during during production
3.) have many databases that are selective for each mission, one for addresses, one for balances ( short life ), one for public-keys, ... but all the databases have bloom-filters, so you don't need to query a slow server during production, for instance a bloom filter indexed by 'address' but the bit signals value is far faster way to determine whether its useful to analyze and address
4.) Have many bloom-filters for all of the above, searching for the monkey means O(1) search time, you can NOT have just a bloom for address, you need blooms for your rain-bow tables, for your private-key warehouses, for your public-keys, for your ecdsa integer farming, X-Y pairs, R's&S's, k's, ...
5.) getting back 2, none of the code on github works, I mean NONE, its not maintained, and it will all lead you to dead ends, if a guy actually wrote a 'bot' that harvested valuable addresses and swept those accounts he would NOT give that software away for free, 99% of the shit you find on GITHUB is somebody's dead-end,
6.) study all the papers on the subject, there are 1,000's of well written technical papers on ECDSA SECP256, read them all, write your own sig ecdsa software write your own hash library, vector everything, always place vector check points every few 100 steps so you know everything is working.
7.) there are 1,000's of variables, and it only takes one to generate false-positives, know at all times that all your inputs are correct,
8.) have a bell or timer set to generate music ( make a sound, don't sit and watch the monitor ), I have a A-G guitar chord set, so depending up what my bots find, they play the different chord sets so that I know the nature of the problem, and the chord set doesn't nauseate people around the house
9.) I find that hacking BTC is harder than mining ( writing your own mining sw ), but far more interesting, 'mining' is a toy problem, while the 'discrete log' problem may win you a fields medal, big difference between 'hacking' and mining.
10.) Don't be a fool, if you don't have years of experience in programming, cryptography, database, networking, math, physics, then your chance of making any kind of interesting discovery is nil ( or for finding high-val address for that matter, when I say 'find', I mean getting the private-master-key ); Lots of smart people working on this "Discrete Log Problem" for a long time, if it were an easy problem, then it would have been solved, I think some 50 years since computers have been generally available people have been trying to solve this problem by brute-force
11.) like I said there are 10k ways to hack btc, there is the address angle ( have bloom filter for a addresses with value ), the public-key angle, the random priv-key angle, ... the ecdsa pool angle, ... you need to really play around with all until you find a method that works for you, then dive deep and really understand why your succeeding, don't try to do them all, there is too much, just doing the ECDSA can be a full time job for a mathematician
...
Most of this stuff is done for intellectual curiosity IMHO its to much work for the 'get rich quick moron' which are the majority of this board ( over at 'bitcoin talk', I know here at dev is the real geniasses
),
its far easier to clone your own coin, start your own mining pool, or exchange, or write 'wallets with backdoors' and rip people off if your goal is to 'steal', most of us when we do find coin, are more than happy to make note of the find to the owner.
It's a vast multi-disciplinary field 'hacking btc', I can see it become a major career path, there are already dozens of masters thesis written on this subject, bound to be many phd's born of this stuff
For the young kid, I can offer no better path than BUTERIN did, first study the BTC source (C++), and master that, then write your own btc client/server in python, and completely understand all, then modify your source so it can output 'data' as you want, ... Most of the 'action' is happening now, most of the easy stuff that is talked about in papers or this forum is what happened in 2014 or earlier, ... unless you write your own client/server that is tuned to study the now, your not going to make 'great' discovery's.
Passive Analysis is still wide open, very little work has been done on the block-chain using machine learning or digital signal processing techniques, but then again like the stock-market, what bitcon did in the past in terms of private-key generation means nothing tomorrow, as the core-devs are constantly hacking the code, and fixing the 'holes', thus to find the new holes, you must stay one step ahead of the core-devs,
