Obsolete gtx1060-3gb GPUS can find valuable BTC keys 250 MH/Sec, 1000TH

[varfast]

All talk and no examples of anything, getting tired of all this theory talk.

There are dozens of steps & modules in this process, its like cooking gourmet meal for a 1,000 people

Your the type of person that wants a GUI, and his hand held going to the bathroom.

All my stuff is cmd-line, like any hacking of cryptography its a long and tedious process, I have no intention of automating and black boxxing for morons.

I will provide components and explain in detail how to use each component, but I will only do this with people who are not morons.

Obviously, if you ain't already got a MS in physics or math, and ain't a python/c++ guru, and if you ain't got 10+ years experience in LINUX, no source on earth is going to help you, nobody helped me get this stuff going I did it on my own, and if smart people want to take this to the next step, that's good with me.

If you didn't spend 20+ years as a sw developer doing networking, os, graphics, device-drivers, .. then you aint' going to get any of this ever.

What moron 'talk' the entire thing is to teach people to think the right way about hacking bitcoin. GARWIN had a great quote "The hardest thing about dropping a-bomb was that once it was dropped they couldn't deny it existed", same here once everybody know's how easy it is to hack bitcoin, then the mythology is game-over.



Garwin was the presidents advisor on atomic physics for 50+ years, he's probably dead now.

Theory is way more interesting to me than 'code', you say your tired of 'thinking' you must be a first class un-educated fool. Why are you even posting? Don't you have a computer game to play?

Dude you are a scammer, and your programs have malware in it. Those little projects that you just uploaded that probably don't even work cause you was trying to sell those same ones over a year ago. Now they are free, I wonder why.....still talk that same gibberish theory with those crappy programs you got and I don't remember trying to use your programs because you was trying to sell them. Now all of a sudden uploading them for free. Keep talking crazy, your account will be gone. You the one brought up the word moron, I could go on and on about you.

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..

[1715590641]

1715590641

[1715590641]

1715590641

[1715590641]

1715590641

[1715590641]

1715590641

[1715590641]

1715590641

[btc-room101]

All talk and no examples of anything, getting tired of all this theory talk.

There are dozens of steps & modules in this process, its like cooking gourmet meal for a 1,000 people

Your the type of person that wants a GUI, and his hand held going to the bathroom.

All my stuff is cmd-line, like any hacking of cryptography its a long and tedious process, I have no intention of automating and black boxxing for morons.

I will provide components and explain in detail how to use each component, but I will only do this with people who are not morons.

Obviously, if you ain't already got a MS in physics or math, and ain't a python/c++ guru, and if you ain't got 10+ years experience in LINUX, no source on earth is going to help you, nobody helped me get this stuff going I did it on my own, and if smart people want to take this to the next step, that's good with me.

If you didn't spend 20+ years as a sw developer doing networking, os, graphics, device-drivers, .. then you aint' going to get any of this ever.

What moron 'talk' the entire thing is to teach people to think the right way about hacking bitcoin. GARWIN had a great quote "The hardest thing about dropping a-bomb was that once it was dropped they couldn't deny it existed", same here once everybody know's how easy it is to hack bitcoin, then the mythology is game-over.



Garwin was the presidents advisor on atomic physics for 50+ years, he's probably dead now.

Theory is way more interesting to me than 'code', you say your tired of 'thinking' you must be a first class un-educated fool. Why are you even posting? Don't you have a computer game to play?

Dude you are a scammer, and your programs have malware in it. Those little projects that you just uploaded that probably don't even work cause you was trying to sell those same ones over a year ago. Now they are free, I wonder why.....still talk that same gibberish theory with those crappy programs you got and I don't remember trying to use your programs because you was trying to sell them. Now all of a sudden uploading them for free. Keep talking crazy, your account will be gone. You the one brought up the word moron, I could go on and on about you.

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..

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.

[btc-room101]

Thanks for the response.  

Curiosity question; do you notice a speed difference if you have say a 1Gb bloom versus the full 8Gb bloom you are running? Or is it the same speed no matter how large/how many h160s the bloom contains?

I will try and start small; create a smaller bloom first (30M h160s), run it, see if I notice a speed increase and make sure I understand/get the process right.

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.

[chup]

Like i have said, the only thing left to do is derive private-keys straight from public-keys, ....

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

[btc-room101]

Like i have said, the only thing left to do is derive private-keys straight from public-keys, ....

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

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.

[dextronomous]

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

[nsummy]

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

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://bitcointalk.org/index.php?topic=4453897.0   Maybe go take out your aggression on these guys too.

[btc-room101]

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

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://bitcointalk.org/index.php?topic=4453897.0   Maybe go take out your aggression on these guys too.

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.

[arranka]

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

[WanderingPhilospher]

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.

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.

[nsummy]

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

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://bitcointalk.org/index.php?topic=4453897.0   Maybe go take out your aggression on these guys too.

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.

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

[nsummy]

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.

[btc-room101]

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.

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?

[nsummy]

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.

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 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

[nsummy]

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

Code:

ubuntu@ip-172-31-44-174:/data/all-blocks$ python3 all-blocks.py
getblockcount =  686852
height =  686841
Traceback (most recent call last):
  File "all-blocks.py", line 176, in <module>
    al=addrlistVout( txid )
  File "all-blocks.py", line 113, in addrlistVout
    raw = rpc_connection.getrawtransaction(txid)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/bitcoinrpc/authproxy.py", line 141, in __call__
    raise JSONRPCException(response['error'])
bitcoinrpc.authproxy.JSONRPCException: -5: No such mempool transaction. Use -txindex or provide a block hash to enable blockchain transaction queries. Use gettransaction for wallet transactions.

[nsummy]

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

Code:

ubuntu@ip-172-31-44-174:/data/all-blocks$ python3 all-blocks.py
getblockcount =  686852
height =  686841
Traceback (most recent call last):
  File "all-blocks.py", line 176, in <module>
    al=addrlistVout( txid )
  File "all-blocks.py", line 113, in addrlistVout
    raw = rpc_connection.getrawtransaction(txid)
  File "/home/ubuntu/.local/lib/python3.8/site-packages/bitcoinrpc/authproxy.py", line 141, in __call__
    raise JSONRPCException(response['error'])
bitcoinrpc.authproxy.JSONRPCException: -5: No such mempool transaction. Use -txindex or provide a block hash to enable blockchain transaction queries. Use gettransaction for wallet transactions.

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

[WanderingPhilospher]

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

Code:

[ Combination Speed 61864.26 TH/s ][Combinations Checked 2^66.29] [Found 0]

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?

[bigvito19]

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

Code:

[ Combination Speed 61864.26 TH/s ][Combinations Checked 2^66.29] [Found 0]

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?

You got a windows version of it?

[WanderingPhilospher]

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

Code:

[ Combination Speed 61864.26 TH/s ][Combinations Checked 2^66.29] [Found 0]

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?

You got a windows version of it?

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.