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

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

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.

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?

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.