Topic: VanBitCracken - a program to use for 32 BTC challenge (supports RTX 30xx cards) - page 3. (Read 5673 times)

I've tested this today with a modified Bitcrack and my conclusion is it doesn't really matter skipping one more step of converting PKH to address. Speed boost was minimal.

Devices: 01
Targets: 01
Use: RX 5700XT 8GB OC
Key Random points: 47,185,920
Addr Speed: 499 mil/sec
Ripemd160 speed: 511 mil/sec


Edit: i will test it with millions of targets to see if it causes any speed boost then post results

-----

Test done.. here it is:

Devices: 01
Targets: 6,000,000
Use: RX 5700XT 8GB OC
Key Random points: 47,185,920
Addr speed: 272 mil/sec
Ripemd160 speed: 286 mil/sec

Yes, if my math above was correct lol

Based on your calculations, i found a prefix that only repeats 4967 times in the entire 66 puzzle range: 13zb1hQbWV

Is my math correct?

What is required to run the program on Lambda machine?

Hey all,

Great discussion and lots of knowledge here. Thanks for sharing. Here is my question. I had the chance to test a few Lambda machines and they are very powerful machines. Was wondering if it's possible to run an experiment with VanBitCracken on Lambda machines specifically 2x NVIDIA RTX 6000 Ada 48 GB GPUs (not a cloud version - physical machine). I'm willing to share the results of the experiment.

Thanks,

In VanBitCracken, use -r 400, it will generate thousands of new mini random ranges and searches them until 400 million searches are done and will again generate random keys, the cycle goes on for ever random.😉

just keep generate new random keys, no sequential

I’m not understanding what you are asking. Can you elaborate or give an example?

can you add an option to keep generate&checked random keys in the start-to-end range? no sequential search

The program generates random starting points/keys and then searches sequentially from those until specified rekey number has been reached. So yes, if you use -r 0, it will search sequentially from the random generated keys and will not generate any new random keys.

Random version does not search sequentially, the first version which is not marked as random on github will only search in sequence. -r 0 means generating new random keys after every 0 generated and checked addresses, so you need to increase it, if your speed is 100 M/s, changing -r to 100 means generating random search points every second, if you have a speed of 100 M/s it's better to add -r 1000 in order to generate random points every 10 seconds, additionally you could add whatever you want, but don't make it too short because it can decrease your overall speed.

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


this command is sequential search or random search?

Well I know all the things you said, I just wanted the cost of check encoding in computing units. And the information about the 69 position of your ancestors sperms was uncalled for. Lol.

Correct. Searching directly for RIPEMD-160 is slightly faster because it skips the base58 encoding. But it doesn't really boost the speed a lot. So i would say it doesn't matter that much.

Let's take an example:

The Bitcoin Address 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM is the same as 010966776006953D5567439E5E39F86A0D273BEE.

The first one is the base58 encoded, and the second one is the RIPEMD-160. They're actually the same but in different view and shape. They're always both 160 bits too. 40-HEX x 4 = 160 bits. And you can always convert the RIPEMD-160 to base58, and base58 back to RIPEMD-160.

You can create as well a fun valid Bitcoin Burner Address. 1ELonMuskTrashAndHasNobrainyzXpEm =  0285F0F3222B4F2DB6F7B0EA4BD1B1D53A7D4852. They're both valid but obviously no one has its privates keys for this address. You can get its private key after bruteforcing about 2^160 addressess, which is older than the sperms of my 2^69 grand grand fathers. Keep in mind too, an Bitcoin Address is always valid as long as its RIPEMD-160 is 40 Hexadecimal characters.

BUT You only skip the base58 encoding. You still need to perform the steps that are needed for bruteforcing in order to get the wanted RIPEMD-160 if you search by skipping base58.

HexPrivateKey => SHA256 of PubKey => RIPEMD-160 of PubKey's Hash

Hi, I'm here again with more questions, appreciate the answer. Isn't it faster to search for RIPEMD-160 instead of address? Or the check encoding of hash 160 to address doesn't require any computation

I am not sure what doesn't add up. You are just adding numbers of addresses not necessarily different addresses.

2^256 uncompressed, 2^256 compressed is equal to 2^257 total addresses. What is their not to understand or what doesn't add up?

Now if you want to get into theory, then 2^161 addresses would contain, each possible address, twice.

But that doesn't add up with the number of possible private keys, maybe we are discussing over some precision calculations. Haven't found a provable answer to my questions yet. These ideas keep me up at nights, among other stuff.🤣

Ummmm, thanks LOL. When did I say it wasn't?

Wow guys, so knowledgable people around here. But I have discovered there are only 2^160 valid addresses. If the number of un/compressed addresses are equal, meaning half of each, then we should have 2^48 valid private keys for each address. Though there is a possibility of 2^128 uncompressed addresses with 2^64 valid private keys for each and having 2^32 compressed with 2^32 valid private keys for each address. In total 2^160 add, 2^256 Private keys. Then compressed addresses in theory should be safer to use.

I think I just invented a new algorithm Lol.

---

I don't know if any of the above measures are correct.
Let's move on to other measures, Since I'm a newbie to math. Lol

Does anyone know the probability of finding several private keys for one address? I couldn't quantify the probable outcome, In order to find them, you'd have to divide 2^96 and spread it throughout the whole 2^256 range? And then start scratching the surface. Stay tuned for my future discoveries. 😉

@OP, 2^160 uncompressed, 2^160 compressed is equal to 2^161 total addresses.

2^80 compressed addresses * 2^80 uncompressed addresses = 2^160 addresses

2^128 compressed addresses * 2^128 uncompressed addresses = 2^256 addresses