??
I hate making excuses but just when I was ready to work on VS project files for my fork today I learned that my Windows box is being serviced for the next few hours. So looks like a no-go for now.
Wow! Amazing I like know more and I have equally successfully developed a tool to help you recover your btc funds be it lost or stolen in any way and also help you transform non spendable funds into Spendable and many other interesting features. Checkout https://www. no bestbitcoinprivatekeyrecovery backlinks .org
Your contains tidbits like this on the front page:
Quote
Bitcoin dust attack is performed by sending $1 to any wallet you wanna sweep away it entire funds. A dust doesn’t requires a specific coin state,a dust is send to non-spendable funds as-well as confirmed or unconfirmed bitcoins.
Quote
private key is an encrypted alphanumeric code that permits access to your bitcoin or cryptocurrency holdings. It is the only true way of proving that you are the owner.
Eh?
This looks more like a phishing attempt than a real cracker.Brainflayer needed to use this because the 512mb bloom-filter they use, only allowed about 10M addresses before false-positive went astro, with the binchk you can take the false positives and very if any of them are real postive.
I'm trying to find relation between the bloom filter size and max number of addresses for a tolerable FP rate because being able to use more than 512MB memory would be handy.
Real problem here is setting up the bloom-filter, orginal model in brainflayer was 512MB, which only allows about 15M addresses, before false-positive goes astro. Solution is to cascade 4gb junks in series, as most shared memory models only allow 4gb chunks, 3 years ago using open-gl I had the bloom filters on the GPU ( gtx-1070 ), but you can only have 2gb chunks, and its actually faster to do blocks of 2048 private-keys, and then have each gpu core pass them back to threads all running cpu cores on the shared bloom-filter. With 300M valid btc addresses, you really need a 32gb bloom filter. None of this stuff is online, you must roll your own.
Yeah, when you're working in parallel with multiple GPUs each device memory is separated from each other and so you have to split the bloom filter accordingly, so you don't offload that part of the code to CPU. And then compressing the R160 hashes down to binary dramatically speeds up the initialization time by avoiding reading several dozen GB and is what makes large bloom filters practical in the first place.
We can actually reserve most of the memory for the bloom filters, and the array of addresses themselves can be placed in host memory because finding a match doesn't happen very often, it's only be used for output and logging anyway.