This is the newer 64 Bit Pool Project. We are running the same pool but we have changed the mode, client program, and cracking program.

A continuation of:  https://bitcointalk.org/index.php?topic=5356170.0

Second version of 64 Bit Random Pool

Live User Stats:  http://bitcoinchallenge.site/64-bit-user-stats/

Ok, as said, we will be redoing the way the 64-bit random pool is done.

We started out with 2^19 subranges and that was too many or just not enough participants, which the latter is/was expected.

For this round and beyond, the range will again be divided up, this time into 2^17 ranges, so each subrange will be 2^46 in size. Subranges will be assigned randomly. GPU threads will spread out inside each subrange in 2^46/2^15 smaller subranges and check 2^32 keys. Once all ranges have been checked (should be a lot quicker this time around, to get through each range), I will add 20000 (in hex) to the beginning range and subtract 20000 (in hex) from the end of the last range, and we will run the next round. So, this way, each round we will check 2^48 keys but spread out over the entire range versus checking every key in every range like TD’s pool.

Here is example of one of my tests, to ensure no overlap. this is the beginning range:

8000000000000000:87ffffffffffffff

8000000000008000:8800000000006fff

8000000000010000:880000000000dfff

See how it's incremented? (Note, this was a test on larger subranges so I could get through them quicker, the pool subranges will be much smaller, but this should give you an idea on the increments between rounds)

So we are still checking “random” keys in each subrange, but each round will be sequential in nature. Example: If you get assigned range 8000000000000000:87ffffffffffffff Instead of running and checking every key in the range, your GPU threads will spread out every 2^46/2^15 subranges.

Thread 1 will start at key: 8000000000000000 And will sequentially check the first: 131,072 keys (8000000000000000 thru 8000000000020000)

Thread 2 will start at key: 80000FFFFFFFFFFF And will sequentially check the first: 131,072 keys (80000fffffffffff thru 800010000001ffff)

The last thread will start at key: 87FFEFFFFFFF8001 And will sequentially check the first: 131,072 keys (87FFEFFFFFFF8001 thru 87fff00000018001)

After all ranges have been ran (if key hasn't been found), we will reset the starting point by adding 20000 to the original starting range of 8000000000000000, which our new starting range will now be 8000000000020000

By doing it this way, hopefully we catch the key in a smaller subrange and soon. If we do not, we will eventually because eventually we will have checked every key in the 64-bit range.

If you are connected and running a client, eventually you will see a message on your screen that says:

[INFO UPDATE] Range Sent

[INFO UPDATE] Resetting Ranges

[MAIN] Resetting...

[INFO UPDATE] Resetting Ranges.

That is by design so do not turn off your machine. That lets us know we are done with the current round, and we need to adjust for the next range. Once I adjust the ranges and restart the server, your GPU will pick back up where it left off and keep working through ranges.

Excluding myself with multiple GPUs, we normally had 3-5 additional users connected and running in the pool. With 8-10 cards running, we should get through each round quickly, which was the original intent. I alone will have at least 4 cards running at a time, at all times.

We will be using a different client and cracking program this time around as well. The client has to be new/reconfigured because of the different cracking program. The program will work with all recent cards, GTX 10xx, GTX16xx, RTX 20xx and 30xx cards. The new client program also allows multiple cards on one rig to run without bottlenecking the CPU. With the old program, my rig started bottlenecking the CPU with 4-5 cards running.

How do you join and get started?

Download the 2 files from here:

https://github.com/WanderingPhilosopher/64-Bit-Random-Pool-2/releases/tag/v2.0    or

discord channel: https://discord.com/channels/871109371805962240/889292084190777394 .

SHA256 Checksum for KHClientV2.exe =

Code:

426aaef8ba24e59b64292ba124d66acc0a8f8cca5befccfa5cd72355417fa611

SHA256 Checksum for KHV2.exe =

Code:

44c199504de22e526ff3bd72aaa68c8a1920484bf9b0712bdb1098a775461ef8

(Verify by opening cmd, change directory to where files are located, and run CertUtil -hashfile KHClient.exe SHA256 and CertUtil -hashfile KH32.exe SHA256

Place them in the same folder. Create a batch file EXACTLY like this:

KHClientV2.exe -d 0 -name username

If you have multiple GPUs on a single PC/rig, use the -d flag to signify which GPU to use. -d 0 for GPU 0, -d 1 for GPU 1, etc.

Replace the -name username with your actual username, such as for me, -name wanderph ; I wanted to be able to use a BTC address but the database is case insensitive and at this time, that won't work But please only use one username whether you have 1 GPU or 1,000 GPUs. Keep the username the same. Example if using two GPUs: GPU 0 = Client.exe -d 0 -name wanderph GPU 1 = Client.exe -d 1 -name wanderph

If you have multiple GPUs, it is better to run each one on a separate/different instance versus running them together. If you have 2 GPUs, let them run the program seperately, it helps the pool check each range quicker and gives you credit for 2 ranges versus 1 range.

The username is how the program tracks how many ranges you have been assigned and completed. This is IMPORTANT because this is how we know who to pay and how much to pay them. Users will be paid based on their work. Your total ranges checked divided by total ranges checked equals your payout. Example: You checked 125,000 ranges and it took us 1,000,000 ranges checked to find the key then your amount would be 125,000 divided by 1,000,000 = .125 percent of ranges checked. Now multiply that by the amount of BTC we will find, .60 so your BTC payout would be .125 multiplied by .60 = .075 BTC.

Wait, what? .60 ?? I thought it was for .64 BTC? I am glad you are paying attention! .04 will go to the user who finds the private key. Yes, the program allows me to see who actually found the key. So overall, the pool will split, based on amount of work each user does, .60 BTC and the private key finder will get .04, in addition to their equal share. So if user is owed .055 BTC based on their work, and they find the key, they will get .055 + .04 = .095 BTC. So make sure you run your GPUs as often as you can.

While we are searching for the key, you can message me your BTC address so I will have a record of it when we do find the key! Once we find the key, I will message everyone who participated and sent me their BTC address to verify the address is correct.

We have the same pool running, but with a new client and cracking program.

Come see the new thread:  https://bitcointalk.org/index.php?topic=5361022.msg57985360#msg57985360




A new project to test bitcoin's key security attacking the BTC challenge. You can read more about the challenge here:
https://bitcointalk.org/index.php?topic=5218972.0

This project is considered a proof of concept, and we are testing the concept now.

Information links:
Discord server
https://discord.gg/5CyApZHgUu
Discord channel
https://discord.com/channels/871109371805962240/879196557067558913
Github
https://github.com/WanderingPhilosopher/64-Bit-Random-Pool

We are also working on a website to show live, real-time stats (in works now).

We have created a random searching pool in search of the #64 BTC challenge...in search of .64 bitcoin.

How is this pool different than TDs 64 bit pool?
TD has a great pool. The entire 64 bit range is broken up into 2^27 ranges, each range is 2^36 bits in size.
Users help search and complete each range in its entirety. Meaning once connect to the pool and run your rig,
you have to search a complete 2^36 bit sized range. The idea is a 100% key by key search. Hopefully the key
is found before reaching the 50% mark.

This pool is different. I have broken the entire 64 bit range into 2^44 ranges. Larger ranges than the above,
but we will NOT be searching every key sequentially. Once connected to the pool, you will be assigned a range.
Your GPU will generate random points throughout the range and then start searching for the private key in that
range. Once started, your GPU will check x amount of keys or run for x amount of time. I have it currently set
up that the maximum amount of time a single GPU will be in a range is 30 seconds. So your GPU gets assigned a range,
jumps in the range and generates random starting points, starts searching, runs for x amount of keys or 30 seconds,
whichever happens sooner. This way we are going in and out of ranges and at least searching in every possible range
within a limited time frame.

Depending on how many people/GPUs join the pool, we will search in every possible range in x days.
Example:
if we have 100 GPUs running 24/7
each GPU would check 2,880 ranges a day [1,440 minutes in a day, 2 ranges per minute (1 range every
30 seconds)]
2^19 ranges divided by 288,000 (100 GPUs x 2,880 ranges per day) = 1.82 days
every 1.82 days we will have searched every possible range
if we have 200 GPUs running 24/7 = every .91 day we will have searched every possible range

Example of ranges:
8000000000000000
80000FFFFFFFFFFF

8000100000000000
80001FFFFFFFFFFF

8000200000000000
80002FFFFFFFFFFF

all the way to

FFFFF00000000000
FFFFFFFFFFFFFFFF

How can you join?

Download the 2 files (discord channel) or at https://github.com/WanderingPhilosopher/64-Bit-Random-Pool/releases .
Place them in the same folder.
Create a batch file such as:

Client.exe -d 0 -name username

If you have multiple GPUs on a single PC/rig, use the -d flag to signify which GPU to use. -d 0 for GPU 0, -d 1 for GPU 1, etc.

Replace the -name username with your actual username, such as for me, -name wanderph
I wanted to be able to use a BTC address but the database is case insensitive and at this time, that won't work
But please only use one username whether you have 1 GPU or 1,000 GPUs. Keep the username the same.
Example if using two GPUs:
GPU 0 = Client.exe -d 0 -name wanderph
GPU 1 = Client.exe -d 1 -name wanderph

If you have multiple GPUs, it is better to run each one on a separate/different instance versus running them together. If you
have 2 GPUs, let them run the program separately, it helps the pool check each range quicker and gives you credit for 2 ranges
versus 1 range.

The username is how the program tracks how many ranges you have been assigned and completed. This is IMPORTANT because this is
how we know who to pay and how much to pay them.
Users will be paid based on their work. Your total ranges checked divided by total ranges checked equals your payout.
Example:
You checked 125,000 ranges and it took us 1,000,000 ranges checked to find the key then your amount would be
125,000 divided by 1,000,000 = .125 percent of ranges checked. Now multiply that by the amount of BTC we will find, .60
so your BTC payout would be .125 multiplied by .60 = .075 BTC.

Wait, what? .60 ?? I thought it was for .64 BTC? I am glad you are paying attention! .04 will go to the user who
finds the private key. Yes, the program allows me to see who actually found the key. So overall, the pool will split, based on
amount of work each user does, .60 BTC and the private key finder will get .04, in addition to their equal share. So if user
is owed .055 BTC based on their work, and they find the key, they will get .055 + .04 = .095 BTC. So make sure you run your
GPUs as often as you can.

While we are searching for the key, you can message me your BTC address so I will have a record of it when we do find the key!
Once we find the key, I will message everyone who participated and sent me their BTC address to verify the address is correct.

And that's pretty much it. The who why when what.

The idea is if we visit every range every 1-2 days, the odds of us finding the key will be increased versus searching every range,
key by key. TDs pool has been operational for some time, and it's like any type of pool, it depends on how much hashing power
is pointed at it that determines progress. That pool has 134,217,728 ranges to search through and they are a little over 10% completed.
Where as this pool will be in the actual range the private key lies in, every x amount of days, depending on hashing power pointed at
the pool.

For now, this is just open to Windows users with Nvidia GPUs. Once I can figure out/precompile for Linux users, I will post.

I am sure I will add to or edit this as things change.

I have ran 2 days of tests with the server and client program without a hitch, but that was with limited GPUs running. So if
some glitch does occur, bare with me and I'll get it fixed.

Kudos go to:
Jean Luc Pons and Telariust for original and modded Vanity Search.
I modded their work to create random points in specific ranges, each and every time.
Etar / Etayson for the client and server program groundwork.
I made a few tweaks to his program but really great work by him!
@dlystyr for his python experience and ability to write a python script in 3 seconds.
Also for his "ear", to listen to some of my crazier ideas regarding this BTC challenge.
@yoyodapro for his motivation and for setting up the discord channel to bring us all together.
And helping me test, work out any bugs.
and @bigvito for hitting me up every few weeks to work on the random feature until I finally
said dang, alright lol! But I got the idea while building him out a random version.

Stay tuned to the channel/here for important updates and stats.

This project will help us determine how random range and points compares to range by range sequential key searches and will give us data to use
in moving forward to keys #66, 67, 68, etc.

WP

Anyone know the huge differences (30,00 foot view)?  I haven't looked at Chia in depth but see that is seems similar to what Burstcoin used to be, i.e. using storage space, plotting drives, etc.

Ok, I am running a GMiner versus T-rex miner. Version 2.0.
I am running the latest releases of each miner.

@Didz ran a test and you can see the results here:

https://bitcointalk.org/index.php?topic=5345767.0

I think he did a good job and his post was insightful. There were some different suggestions in some of the comments so I decided to implement a few of those.

So here are the test parameters:

2 x RTX 3070s running on GMiner
2 X RTX 3070s running on T-rex

All 4 cards are the same exact brand/make/model
All cards have same settings
All cards are running on the same rig, so every card has the same CPU, RAM, PSU, etc.
Only difference is they are on different PCIE slots (obviously)
All cards are running on a real-time, mining eth pool

Why only 4 cards? I wanted the test to be fair and run simultaneously, in the same pool, on the exact same cards. I didn't want different times or network hash
or network difficulty to skew the data.
These 4 cards are the only ones I have that are the exact same brand/make/model.


I did read the test that 2 miners did; found here:

https://2miners.com/blog/best-ethereum-mining-software-for-nvidia-and-amd/

From what I gather, they set up a test pool with low difficulty to run their tests. Which is fine, it does show data/results.

But I am not interested in what the miners show as hash rate, nor am I interested in what the pool shows as the hash rate.
And I am not interested in how many shares each miner submitted because, as we know, each share is weighted differently. A share
of 100 G outweighs a share of 10 G.
But what I am interested in, is the bottom line, how much eth/money did the miners mine!

So the test is running live now. I don't know how long I will let the miners run, but for awhile.
Right now GMiner is running GPUs 0 and 1 and T-rex is running GPUs 3 and 4.
I do plan on switching the miners GPUs up ever so many hours so each miner mined with same cards and PCIE slots.
EDIT: swapping every 6 hours

Comments and suggestions on anything to change with the tests are welcomed.

You can watch/check in on the test in real time (both with the undercover aliases as 007s):

GMiner stats:

https://eth.2miners.com/account/0x00718dd53e4d73fc0fa3ed7935c887a62d7f84ed

T-rex stats:

https://eth.2miners.com/account/0x007231da7f49a3fed2100e6e743f06be45fcec89

Just for your knowledge/awareness; each miner is showing all cards running at 58 MH/s; so each miner is showing total hash rate of 116 MH/s.
You can use that when you look at what the pool is showing the hash rate of each miner at. But again, show me the money!

I'll keep track of how many total shares each miner submitted to the pool, just for those who are curious. But (last time), show me the money,
that's what I am more interested in!

Am I in the right topic area? Hello, is this thing on?

Below is the story of how I got here, typing this out. Could I solo mine a coin, all on my local area network, using an old PC as the server. Can I compete with
mining pools on newer faster equipment and servers spread out all over the world?

After the story I will post a link to the block explorer with my address so you can see if I actually find some blocks!

Ok, so I had a few hard drives crash recently (bad sectors) but I was able to pull some files and folders off of one. On there was a wallet for Ether-1 (now called ETHOS.)
I used to mine it off and on two years ago. Throw some hash at it here and there, nothing crazy. But it's a smaller alt coin so there was never a lot of
network hash rate and the diff was fairly low so you could pull some blocks with minimal effort...like in the 500 Mh/s range. So I brought the coin up
to honestly see if it was still around/being mined. It is. It's up like 1000% from when I use to mine it. So I said what the hey, let's throw some small
hash at it again. Never know when it may hit a dollar or two down the road. So I pointed a few GPUs at some pools and let them dawgs eat. I tried a few PPS
pools and some solo pools. Some were actually decent. Quick pay out time, decent block per pool hash to network hash ratio, etc. But some of the pools are
sheeeeeyat. I think I am still waiting on payments from a few of them lol!

So that leads up to one of my many tinkering projects (yes, I am a tinkering shade tree wandering philosopher.) And thus, here we are.

I thought to myself, I said hey WP (that's what I call myself when I think to myself), what if you grab one of those old PCs you paid $50 for and
see if we can set up our own pool of sorts. Mine the blocks straight off the chain and not worry about pools, are they going to pay out, will
they black-out/go off line (yes, two went off line for hours, hell I'm not even sure if they are back online yet.)

So again, here we are.

So I picked out an old PC that had a decent amount of hard drive loaded in it. Brought it into my tinkering area and gave it a bath...it was pretty dusty.
Whilst opening her up and making sure the wires were decent and nothing looked out of place, I decided to call her Eleanor Ethos Server, because that is what
she is now...my test server...to stick it to the pools who put a bad taste in my mouth. 

Here are Eleanor's specs:

Processor Intel(R) Xeon(R) CPU X5670  @ 2.93GHz, 2933 Mhz, 6 Core(s), 6 Logical Processor(s)
Installed Physical Memory (RAM)   8.00 GB
Total Physical Memory 8.00 GB
Available Physical Memory 3.76 GB
DDR3...back in the day it was fast!!

yada yada yada. She may not be the prettiest or the fastest and flashiest, but I think she will work just fine.

Oh, she also has a 250GB and a 1TB hard drive loaded in her.  Model is a Dell T3500.  Operating system is Windows 10.

So, I fired that puppy up and let her start to warm up and EAT! Well, it had been a long while since she was turned on, so she and Mr. Gates had to
become acquainted again...holy smoly, 6 hours of updates later...she was ready.

So, I remembered a guide years back how to set up a mining pool. So I did some googlin, and found one on Geth's info page.
(This guide got me about 90% there, and had to wing the other 10%)

First things first, download/install Ubuntu 18.04 LTS as subsytem on Windows system. Check
Create sudo, create another user, start downloading packages. Check
I thought about creating a pool while I was at it but Go isn't supported on Ubuntu under Windows.
Now the fun part, syncing the chain, which actually wasn't bad.
Now I am typing this up, while waiting on Eleanor and Geth to finish their business.
Ok, only 3 years of light data and stuff so it only took about 3 hours for full sync.

Time to generate my address, tell Geth to let me mine, and fire up some GPUs. Going to max it out around 500 Mh/s to see what happens.
Now I'm thinking can I compete going solo? Maybe find more blocks then I was on the pools because every thing will be within feet of each other.
The server and GPUs, sitting right next to each other.  Should be fun.

Current chain info:
Network Difficulty: 228.668 G
Network Hash Rate: 17.59 GH
Blockchain Height: 7,384,396

Ok, so I'll be competing with 17 GH/s. Eleanor says no worries. You built me, the blocks will come.

Alright, here is the address that I will be using to solo mine:
0x9697872A2a0e73C22028708f32F12537Ac8f1E9e

and here is the block explorer link to follow progress, see how long it takes to find a block:

https://explorer.ethoprotocol.com/address/0x9697872A2a0e73C22028708f32F12537Ac8f1E9e/transactions

Ok, about to fire it up. Wish us luck!

Is there a known working option out there (not using any of the commercial OS mining software) where one can set up a local stratum or port on one PC to control which pools all mining rigs are mining on?

Think of it like Nicehash but on a local network.

Example:

Main PC/Server runs local stratum or port for all mining rigs to connect to, ex:
127.0.01.123:8888

This main PC will have different pools loaded where it will send all mining rig hashrate to.

Mining rigs will connect to main PC/server. Example batch script:

miner.exe --server 127.0.01.123:8888

Like I said, like Nicehash but on local network.  When one connects to Nicehash they use a command like this:
--server daggerhashimoto.usa-east.nicehash.com:3353 -u btcwalletaddress.workername

and when people buy hash, Nicehash tells connected mining rigs/workers to go to some pool.

So is there a way to do this on a local network.  One PC controls the pool that all miners go to and the main PC can switch pools on the fly and for algos like ethash, the dag doesn't have to be recreated, the rigs just switch to the new pool.

Anyone interested in a "Lost" Bitcoin Collider Pool?

A pool where people could throw some hashing power at it when they aren't using their CPU/GPU to try and find what is considered lost bitcoin.

The pool would not be for trying to find every wallet/address with a balance, just the coins that are deemed lost.

So question one, what would you say would be the requirements/consideration of "lost" bitcoin?

Question two, would anyone have the know how of how to put a pool together, programming wise?

I would host the server and pay for the startup of it, and the upkeep.  I just don't have that kind of brain muscle...I am a tinkerer, shade tree, but I
know nothing of servers and making a program communicate.

I guess the pool would be like a mining pool, people get a percent of any lost bitcoin based on ranges searched or some hash rate. But either way, there
would have to be checks/verification to ensure people aren't sending fake hash/ranges searched.

Think of it as a better upgrade, with different twists and methods compared to the LBC. I see interest in the LBC (what got me to think of this today), but it
seems "dead" or barely limping along.  From what I've read, the program your CPU/GPU uses to search with isn't the best. 
Ideally, the new pool would have different search programs that people could choose to use; think Bitcrack (mods), VanitySearch (mods), archaic python scripts, etc.

I have ideas on how it could work but first want to see if there is any interest AND if anyone would have an inkling on how to set up the "mining" pool. If so,
we could brainstorm as it progresses.  If not, no biggie.

Ideas, suggestions, comments?

UPDATE 2: Newest version, VBCr 2.0 has been released. Now works with full address and/or prefix/strings.

It has been tested on Windows 10 and Windows 11 on RTX 30xx cards, RTX 20xx cards and a GTX 1660 Ti card.

Link:
https://github.com/WanderingPhilosopher/VanBitCrackenRandom2

SHA256 Checksum:

Code:

5415d56416632faa7058e1ddf2a6cde037d6df22778606128369df4557627dc3

Flags:

Code:

printf("VBCr [-check] [-v] [-u] [-b] [-c] [-gpu] [-stop] [-i inputfile]\n");
printf("             [-gpuId gpuId1[,gpuId2,...]] [-g g1x,g1y,[,g2x,g2y,...]]\n");
printf("             [-o outputfile] [-m maxFound] [-ps seed] [-s seed] [-t nbThread]\n");
printf("             [-bits bitsNumber] [-begr BeginRange] [-endr EndRange] [-dis Display Private Key] [-drk Display random keys] \n");
printf("             [-nosse] [-r rekey] [-check] [-kp] [-sp startPubKey] [-rp privkey partialkeyfile] [prefix]\n\n");
printf(" prefix: prefix to search (Can contain wildcard '?' or '*')\n");
printf(" -v: Print version\n");
printf(" -u: Search uncompressed addresses\n");
printf(" -b: Search both uncompressed or compressed addresses\n");
printf(" -c: Case unsensitive search\n");
printf(" -gpu: Enable gpu calculation\n");
printf(" -stop: Stop when all prefixes are found\n");
printf(" -i inputfile: Get list of prefixes to search from specified file\n");
printf(" -o outputfile: Output results to the specified file; Default is KeysFound.txt\n");
printf(" -gpu gpuId1,gpuId2,...: List of GPU(s) to use, default is 0\n");
printf(" -g g1x,g1y,g2x,g2y, ...: Specify GPU(s) kernel gridsize, default is 8*(MP number),128\n");
printf(" -m: Specify maximun number of prefixes found by each kernel call\n");
printf(" -s seed: Specify a seed for the base key, default is random\n");
printf(" -ps seed: Specify a seed concatened with a crypto secure random seed\n");
printf(" -t threadNumber: Specify number of CPU thread(s). Default is number of core(s)\n");
printf(" -bits bitsNumber: Specify bit length for private key. Default is 0 bits. -bits overrides -begr/-endr. \n");
printf(" -begr Begin Range: Specify Beginning Range in which you want to search, ex: 30000000000000000. Must use with -endr\n");
printf(" -endr End Range: Specify End of Range in which you want to search, ex: 3FFFFFFFFFFFFFFFF. Must use with -begr\n");
printf(" NOTE: when using -beginr and -endr, the program generates random keys in between those ranges. It will not\n");
printf("       search sequentially such as start at begr and stop at endr. Random keys in between the 2 ranges ONLY.\n");
printf(" -dis Display Private Key info on screen: 0 = off, 1 = on. Default is 0 / off.\n");
printf(" -drk Display random keys: 0 = off, 1 = on. Default is 0 / off.\n");
printf(" -nosse: Disable SSE hash function\n");
printf(" -l: List cuda enabled devices\n");
printf(" -check: Check CPU and GPU kernel vs CPU\n");
printf(" -cp privKey: Compute public key (privKey in hex hormat)\n");
printf(" -ca pubKey: Compute address (pubKey in hex hormat)\n");
printf(" -kp: Generate key pair\n");
printf(" -rp privkey partialkeyfile: Reconstruct final private key(s) from partial key(s) info.\n");
printf(" -sp startPubKey: Start the search with a pubKey (for private key splitting)\n");
printf(" -r rekey: Rekey interval in MegaKey (millions). Default is disabled / 0.\n");

Example batch file (for #66):

Code:

VBCr.exe -t 0 -bits 66 -gpu -g 360,512 -dis 1 -r 4800 -stop 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
pause

Or, if you want to narrow the search down in between a specific range:

Code:

VBCr.exe -t 0 -begr 20000000000000000 -endr 21000000000000000 -gpu -g 360,512 -dis 1 -r 4800 -stop 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
pause

UPDATE: The Random version is now available.
Link
https://github.com/WanderingPhilosopher/VanBitCrackenRandom

Read the readme to understand the different flags to use:
https://github.com/WanderingPhilosopher/VanBitCrackenRandom#readme


This thread is just to inform people of the release of the "Spread" version of VanBitCracken and now the Random version.

Link:
https://github.com/WanderingPhilosopher/VanBitCrakcenS

For now, I only have a Windows binary release. I will post source code later and may need help with Makefile since I am not a Linux/Makefile person; I mainly use Windows only, for better or for worse.

What is VanBitCracken?  It is a cross between Vanity Search and Bitcrack.  Telariust did the heavy lifting on this many months ago. I took the code and made minor tweaks and mods.  

What does it do?  Well, it can do what Vanity Search and Bitcrack do.  But it's primary purpose is to help find the keys in the 32 BTC transaction challenge.  AND, it does support RTX 30xx cards. Tested on a RTX 3070 card.  For now, if you are using a 30xx card, you will have to use an address string, not the full address.  Example:  Use 16jY7qLJnxb7CHZyqBP8qca9d51 instead of full address 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

A few people have the newer RTX 30xx cards but no program to run them on.  A few in the community are attempting to rewrite/rebuild/modify an existing program and that is great.  This program can be a fill in the gap until they accomplish tweaking the other program.

THAT IS THE reason behind the release...people struggling to use 30xx cards.

Hopefully someone does tweak existing programs or writes a new one to fully utilize the 30xx cards.

This is the VanBitCracken Spread Version. The Spread means that this specific version is geared towards covering ranges, not doing any random mode. The random mode will come later.

You can use the flags/options that the program known as "Bitcrack" uses, except the -b -t -p options. This program uses the grid size options that JLPs version used in version 15. If you want to adjust grid size, use the -g option. Since this is based off of version 15, the y grid size is hard coded so all you can adjust is the x grid size.

Example: -gpu -g 512 -gpuId 0 .

The other bonus feature of this program versus Bitcrack is it supports multiple GPUs.

The other difference from Bitcrack is this program will search for partial/strings of addresses and does not need a full address and can search for wildcards.

I will update this more in-depth later.

Other flags include:

-t for CPU threads (not optimized for CPU use, that was not the intent/focus)
-gpu for gpu use
-gpuId 0 (if more than one gpu use -gpuId 0,1,2,3,4 etc.)
-g to adjust x grid size; -g 256
--keyspace to enter your start and end range; example 80000:FFFFF
--continue to save work/progress; --continue continue.txt
-o for output/results file; -o outputfile.txt
-i for input file of addresses/strings; -i inputfile.txt
-r for rekey; -r 100000 the -r is important because in this spread version, it really tells the program how often to save your continue file in MKey/s. Based on your gpu and its MKey/s, you need to adjust the -r. If your gpu's speed is 100 MKey/s and you want to save your continue file every minute, then you would calculate 60 (seconds) multiplied by 100 = 6000; so you would want to input -r 6000. If you do not input a -r it will go to the default of 10000 and depending on your card you could be saving every 5 to seconds (not recommended.)

You can also enter a single address/string at the end of your command line/batch file; command line ....... 19Hed12



More to follow...

Just a silly question, because that's what I do.

Below examples are abbreviated for brevity.  All 4 examples are different private keys.

Let's say you have pubkeys (minus the 04, 02, or 03):

d769fa21825b....  priv key w
d769fa21a104....  priv key x

and two RIPEs:

f037a6296d81...  priv key y
f037a6291034...  priv key z

Which two have more ec math properties, or more relational to each other?

The pubkeys because they are directly related to k*G, or the RIPES which are a result of k*G, a sha256, and then RIPEMD'd?

Since both pubkeys start with d769fa21, what relation is there, if any?

Same for the RIPEs, any relation?

Maybe nothing, zero relation. What say you?

(I didn't want to clutter up specific programs' threads.)

First, I understand how the methods work. I have probably ran over 500 different tests at different bits.

I have also used 4 different versions of the programs and maybe that's where my questions spawns from.

To keep it simple, I am going to just use integer numbers.

Let's say I am searching for pubkey 100 in a range of 0 to 1000.  Let's also say that the tame and wild that solved the key are:

tame
pubkeyx1  940

wild
pubkeyx2  840

(940 - 840 = 100)

My tames were randomly set out in the middle of the range, say in the range of 400 to 600.

My wilds were randomly set out in the beginning of the range, say in the range of 0 to 200.

Now, here is the question:

Let's say tame pubkeyx1 originally started at 500 and worked its way up and past pubkeyx1 940 (the tame/point that helped solve the key). And wild pubkeyx2 originally started at 20...

Did the wild pubkeyx2 have to make it all the way up to tame pubkeyx1 940 to solve the key OR did it just have to make it to wild pubkeyx2 840, in order to solve the key??

With one version of the kangaroo program that I have used, if I know the key is in a 32 bit range, 80000000:FFFFFFFF, I know that my tames have to at least be in that range and the wilds have to be under that range.  Because it merely subtracts the two, example (tame) 9A82D6AB - (wild) 10000000 = private key 8A82D6AB. If the wilds are in the 80000000 thru FFFFFFFF range, the key will never be found because even FFFFFFFF - 80000000 = 7FFFFFFF, which is in the 31 bit range, not the 32 bit range.

Seems like some programs focus on a "path" and others focus on maybe hitting "random" points to solve?

Have a damaged or partial WIF? Can't make out all the characters?

If you need help recovering missing/non-legible characters, I can help.

I know there are many programs out there to help, most are really fast recovering 1-8, sometimes 9 missing characters.

I can recover up to 22 missing characters in a few hours.  Missing more than 22, I can try and recover up to 25.

(Edit): Each case is different, sometimes recovering 24 characters is easier than recovering 16 characters, it all depends on the position in which they are missing.

Two limitations, the characters missing need to be at the end or in the middle.

Examples:
5Yli2983xxxxxxxxxxxxxxxx
5Ylixxxxxxxxxxxx34879efr

And you must know the public key (or the actual address and have sent money from this address; we can look for public key that way)

Edit 2: If the characters are missing from the end, with a max of 15 characters, no public key is required.

What's the cost? It's on a case by case basis. You can PM or post what you have and I can take a look at it and let you know the difficulty of your situation and we can go from there.

Comment below or PM if you need help and we can discuss specifics and then settle on price.

UPDATE: I have removed all the BSGS files from version one, for the combined effort, on this page. The BSGS exe file located on main page is the same as Jean Luc's; I just added the function where it will print and save a text document with the public and private keys. The combined effort seemed to cause confusion because of the pub key shift so now it's back to just searching in the actual 120 bit range. Users can still share ranges searched. I will upload a simple python and batch file to randomly choose ranges to search and keep track of those ranges via a text file.

I have tweaked the code of Jean Luc Pons' Baby Step Giant Step program ( https://github.com/JeanLucPons/BSGS ) to help find the #120 puzzle in the Bitcoin Challenge Transaction ( https://bitcointalk.org/index.php?topic=5218972.0 ).

Not everyone has a GPU or a high powered GPU to use programs such as Bitcrack or Kangaroo methods. But mostly everyone has a CPU, and that is what powers the Baby Step Giant Step (BSGS) program...the CPU located in your computer. Now, everyone has a chance to help crack the puzzle. One major advantage over Kangaroo methods, the BSGS is easy to give different ranges to workers without losing in complexity which is not possible with Kangaroo.

Download the exe files and batch files here:
https://github.com/WanderingPhilosopher/BSGS

The tweaks I made to the original code include:
a random range generator
the program now automatically creates the input file:
Baby Step Size
Start Range
End Range
and applicable Public Keys (to search for)

All you have to do is download the tweaked program and the already made batch file. Once you download the files, place them in the same folder and double-click on the batch file. The program will automatically start searching for the public key. That's it. It's that easy.

What you will notice in the folder you placed your files in:
an input file will automatically pre-fill
and there will be a file called ranges_searched.txt

After we run the program for awhile, people can send me their ranges_searched.txt file and I can keep track of ranges searched and maybe this will help us narrow down to a smaller range in the future. Or, people can post how many ranges they've already searched and we can keep a running tally.

I took the #120 public key (120 bits) and compressed it down to 117 bits to make our search range 8 times smaller.

What happens when you find the public key?
If your CPU finds a key, a text document called, FOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKEYSFOUNDKE YS.txt will be created in the folder and it will contain the private key and the public key. Send that information to me, along with your bitcoin wallet address, and I will recreate the original #120 public key, and we will split the 1.2 bitcoin 50/50. It's that easy.

How I am running the program on my computer:
I have downloaded the 16 BSGS exe files and the 16 batch files. In each batch file, it calls to use one CPU thread (-t 1). So I run as many of the batch files/programs as my CPU can handle. On an i5-4690, with four instances running (4 threads total), each thread completes a range in about 9 seconds. So that's 4 ranges checked every 9 seconds, which on the safe side, this one computer checks about 34,560 ranges a day. Let me know how fast your computer completes a range.