Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Jorge54PT]

Taking advantage of wallets 71 and 72, I'd like to ask WanderingPhilosopher - author of VBCR.exe - if he could release a compilation of the executable but with os.random, if he hasn't used this type of random. Is that possible, friend?

for 18 characters
import os
random_bytes = os.urandom(9)
random_hex = random_bytes.hex().upper()
print(random_hex)

Thank you very much

[nochkin]

Taking advantage of wallets 71 and 72, I'd like to ask WanderingPhilosopher - author of VBCR.exe - if he could release a compilation of the executable but with os.random, if he hasn't used this type of random. Is that possible, friend?

It does not look like it's using Python. Most likely it's C++ with CUDA.
At least, the Linux version uses /dev/urandom, so most likely the Win binary is doing something similar.

[IlhamCung23]

I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?

As an experiment, I create privkey low-bit is there anyone who can try deriving the private key from this public key: 02e6ccb35984820aeef916e1d5585ca5f39e3d39bef71bdd845227933cf8b46d9f

[Jorge54PT]

Taking advantage of wallets 71 and 72, I'd like to ask WanderingPhilosopher - author of VBCR.exe - if he could release a compilation of the executable but with os.random, if he hasn't used this type of random. Is that possible, friend?

It does not look like it's using Python. Most likely it's C++ with CUDA.
At least, the Linux version uses /dev/urandom, so most likely the Win binary is doing something similar.

Since his source code isn't available on GitHub, I don't know what he uses, but it must be C++ and Cuda. But if he uses o.random, then random character generation is fine. That's why I asked if, if he didn't use it, he could go back and compile an .exe with os.random.

[nochkin]

I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?

Brute-forcing using the public key is much cheaper than brute-forcing using an address only.

if he didn't use it, he could go back and compile an .exe with o.random.

This is not how development works. You can't just "compile a binary" after sticking "o.random" somewhere and expecting it to work.

[Jorge54PT]

I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?

Brute-forcing using the public key is much cheaper than brute-forcing using an address only.

if he didn't use it, he could go back and compile an .exe with o.random.

This is not how development works. You can't just "compile a binary" after sticking "o.random" somewhere and expecting it to work.

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

[nochkin]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

[teguh54321]

Anyone here have example of 2 or more private key that produce same address ? Or anyone discover yet ?
I want to make some experiment with it 😅🙏

[Cricktor]

I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?

BSGS or Kangaroo would be sufficiently quick attack methods to find a low-bitlength private key fast enough.

For your example PubKey you should provide more details for others, especially what bitlength the private key has.

~~~

To my knowledge there are no known HASH160() collisions so far. Mathematically they have to exist. I haven't even heard of any known RIPEMD-160 collision so far. Please use your brain before you post.

[Jorge54PT]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that  my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from  source offcourse
If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

[kTimesG]

Anyone here have example of 2 or more private key that produce same address ? Or anyone discover yet ?
I want to make some experiment with it 😅🙏

Compute and store 2**80 H160s (from different private keys) and you'll reach the 50% threshold to get your first H160 collision between some of the stored items. Not there yet? Keep crunching at it until it pops.

NB: you might have some difficulty storing more data than the combined capacity of all storage devices in existence allows.

[invisibleecho]

I still don't fully understand — if a low-bit privkey public key is exposed, how could someone potentially derive the private key from it? Could someone please explain how that's possible?

BSGS or Kangaroo would be sufficiently quick attack methods to find a low-bitlength private key fast enough.

For your example PubKey you should provide more details for others, especially what bitlength the private key has.

~~~

To my knowledge there are no known HASH160() collisions so far. Mathematically they have to exist. I haven't even heard of any known RIPEMD-160 collision so far. Please use your brain before you post.

@Cricktor — With all due respect, maybe it’s better to stay out of topics like these if you clearly don’t understand how ECC actually works. You didn’t even attempt to answer the question. The user asked why a low-bit private key can be recovered — and your answer was just name-dropping “BSGS” and “Kangaroo” with zero explanation. What's the Point in answering if you cannot answer a simple question?

As for the answer to the original question:
Suppose your search space is from 1G to 20G, and the target private key is 14G.
Let’s say the final hash160 of the public key is: 726d44b7af8228257c030bafe764d3c5839d5c02


This hash is derived via RIPEMD160(SHA256(pubkey)) therefore any arithmetic on it will be useless.
The only way is to try every private key:
1. 751e76e8199196d454941c45d1b3a323f1433bd6
2. 06afd46bcdfd22ef94ac122aa11f241244a37ecc
3. 7dd65592d0ab2fe0d0257d571abf032cd9db93dc
…
14. 726d44b7af8228257c030bafe764d3c5839d5c02 (match)
If you started from the beginning this would take us 14 operations, from the end 7 operations.
Thats why we say the runtime of bruteforce is O(N) where N is the number of candidates in your search so you have to do at worst N operations.

__________________

Baby step giant step

Now suppose you’re given the actual public key, like: 03499fdf9e895e719cfd64e67f07d38e3226aa7b63678949e6e49b241a60e823e4
or in affine coordinates: P(499fdf9e895e719cfd64e67f07d38e3226aa7b63678949e6e49b241a60e823e4, cac2f6c4b54e855190f044e4a7b3d464464279c27a3f95bcc65f40d403a13f5)


Because you now have an actual elliptic curve point, you can do math with it.
You precompute a table of baby steps:
map[G * 1] = 1 
map[G * 2] = 2 
... 
map[G * 10] = 10

Now you walk backward from the target using giant steps:
Q - G * 10 → check if in map 
Q - G * 20 → check again 

So in our case:
1) 14G - 10G = 4G | Is 4G in the map? Yes → index = 4
Then we can calculate the real private key by doing tablesize * iterations + index, so 1*10 + 4 = 14
Again, scale this up to a babystep table of 1 billion then you can check 1 billion keys in less than a second, thats why its much much faster than bruteforce.

As for pollard kangaroo it works kinda differently, but the actual operations are much much slower simply because scalar multiplication is needed where in bsgs - you can do it with point addition.

[MrGPBit]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that  my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from  source offcourse
If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom

[Jorge54PT]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that  my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from  source offcourse
If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom

https://i.ibb.co/206x79sj/Crypt-Gen-Random.jpg

thank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards

[kTimesG]

@Cricktor — With all due respect, maybe it’s better to stay out of topics like these if you clearly don’t understand how ECC actually works. You didn’t even attempt to answer the question. The user asked why a low-bit private key can be recovered — and your answer was just name-dropping “BSGS” and “Kangaroo” with zero explanation. What's the Point in answering if you cannot answer a simple question?

90% of your explanations are a proof you have no idea what you are talking about. Baby steps using N/2 table size? Kangaroos using scalar multiplications being slower? What's the Point in answering if you cannot answer a simple question?

Cricktor was spot on with his answer, and guess what, he didn't fuck it up, while you did trying to show off as the grand expert, but instead adding more confusion to an already garbage thread.

[teguh54321]

Anyone here have example of 2 or more private key that produce same address ? Or anyone discover yet ?
I want to make some experiment with it 😅🙏

Compute and store 2**80 H160s (from different private keys) and you'll reach the 50% threshold to get your first H160 collision between some of the stored items. Not there yet? Keep crunching at it until it pops.

NB: you might have some difficulty storing more data than the combined capacity of all storage devices in existence allows.

I just want to observe the distribution around those key and the other key.  😅🙏

[WanderingPhilospher]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that  my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from  source offcourse
If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom

thank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards

the "CryptGenRandom" is only used in the timer seed:

Code:

std::string Timer::getSeed(int size) {

  std::string ret;
  char tmp[3];
  unsigned char *buff = (unsigned char *)malloc(size);

#ifdef WIN64

  HCRYPTPROV   hCryptProv = NULL;
  LPCSTR UserName = "KeyContainer";

  if (!CryptAcquireContext(
    &hCryptProv,               
    UserName,                  
    NULL,                      
    PROV_RSA_FULL,             
    0))                        
  {
    
    if (GetLastError() == NTE_BAD_KEYSET) {
      if (!CryptAcquireContext(
        &hCryptProv,
        UserName,
        NULL,
        PROV_RSA_FULL,
        CRYPT_NEWKEYSET)) {
        printf("CryptAcquireContext(): Could not create a new key container.\n");
        exit(1);
      }
    } else {
      printf("CryptAcquireContext(): A cryptographic service handle could not be acquired.\n");
      exit(1);
    }
  }

  if (!CryptGenRandom(hCryptProv,size,buff)) {
    printf("CryptGenRandom(): Error during random sequence acquisition.\n");
    exit(1);
  }

  CryptReleaseContext(hCryptProv, 0);

#else

  FILE *f = fopen("/dev/urandom","rb");
  if(f==NULL) {
    printf("Failed to open /dev/urandom %s\n", strerror( errno ));
    exit(1);
  }
  if( fread(buff,1,size,f)!=size ) {
    printf("Failed to read from /dev/urandom %s\n", strerror( errno ));
    exit(1);
  }
  fclose(f);

#endif

If I recall correctly, if you are using the -bits feature the random is:

Code:

if (nbit <= 64) {

		bits64[0] = (uint64_t)((uint64_t)MASK64 >> (64 - nbit)) & (rndl64() | ((uint64_t)0x1UL << (nbit - 1)));
		bits64[1] = 0UL;
		bits64[2] = 0UL;
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 128 && nbit > 64) {

		bits64[0] = rndl64();
		bits64[1] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[2] = 0UL;
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 192 && nbit > 128) {

		bits64[0] = rndl64();
		bits64[1] = rndl64();
		bits64[2] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 256 && nbit > 192) {

		bits64[0] = rndl64();
		bits64[1] = rndl64();
		bits64[2] = rndl64();
		bits64[3] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[4] = 0UL;
		
	}

if not using the -bits flag then random is:

Code:

uint32_t nb = nbit / 32;
	uint32_t leftBit = nbit % 32;
	uint32_t mask = 1;
	mask = (mask << leftBit) - 1;
	uint32_t i = 0;
	for (; i < nb; i++) {
		if (i + 1 != nb) {
			bits[i] = rndl();
		}
		else {
			bits[i] = rndl() | ((uint64_t)1 << nbit);
		}
		 
	}
	bits[i] = rndl() & mask;

I just want to observe the distribution around those key and the other key.

Yeah I don't think anyone has found 2 private keys that transform into the same address. If they have, they aren't telling lol.

I did build a script whilst being bored a few days ago to find:

Code:

Hash160 truncated (65 bits): 83f1c3abb24ca603
Key A   PK: 0xeedaa8fb
Key A H160: 83F1C3ABB24CA603AA19A06DA310CA91B0F00B88
Key A ADDR: 1D2f9DDCbPLifCoN4FfRF4menkJnAn7o1z

Key B   PK: 0x905ad362
Key B H160: 83F1C3ABB24CA603FD94C186DF757AB0EBB4FBDD
Key B ADDR: 1D2f9DDCbPLiqWhSzdR5Ar9dv9H6kWMHGa

and then got even more bored and looked for h160 and X coord bit collisions:

Code:

  Priv A             : 0x73376a58
  Address A          : 1HBciTzQvptaeMprAb2b7Rf7MLmKxgUxHB
  HASH160 A          : b183fc47e322f0c789fe7577464300dddbaca88d
  Priv B             : 0x1861323a3
  Address B          : 1HBciUPdv1v93jQFSkZ7uo4yrZxxZ1x6WA
  HASH160 B          : b183fc4e661efeeddeff8c2d9a52d1810d6ea606
  X‑coord A          : 40f9171f3ab73d2cb2439bac4a88f60d0db14b342b22bfe01354580299fd2dcb
  X‑coord B          : 40f9171939818f237426a1415c983a49a8f30b2df19a379598a794579b8f4d7e
  X‑match bits       : 29 (need ≥28)
  H160‑match bits    : 28 (need ≥28)

[mahmood1356]

Anyone here have example of 2 or more private key that produce same address ? Or anyone discover yet ?
I want to make some experiment with it 😅🙏

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qefJjCmLAPHbQ4x7D9Qy
L5oLkpV3aqBjhki6LmvChTCV6odsp4SXMCBHa5h391uEcXoCvAnp




5HpHagT65TZzG1PH3CSu63k8DbpvM6sdcMk3rQ8hVnTJAphn1wQ
5Km2kuu7vtFDPpxywn4u3NLpbr5jTnTiwHZAqh7Go9SJu8y7XMR
1FAiLLQsUoJwVYeYPUuoceyAyNVENv3b5w

L5oLkpV3aqBjhki6LmvChTCV6odtRDex6c4zRv2gigEhzkSSVKEP
KwDiBf89QgGbjEhKnhXJuH7LrciWTivUb4Z1b36yk3d4nHheQ1AU
1PijtU6wcyyZYiPcjvTaRBbC6xMMkd5Cj


I hope I have answered your question.

[invisibleecho]

@Cricktor — With all due respect, maybe it’s better to stay out of topics like these if you clearly don’t understand how ECC actually works. You didn’t even attempt to answer the question. The user asked why a low-bit private key can be recovered — and your answer was just name-dropping “BSGS” and “Kangaroo” with zero explanation. What's the Point in answering if you cannot answer a simple question?

90% of your explanations are a proof you have no idea what you are talking about. Baby steps using N/2 table size? Kangaroos using scalar multiplications being slower? What's the Point in answering if you cannot answer a simple question?

Cricktor was spot on with his answer, and guess what, he didn't fuck it up, while you did trying to show off as the grand expert, but instead adding more confusion to an already garbage thread.

Lmao it was a simple example to show why some algorithms are faster. And yes scalar multiplication is slower than point addition otherwise give me proof.

Looks like you also fall into the category of people who cannot read properly. Lmao.

[mahmood1356]

My friend, I didn't mention any binary. I said that he didn't provide the source code and therefore I don't know what he used to compile VBCr.exe in the end. Since I don't want to get his source code at all, I asked if he could recompile the code he has using os.random if that's not the type of random that the executable uses Simple, friend

The .exe file is a binary. I answered to the second part of your question already. Please take your time to check.

So there you go...yes, the binary for direct execution (.exe) can be compiled using the source code that the author has in his possession. What part of my question that  my friend didn't understand? :/
and my original question was to the author WanderingPhilosopher and he should understand what I asked him, and he is the one who must know the correct answer to what I asked him, if he can recompile the VBCR.exe with os.radom from  source offcourse
If VBCR.exe was compiled with os.random for key generation, then everything is fine and I don't need it to do anything. This was my question from the beginning, but I possibly explained myself badly because I neither speak nor write English.

VBCR.exe uses https://en.wikipedia.org/wiki/CryptGenRandom

https://i.ibb.co/206x79sj/Crypt-Gen-Random.jpg

thank you so much my friend. That's exactly what I wanted to know, what kind of random was used in VBCr.exe and in this case is more powerfull and more secure of os.random . best regards

the "CryptGenRandom" is only used in the timer seed:

Code:

std::string Timer::getSeed(int size) {

  std::string ret;
  char tmp[3];
  unsigned char *buff = (unsigned char *)malloc(size);

#ifdef WIN64

  HCRYPTPROV   hCryptProv = NULL;
  LPCSTR UserName = "KeyContainer";

  if (!CryptAcquireContext(
    &hCryptProv,               
    UserName,                  
    NULL,                      
    PROV_RSA_FULL,             
    0))                        
  {
    
    if (GetLastError() == NTE_BAD_KEYSET) {
      if (!CryptAcquireContext(
        &hCryptProv,
        UserName,
        NULL,
        PROV_RSA_FULL,
        CRYPT_NEWKEYSET)) {
        printf("CryptAcquireContext(): Could not create a new key container.\n");
        exit(1);
      }
    } else {
      printf("CryptAcquireContext(): A cryptographic service handle could not be acquired.\n");
      exit(1);
    }
  }

  if (!CryptGenRandom(hCryptProv,size,buff)) {
    printf("CryptGenRandom(): Error during random sequence acquisition.\n");
    exit(1);
  }

  CryptReleaseContext(hCryptProv, 0);

#else

  FILE *f = fopen("/dev/urandom","rb");
  if(f==NULL) {
    printf("Failed to open /dev/urandom %s\n", strerror( errno ));
    exit(1);
  }
  if( fread(buff,1,size,f)!=size ) {
    printf("Failed to read from /dev/urandom %s\n", strerror( errno ));
    exit(1);
  }
  fclose(f);

#endif

If I recall correctly, if you are using the -bits feature the random is:

Code:

if (nbit <= 64) {

		bits64[0] = (uint64_t)((uint64_t)MASK64 >> (64 - nbit)) & (rndl64() | ((uint64_t)0x1UL << (nbit - 1)));
		bits64[1] = 0UL;
		bits64[2] = 0UL;
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 128 && nbit > 64) {

		bits64[0] = rndl64();
		bits64[1] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[2] = 0UL;
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 192 && nbit > 128) {

		bits64[0] = rndl64();
		bits64[1] = rndl64();
		bits64[2] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[3] = 0UL;
		bits64[4] = 0UL;
	}
	else if (nbit <= 256 && nbit > 192) {

		bits64[0] = rndl64();
		bits64[1] = rndl64();
		bits64[2] = rndl64();
		bits64[3] = (uint64_t)((uint64_t)MASK64 >> (64 - (nbit - 64))) & (rndl64() | ((uint64_t)0x1UL << (nbit - 64 - 1)));
		bits64[4] = 0UL;
		
	}

if not using the -bits flag then random is:

Code:

uint32_t nb = nbit / 32;
	uint32_t leftBit = nbit % 32;
	uint32_t mask = 1;
	mask = (mask << leftBit) - 1;
	uint32_t i = 0;
	for (; i < nb; i++) {
		if (i + 1 != nb) {
			bits[i] = rndl();
		}
		else {
			bits[i] = rndl() | ((uint64_t)1 << nbit);
		}
		 
	}
	bits[i] = rndl() & mask;

I just want to observe the distribution around those key and the other key.

Yeah I don't think anyone has found 2 private keys that transform into the same address. If they have, they aren't telling lol.

I did build a script whilst being bored a few days ago to find:

Code:

Hash160 truncated (65 bits): 83f1c3abb24ca603
Key A   PK: 0xeedaa8fb
Key A H160: 83F1C3ABB24CA603AA19A06DA310CA91B0F00B88
Key A ADDR: 1D2f9DDCbPLifCoN4FfRF4menkJnAn7o1z

Key B   PK: 0x905ad362
Key B H160: 83F1C3ABB24CA603FD94C186DF757AB0EBB4FBDD
Key B ADDR: 1D2f9DDCbPLiqWhSzdR5Ar9dv9H6kWMHGa

and then got even more bored and looked for h160 and X coord bit collisions:

Code:

  Priv A             : 0x73376a58
  Address A          : 1HBciTzQvptaeMprAb2b7Rf7MLmKxgUxHB
  HASH160 A          : b183fc47e322f0c789fe7577464300dddbaca88d
  Priv B             : 0x1861323a3
  Address B          : 1HBciUPdv1v93jQFSkZ7uo4yrZxxZ1x6WA
  HASH160 B          : b183fc4e661efeeddeff8c2d9a52d1810d6ea606
  X‑coord A          : 40f9171f3ab73d2cb2439bac4a88f60d0db14b342b22bfe01354580299fd2dcb
  X‑coord B          : 40f9171939818f237426a1415c983a49a8f30b2df19a379598a794579b8f4d7e
  X‑match bits       : 29 (need ≥28)
  H160‑match bits    : 28 (need ≥28)

This is nothing new, and I've asked this question several times, and no satisfactory answer has been given in the forum. And it doesn't require coding, all calculations can be done with a calculator.
5HpHagT65TZzG1PH3CSu63k8DbpvM6sdcMk3rQ8hVnTJAphn1wQ
5Km2kuu7vtFDPpxywn4u3NLpbr5jTnTiwHZAqh7Go9SJu8y7XMR
1FAiLLQsUoJwVYeYPUuoceyAyNVENv3b5w

L5oLkpV3aqBjhki6LmvChTCV6odtRDex6c4zRv2gigEhzkSSVKEP
KwDiBf89QgGbjEhKnhXJuH7LrciWTivUb4Z1b36yk3d4nHheQ1AU
1PijtU6wcyyZYiPcjvTaRBbC6xMMkd5Cj