Bitcoin puzzle transaction ~32 BTC prize to who solves 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

[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

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)

For my part, I am enlightened and I appreciate the explanations of how VBCr.exe works in the random key generation part. Thank you very much

[kTimesG]

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.

Looks like you also fall into the category of people who think they understand how things work, but they really don't.

There is no scalar multiplication used in Kangaroo (or at least not even a single one more than what it's also used for BSGS when parallelizing it).

Also not my fault you are giving BSGS demonstrations that use 11 steps for solving instead of the 7 that were sufficient. It just creates confusion in understanding the principles.

[stwenhao]

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.

Well, it is possible to write a Script, which will do exactly that.

Input Script: <sigB> <sigA> <pubKeyA> <pubKeyB>
Output Script:

Code:

OP_2DUP OP_EQUAL OP_NOT OP_VERIFY                           //checking if public keys are different
OP_2DUP OP_HASH160 OP_SWAP OP_HASH160 OP_EQUALVERIFY        //checking if their hashes are identical
OP_TOALTSTACK OP_CHECKSIGVERIFY OP_FROMALTSTACK OP_CHECKSIG //making sure that the signatures are correct, so public keys are valid

Which means, that you can just create a TapScript branch, with this challenge, and then you can spend coins by using your key, but also someone else will be able to do that, by providing that kind of collision.

See also: https://bitcointalk.org/index.php?topic=293382.0

And then, it is all about incentives: if enough coins will be there, on such address, then people will have a reason, to reveal such collision.

[WanderingPhilospher]

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

Why did you post these? You have WIFS/Private Keys that aren't in the curve. Maybe I am missing something.

[fecell]

Initializing CUDA constants...
Total GPU memory: 4294639616 bytes
Free GPU memory: 3333160960 bytes
Available for tables: 2666528768 bytes
Max half_N: 10416128
Generating 20832256 points (10416128 positive, 10416128 negative)...
Generation time: 1409.00 ms
Speed: 14785.14 points/ms

First positive point:
  x = 3130e6f4bcf13065e63b05c3c26da883962d17e1d1a7b83deddfb82798c37fa8
  y = ff3191deb7f22286ffc93dbc46f0bb78489fb82fdf9c745f6d07a0f2cdafecaf

First negative point:
  x = 50132620dbf5bb47c30c603a60897e8e74873aac7e42f30c9d1ac42f22399410
  y = 0644bbbbe2809bcb11f620e540bdbd1366e8fb80d33b1488e85a0d41d6da2240

Generated 20832256 points successfully!

is good result for 1650ti?

[Menowa*]

Do you guys think one day the computational power of a single machine will be able to brute force a 256bits?

[fixedpaul]

Initializing CUDA constants...
Total GPU memory: 4294639616 bytes
Free GPU memory: 3333160960 bytes
Available for tables: 2666528768 bytes
Max half_N: 10416128
Generating 20832256 points (10416128 positive, 10416128 negative)...
Generation time: 1409.00 ms
Speed: 14785.14 points/ms

First positive point:
  x = 3130e6f4bcf13065e63b05c3c26da883962d17e1d1a7b83deddfb82798c37fa8
  y = ff3191deb7f22286ffc93dbc46f0bb78489fb82fdf9c745f6d07a0f2cdafecaf

First negative point:
  x = 50132620dbf5bb47c30c603a60897e8e74873aac7e42f30c9d1ac42f22399410
  y = 0644bbbbe2809bcb11f620e540bdbd1366e8fb80d33b1488e85a0d41d6da2240

Generated 20832256 points successfully!

is good result for 1650ti?

Not much, on a 1650Ti you should be able to perform about 2 million point additions per millisecond.

[GoVanza108@23]

Do you guys think one day the computational power of a single machine will be able to brute force a 256bits?

Yes