Topic: Obsolete gtx1060-3gb GPUS can find valuable BTC keys 250 MH/Sec, 1000TH (Read 1043 times)

It's just JLPs original VanitySearch; I tweaked the text and math to show what it's actually doing.

Going to try to tweak code to include prebuilt h160s inside the program versus reading an input file.  And then figure out a way where the GPU doesn't lose speed.

You got a windows version of it?

Just tinkering around with small changes to original VanitySearch, here are some numbers:


So with 5 cards and 39 million addresses (with no bloom filter yet), I am getting almost 62 Petahashes per second.

Program is using right at 6.5GB RAM, constant, so here is my question to @btc-room101, with your configuration, how much constant RAM is used?

GPUs obviously lost speed with that many addresses.  If I only wanted a constant set number of addresses (not update and sync with chain), what would be the easiest most efficient way to set it up with bloom filter?

Nevermind, I didn't realize txindex was a setting that needed to be enabled.  Like you said, stop thinking and start tinkering 

I am getting the following error when running all-blocks.  Any idea might be causing this? 

I get that, but if I read what you said correctly, the super computer is only needed once, to generate the bloom filter.  After that the mining rigs can run the new-block script.  Is that correct?  My thinking was to use AWS to generate the initial 8 GB bloom file, download it, then have a mining rig and bitcoind/electrum server locally.  and then like you said, the mining rig updates the bloom filter every 12 hours

U really need to quit thinking, and start tinkering.

There are two things here like all this crap. U need a super computer, thread-ripper, 32+gb ram, and lots of NVME's to make your bloom filters and collect your bitcoin addresses and fill your bloom filters.

Then you need mining rigs, one card or a set, that had at least 8gb; The bloom-filter on the mining rigs is kept in an NVME drive, but it gets updated every 12 hours, I keep a task that harvests new bitcoin addresses from the mempool, and then every 12 hours add'd them to the bloom filter, now you could do that on the mother system that made the initial bloom filter, but I find it better to ...

1.) Have one old system that runs bitcoin-core, and electrum-server that hands off bitcoin-addresses from the pool. The electrum server is to add found priv-keys to the wallets on each mining rig. The 'loop2.sh' mining script, has a section where any found bitcoin's are swept into the wallet. Note there are also binchk routines that kick out false-positives from the bloom filter. ( Make sure your old computer has a SSD +1TB for the bitcoin blockchain, otherwise the RPC will be too slow for the mining rigs to harvest addresses&priv-keys)

2.) A super computer to make the bloom-filters and manage the source code (C++/python), I define a super-computer as +32gb RAM, +12 core ripper; +2  NVME 4x16 (128gb ok for bloom, but 1TB for processes )


3.) Mining rigs i3s' 4core  are ok, +8gb, while the process 'mining' only uses 900mb on gpu&cpu, when you update the bloom-filter ( which why I only do every 12 hours ), because the code uses share-memory, then the cpu needs 8gb, so 12gb would be best on each miner. ( every 12 hours, because the 300k new address add  to the bloom-filter, takes about 30min on the mining rig, and during that time the process speed drops from 400MH/sec to 60mh/sec, so I don't want to do it too often ).

4.) For 'testing' you could just have any old gpu card on the 'super-computer' for validation.

The 'new-block' routine as of right now my way, is to run it on each miner, I tried before running it on the bitcoin-core server, but what happens is the bitcoin&electrum servers ground to a halt, during the bloom-filter update ( which requires +8gb RAM, so the system becomes cache  locked ); The thing is I don't want my bitcoin&electrum servers to ever stop, otherwise the entire system fails. ( The mining machines are running new-block, they're expecting a good RPC connection ), the mining routine is also expecting a good electrum-rpc to sweep priv-keys.

So now I have 'new-block', which for those who haven't READ, its a batch-file that calls python to collect all the new addresses from mining-pool every 15min(new block sleep); About 4,000-12,000 new addresses; they're concatentated and 'sorted uniq', of which I see about 10% reduction, so most are new addresses and no-duplicated.

Adding 300,000 new addresses to the bloom-filter on the 'super-computer' ( 32gb, 24core ) is a 5 minute task, but on a mining-rig it can take an hour, which is why I do it on the rigs, if you do it on the bitcoin-core server, then all the RPC calls halt and the entire system suspends.

Probably the best way would be to have the super computer update the bloom-filter every 15 minutes, and then it transfer by "SSH-COPY" the new bloom to the NVME's on all the miners. But I don't do this now, because I used to do it years ago, and now my super-computer has been re-tasked to more interesting projects.

So in summary, normal mining rig with 1+ gpus runnning the miner processing the bloom-filter, on a gtx-1060-3gb I'm now seeing about 400MH/Sec on one card, it was 250MH tops before, the new speedup came from adding more memory to the mining-rig ( asus-370p) was 4gb, now 8gb, I think 12gb would be ultimate. This memory above 1GB is only used during the 'bloom-filter update process', called "hex2blf8 new-address.hex monster8.blf"

...

I don't see how reading can help,  there are 12 components, each must be played with and learned both reading the source, and studying IN&OUT mappings, getting the entire system running, requires that all components are working. The problem is most stuff like 'brain-flayer' which is just one engine with cmd-line switches can be understood by reading the 'readme', but here its 12 engine components that must all be working 100% and communicating.

NOTHING is CPU intensive, all computation is done on the GPU's in the mining phase.
creating 8gb bloom filters and updating them requires +8gb RAM, and multi-core cpus

Again, unless you actually stop reading, and start running these tasks,your not going to 'get it', I would suggest one system to begin with, with 32GB of RAM, and lots of NVME drives on pcie-4x12 slots; U also of course need to have another machine running as bitcoin-core full-node txindex, and the electrum server, this machine is non-cpu, and 4gb of ram is fine, just don't have anything else running your bitcoin/electrum server.

...


In summary, in a perfect environment for a professional dedicated to this task. I would have three computers, and thread-ripper with tons of memory to update and create BLF(bloom filter), an old 4gb 6core amd for running bitcoin&electrum server, note be sure to use 1GB LAN to communicate all computers. Then the miners would need just a standard gpu mining MOBO with 4core intel(i3 ok), and +8gb would be ideal for ram, note that each mining rig needs 1 NVME 4x16 pcie near the cpu, at least 128gb, as it only contains this ONE BLF, nothing else, getting high speeds only works if the NVME is only used for this one task of sharing the bloom filter with gpu boards mining/hacking btc.


Right now 'my way' is to use old-computers and un-used mining rigs that I have set aside, the mining rig fetches addresses&and sweep priv-keys from the bitcoin/electrum server. The only thing I have to check is the electrum client to see what the system has found.

Remember I have already worked +5 years on this project, I'm moving on; so my allotment of resources is what works for me, for somebody just starting out, I would do most stuff on the super-computer, because its fast; These days I use all my super-computers for ECDLP math problems,

F*CK AWS, do you realize it would be $5 to download the blf file every 15minutes, are you going to have a full-node of bitcoin&electrum server also running on the AWS? So now your paying AWS what $14,500/month  ( just for file downloads), then another $1k/month for super-computer server on AWS, for something you can do on old free computers from the junk store? R U serious, that nobody actually does anything anymore at home?

I've been reading this for a few hours tonight.  Quick question, and this is probably stupid, but once the bloom-filter is created, is the new-block routine high cpu and storage intensive?  Reading over the requirements of creating the 8 GB bloom-filter to begin with, I am wondering if this is something I can generate in AWS and then download and host locally.

Right.  I wasn't saying your method was exactly like that, but there seem to be people in this thread who think the idea is completely implausible.  I just wanted to show that this is a legitimate concept

I will have to disagree with you. Bitcrack and VanSearch both can search for multiple addresses at one time, both compressed and uncompressed. They both take the given address input file and store their applicable Hash160s; and then for every private key visited, it checks the hash160 for all inputted addresses.  I can run VanSearch with 20+ million addresses loaded, checking both uncompressed and compressed at the same time, for every address in input file, but I lose overall MKey/s speed. I liked your bloom filter to SSD idea because, according to you, the GPU takes no hit on speed.

Kangaroo can search for multiple pubkeys, you have to tweak the program.  I don't understand what you mean by "a space of 2^40" because I can find a key in the 2^80 range in 2 to 3 minutes using Kangaroo.  2^40 range takes less than a second, but do does using a brute force program.

I hope to get caught up on reading and implementing your bloom filter idea soon.

have you hacked this address from 2011?
310 btc have been hacked
almost 10 years abandoned

https://bitinfocharts.com/bitcoin/address/1BkVazubQAtVfbsnJwArjV3qvRNEiZqTWx


you can follow up here
the pirate sent btc to multiple addresses
and from those directions to other directions many times to try to lose track

https://www.blockchain.com/btc/address/1BkVazubQAtVfbsnJwArjV3qvRNEiZqTWx

NOT TRUE, bitcrack, and kangaroo search for ONE address ( private key pair ) at a time, here using the 8gb bloom filter, all 300MILLION BTC addresses are scanned on each cycle at 250MH/sec, so 250MH * 300M is 1,000TH equivalent of the other methods.

Nobody is doing this anywhere, the bitcrack method is 1 in 10e77 odd's of hitting a private-key match



This method is down to 1 in 10E18, if you apply a mining rig then you can find btc addresses in days, solo 1060-3 is weeks

If you run this method on racks of RTX-3070's can you can find btc priv-key pairs all day long.

...

SO bitcrack just randomly (guesses) a private-key, and then looks to see if it hit the address your looking for, your odds are the same as finding a lost electron in the known universe.

Pollard-Kangaroo requires that you estimate  the correct key with a space of 2^40, in essence you must already known some 80% of the private keys leading digits, otherwise it is useless, again it can only search for one private-key pair address at a time.

Amen to this.  Not sure why there is so much hate for btc-room's posts.  Clearly they are more technical and over a lot of peoples' heads, yet many people love to argue.  None of these concepts are new, this isn't an invention of his imagination.  For people who are interested in learning, stuff similar to this has been discussed for years:  https://youtu.be/foil0hzl4Pg

https://github.com/brichard19/BitCrack
https://github.com/Telariust/pollard-kangaroo

And for anyone who doubts what he says, here is a 67 page post on bitcointalk:  https://bitcointalksearch.org/topic/bitcrack-a-tool-for-brute-forcing-private-keys-4453897   Maybe go take out your aggression on these guys too.

You guys should stop whining, and start listening to him, his work is fine, and he is to,
start learning to program, or start providing answers, and stop banning him, and deleting his thread like that,
nough said

Well that would be your circle-jerk invention ( perpetuum mobile jerking contraption ), lots of people are working on ECDLP, 1,000's of paper per year published. Math&Crypto PHD's.

                                                  ---------------------------------------------------
Two things left. This -------------------------------------------------^
And perpetuum mobile.

Typically there are 16 tests, whether its a 512mb bloom or a 128gb bloom, so the speed would be the same.
The larger bloom just means a larger canvas, so when you throw the dart ( your guess ), its better to hit white-space, than a dot indicating a mark,

The combinatorial nature of blooms is that the number of tests is a quality factor. The thing is once you get above 4gb, then you have a chunk problem as linux memory only support 32bit address chunks, typically with bloom the 256 number or private-key would be four 64 bit address into the bloom, which is normalized with remainder function ; Each of the 4  has its own permutation as the 64bit can be rotated 64 times, so you could in fact have 4 * 64, or 256 tests, but 16 is fine, here of the four sections, just creating  4x deterministic markers in the bloom. For a 8 gb I just do 2+2 using the lower 1/2 of the 256 bit entry for the low/high halves, you could do the same for a 32gb bloom

With only 300M bitcoin addresses I have that the 8gb is fine.

I find that for most people the problem here is approaching the data management problem, of creating the 300M h160 hex addresses, so they have data to operate on, first they need to have a bitcoin-coin full node with tx, up & running, they need to install the python rpc routines, and run the component source, but  most people can't even find the on/off switch on their computer, let alone running the full node.

Impossible to provide data as github limits 100MB for a project. The total data I use is about 10TB for hacking-btc, but given that CHIA mining needs 500TB, then 10TB today sounds like baby data.

Then of course once you have 300MB you have to sort and make the addresses 'unique' in order to build binary sort engines 'xxd', the bloom filter only can ascertain 1 in a trillion-trillion, but to know absolute you need to do a binary search with minimal computation you can't use 'grep' for looking up an address. But sorting a 300M file is a major task on a PC, you need fast cpu, and large RAM

Once you have the data, and have created the .bin files & .blf files, you can run the miner, the .blf get you that 1 in 10E24, but for a yes/no you need the .bin ( xxd );

I used to just ring a bell everytime an address was found that had btc, as I have enlarged the bloom-filters beyond 16gb, and extended the blockchain database scraping to all btc addresses every used, I  find very little noise, so now can just have the few addresses found just 'sweep' the key with electrum-server. But most of the time its just dust, which is to be expected.

I think this approach, will be most useful once the ETH people repurpose away from ETH mining, to btc hacking, as a rack of rtx-3070's can do an enormous amount of hash like 2,000MH/s * 300M, which is 600,000TH/s, times 6 rig, 3.6 EH/s, 3.6 million TH; Somebody with a room of gpu rigs, could really clear  out bitcoin;

I'm still just running gtx-1060-3gb at 250MH/s * 300M, which is 75,000TH/s, still better than running a btc miner at 80th

I suspect that once a few people take this approach, there will be a massive loss of trust in bitcoin and the dev will finally get of their arse and make it stronger, but perhaps not, perhaps like ostriche they'll just stay in denial, and watch everything just dissapear.

...

I do have rtx-3070's but I use them for ETH, I don't want to push the btc, thing IMHO if I push this I don't want to be the one setting on tons of 'lost btc', just brings the wrong kind of attention, I'm done, it was always a proof of concept endeavor, I proved it, it works, time to move on. The only thing left is fine-tuning the automated addition of new addresses to the bloom-filter ( that code is on the github ), and automatically  sweeping 'found' addresses with electrum server. I did find that it didn't like 100K private-keys getting swept, so I have backed off to just one key at a time through rpc calls, but just for fun I wanted to know how it would handle 100K private-key, and it didn't like it.

Like I said, years ago I would just ring a 'bell' when a hot-address(key-pair) was found, but now I can't be bothered, so I just let the stuff run 24/7 & and auto-sweep, and really don't pay much attention to it all. Once your running full rigs on this stuff, you need to be more involved because your generating 100X or more data and getting lots of positives, as I don't really care about find btc in the first place this has all become rather boring.

Like i have said, the only thing left to do is derive private-keys straight from public-keys, but that involves a lot more work, and strategy; It's more of a puzzle problem, while the bloom-filter gpu, is just rolling the dice a trillion-trillion times a second & looking for wins. While the ECDLP is more elegant & about math.

Did you even go to the github site, the sources are there, I posted last week, about 15 components to the entire system. Is this what you do is post crap, without even having gone to the site to study and/or test the code ( 100% open python & c++ )

I normally don't respond to morons, but I felt that some of the handicapped have special needs

https://github.com/room101-dev/Grand-Ultimate-BTC-Hacker/tree/master

All the code is there, but idiots & morons can do nothing with code, as it takes real systems knowledge to even approach this material.

All his post are FUD with no sources like always, dont know how he keep ranting about btc, just posting jibberish and not backing anyword, as you said i dont know how this guy can keep posting even  when they ban you for less..

Well 1GB will let you check 30-50M high-value btc addresses. Original brainflayer was 512MB, 15M addresses.

The speed is the same, the checks are both exactly the same, all that can be said is that one there are different RAM in-memory requirements.

The 8gb is to do all 300M known btc addresses, all at once.

Study the source code for the bloom-filters  (hex2blf) its in the .H files, its just static serial compares, in both cases the run-time test count is the same, so there is little delay difference, given its all in memory that is all equal as well.