Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it

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;

Quote

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)