VanBitCracken - a program to use for 32 BTC challenge (supports RTX 30xx cards)

[WanderingPhilospher]

Wait a minute, do you have a tool that searches for public key collisions? Can we use it on 120+ bit ranges? 🥳🥳 lol.

No, but the kangaroo link above, that program will find x point collisions...

The tool Lolo54 and I were working on, takes a given public key and subtracts from and adds to the given public key.

[digaran]

Do you use CPU on the random search? I just used -t 2 and my speed went up from 28 MK to 31.5 MK also the random key points increased from 4 to 6, however adding -t 4 didn't increase the speed but generated 2 more random points.

I was wondering, do random key points depend on GPU/ CPU cores or we can generate more maybe by changing grid size? Though changing grid size never generates more key points. Lol I think I just realized what parallel computing is.

[WanderingPhilospher]

Do you use CPU on the random search? I just used -t 2 and my speed went up from 28 MK to 31.5 MK also the random key points increased from 4 to 6, however adding -t 4 didn't increase the speed but generated 2 more random points.

I was wondering, do random key points depend on GPU/ CPU cores or we can generate more maybe by changing grid size? Though changing grid size never generates more key points. Lol I think I just realized what parallel computing is.

Its programmed to only show x amount of new random starting points. However big your grid size, is how many new points are generated on each rekey. If your grid size is 10x128 then you are generating 1280 new points each rekey. I can generate and run 2800x512 grid sizes and I did not want all those points, cluttering up the screen and slowing the program down any.

[digaran]

Hi dev, I didn't get my answer elsewhere.
So I deleted my post on another topic and reposting it here.
Does anyone know how many of 2^160 addresses are uncompressed? How many compressed. Is it correct to assume that there are 2^128(compressed)×2^32(uncompressed) addresses?  Whatever the correct answer is. Could we just search in 160 bit range for both un/compressed addresses with only half the performance while searching in 256 bit range is exponentially harder?

[WanderingPhilospher]

Hi dev, I didn't get my answer elsewhere.
So I deleted my post on another topic and reposting it here.
Does anyone know how many of 2^160 addresses are uncompressed? How many compressed. Is it correct to assume that there are 2^128(compressed)×2^32(uncompressed) addresses?  Whatever the correct answer is. Could we just search in 160 bit range for both un/compressed addresses with only half the performance while searching in 256 bit range is exponentially harder?

Not sure what you are really asking/maybe I am misunderstanding your question but here goes:

We will just stick with legacy public addresses, or those that start with a "1".
You can generate just under 2^256 private keys, multiplied by the gen point, that translate to a public key, an x and y coordinate.
For uncompressed, it takes both the x and y coords, adds a "04" to the beginning, and does a sha256.
For compressed, it takes the x coord and if y is even, then public key starts with 02, if odd, starts with 03; and then does a sha256.

Now, for both uncompressed and compressed, it takes the resulting public key, a sha256, and performs a ripemd-160 of the resulting sha256.

Private key(gen)
Public key(whether uncompressed "04..." or compressed "02..." or "03..."
SHA256(Public key)
RIPEMD-160(SHA256)

For the purpose of this convo, this is all we will look at.

In theory, you can have 2^160 uncompressed addresses and/or 2^160 compressed addresses. Which again, in theory, many of those will overlap, meaning you could derive an uncompressed public address from private key 14ed2324 that also is the same public address as a compressed address from private key ed83ad448367.
Again, in theory, if you generated 2^160 uncompressed public keys (generated from x and y coords, starting with 04), or if you generated 2^160 compressed public keys (using only the x coord and the y parity (odd/even), you would in theory, have created all available public bitcoin addresses starting with "1".

So I would say there are 2^160 uncompressed public addresses and 2^160 compressed addresses lol.

Code:

1-Private ECDSA Key

12 (in hex)
 
2-Public ECDSA Key

045601570CB47F238D2B0286DB4A990FA0F3BA28D1A319F5E7CF55C2A2444DA7CCC136C1DC0CBEB930E9E298043589351D81D8E0BC736AE2A1F5192E5E8B061D58 (uncompressed)
 
3-SHA-256 hash of 2

0DA4D8594DA0D4A518922AF0E96D54857A1BBB7FA895C936BE434A43F3C304CF

4-RIPEMD-160 Hash of 3

6FC2F6488DCE92411D2498CB969B739BEFCC7988
 
5-Adding network bytes to 4

006FC2F6488DCE92411D2498CB969B739BEFCC7988
 
6-SHA-256 hash of 5

89C6CC88C80563B115A6F29060B0480729299E7EF40879047D0A340DC0E5F5C4

7-SHA-256 hash of 6

69BD5949E7E0D9F8E06258C6E2A59736726C311E13C8AF416E2D9355F7DE6839

8-First four bytes of 7

69BD5949

9-Adding 8 to the end of 5

006FC2F6488DCE92411D2498CB969B739BEFCC798869BD5949
 
10-Base58 encoding of 9

1BBwZVdBjoPxotHfrKLpHJBSy7vmc2pjex (public address)

[bigvito19]

Hi dev, I didn't get my answer elsewhere.
So I deleted my post on another topic and reposting it here.
Does anyone know how many of 2^160 addresses are uncompressed? How many compressed. Is it correct to assume that there are 2^128(compressed)×2^32(uncompressed) addresses?  Whatever the correct answer is. Could we just search in 160 bit range for both un/compressed addresses with only half the performance while searching in 256 bit range is exponentially harder?

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

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

[digaran]

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.

[WanderingPhilospher]

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

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

[digaran]

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

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

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

[WanderingPhilospher]

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

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

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

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.

[digaran]

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

[GR Sasa]

Hi, I'm here again with more questions, appreciate the answer. Isn't it faster to search for RIPEMD-160 instead of address?

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

[digaran]

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.

[gw08brdx7g]

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");

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?

[digaran]

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");

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?

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.

[WanderingPhilospher]

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");

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?

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.

[gw08brdx7g]

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");

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?

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.

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

[WanderingPhilospher]

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

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

[gw08brdx7g]

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

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

Code:

import random

start_range = int("20000000000000000", 16)
end_range = int("21000000000000000", 16)
target_address = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"

while True:
 random_hex = hex(random.randint(start_range, end_range))[2:].zfill(16) #generate random key
 #address = random_hex to address
 if(address==target_address):
  print(random_hex)
  break

just keep generate new random keys, no sequential

[digaran]

just keep generate new random keys, no sequential

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