Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

That's something.

1 / 0.00011618 = 8607 Keys/s. But in fact it is more. To reduce measurement time, you need to generate more than 10,000 hashes in a cycle, preferably tens of millions. Then the measurement time is not actually counted, and the result will be more plausible.

Redo the wheel, nomachine, LOL.

citb0in has already done benchmark tests on fastecdsa, iceland, etc. generating and writing 1 million addresses to file. They have a whole thread dedicated to the test.

[nomachine]

Maybe I missed someone used SEC1Encoder in that thread.  

this shit is sick, fast

there is even faster function (one zero faster)

def private_key_to_public_key():
   return(binascii.hexlify(SEC1Encoder.encode_public_key(secp256k1.G * dec, compressed=True)).decode('utf-8'))

from dec to public key, if you have it...  

[digaran]

That's something.

1 / 0.00011618 = 8607 Keys/s. But in fact it is more. To reduce measurement time, you need to generate more than 10,000 hashes in a cycle, preferably tens of millions. Then the measurement time is not actually counted, and the result will be more plausible.

Redo the wheel, nomachine, LOL.

citb0in has already done benchmark tests on fastecdsa, iceland, etc. generating and writing 1 million addresses to file. They have a whole thread dedicated to the test.

What is the use of saving a million "addresses" to a file? Can we not see any more base58 encoded addresses mentioned ever again when we are talking about brute forcing puzzles? Base58 used anywhere, whether to generate vanity or find a puzzle will slow down the speed by at least 5%.  Now imagine if we could instead increase the speed 5% more, difference would be like saving $100k from $1M.  Or for example if you could spend $50k to solve a key in 6 month, with 10% more speed you can save $5k.
These small numbers/percentages might sound insignificant for most people, you can only appreciate them when even 1% means millions to be saved.

[nomachine]

Base58 used anywhere...

Thanks for the banking tip but I don't use Base58 in general in my scripts. And if I do use it, it's usually a custom B58. Most often after the H160 target found. I do NOT care what the address is. 

[WanderingPhilospher]

That's something.

1 / 0.00011618 = 8607 Keys/s. But in fact it is more. To reduce measurement time, you need to generate more than 10,000 hashes in a cycle, preferably tens of millions. Then the measurement time is not actually counted, and the result will be more plausible.

Redo the wheel, nomachine, LOL.

citb0in has already done benchmark tests on fastecdsa, iceland, etc. generating and writing 1 million addresses to file. They have a whole thread dedicated to the test.

What is the use of saving a million "addresses" to a file? Can we not see any more base58 encoded addresses mentioned ever again when we are talking about brute forcing puzzles? Base58 used anywhere, whether to generate vanity or find a puzzle will slow down the speed by at least 5%.  Now imagine if we could instead increase the speed 5% more, difference would be like saving $100k from $1M.  Or for example if you could spend $50k to solve a key in 6 month, with 10% more speed you can save $5k.
These small numbers/percentages might sound insignificant for most people, you can only appreciate them when even 1% means millions to be saved.

Because it was a community involved quest; to find the fastest python code to gen and write to a file, 1 million addresses.
Not everything is about the puzzles/challenges.

One could say what is the point of providing a bunch of info on add sub div without concrete examples, from start to finish with result, but some do it anyway.

Base58 used anywhere...

Thanks for the banking tip but I don't use Base58 in general in my scripts. And if I do use it, it's usually a custom B58. Most often after the H160 target found. I do NOT care what the address is.

Not needed for challenges/puzzle, for sure.
However, a few of your scripts do not work/encode the correct RIPEMD160. You should run a test on all of them before posting. AT least a small test of say, finding H160 in a 2^28 range.

[nomachine]

Base58 used anywhere...

Thanks for the banking tip but I don't use Base58 in general in my scripts. And if I do use it, it's usually a custom B58. Most often after the H160 target found. I do NOT care what the address is.

Not needed for challenges/puzzle, for sure.
However, a few of your scripts do not work/encode the correct RIPEMD160. You should run a test on all of them before posting. AT least a small test of say, finding H160 in a 2^28 range.

Yep...I corrected them in old posts.  

[L4rs_]

Damn I could really use 32 Bitcoins. I think the code has something to do with 1337

[nomachine]

Damn I could really use 32 Bitcoins. I think the code has something to do with 1337

In coding and programming, "1337" doesn't have any specific technical meaning. It's more of a cultural reference.

[digaran]

Because it was a community involved quest; to find the fastest python code to gen and write to a file, 1 million addresses.
Not everything is about the puzzles/challenges.

One could say what is the point of providing a bunch of info on add sub div without concrete examples, from start to finish with result, but some do it anyway.

I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.
Also do you remember few month back when I could find public keys similar to #125 key? Well I will tell you this but it's not going to help you or anyone else.

Here is a new angle to work with subtraction only, try to subtract #130 from end range to get this :

Code:

0308360beeb0177961b04eccc33decdf63e23d205abc8ef6355d659d1313459ba7

Now if you just subtract 1 from it:

Code:

026a0747b3229f32ce2f0f7bd77a7bd306f6c95d27e7c5bee22a417938d9988605

Now if you add it to #130, you will have :

Code:

03e067911ebf6bacf87a8088ab9344c95843aed80b070eed09f9d947c98dfc0249
00000000000000000000000000000003ffffffffffffffffffffffffffffffff

Now if you subtract the above instead of 1, you get this:

Code:

035dee726b0fe623224fa1f4d79af66a9a1829213ec675875c619266a5f184e7d1

Once again, if you add the above key to #130, you won't get 1,  instead you are actually adding -1 of #130 to #130, you can confirm that by subtracting it from #130.
Ok, why did we get a different result in our first addition? Because we just subtracted 1 from our offset the first time, so no -n result, but when we subtracted a larger key than our offset, the second addition should have given us 1, but why it added -1 of #130 to #130? Because I knew which key was greater than the other, but if you subtract the larger key > 3fffff..... from our offset, the second addition would have resulted in G.
I don't know why I'm explaining modular effect here, this is useless, unless you know a few tricks.😉

[nomachine]

I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.

It doesn't matter if it's 1, 5 or 10 million.
To find a 66-bit number within 10 days, you would need to check approximately 200 (billion) giga/hashes - addresses per second.  It doesn't matter if it's an even or odd number.  

And here is the reason why someone has to invent a new random generator - or new computing technology in general

Code:

import os, random, time
from contextlib import contextmanager

@contextmanager
def timing(label):
    start_time = time.time()
    try:
        yield
    finally:
        end_time = time.time()
        elapsed_time = end_time - start_time
        print(f"{label} Average Time: {elapsed_time:.8f} seconds")

puzzle = 66
start = 2 ** (puzzle - 1)
end = (2 ** puzzle) - 1

def generate_random():  
    return random.randint(start, end)

with timing("generate_random"):
    random_value = generate_random()
    print(random_value)

72040005465485153674
generate_random Average Time: 0.00002623 seconds

you need random generator with
Average Time:  0.000000000002  seconds

And then all other parts of the script no slower than this.

Just replace the files and rebuild the project.

Code:

make
mkdir -p obj
cd obj && mkdir -p GPU
cd obj && mkdir -p hash
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/Base58.o -c Base58.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/IntGroup.o -c IntGroup.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/main.o -c main.cpp
g++ -m64 -mssse3 -Wno-write-strings -O2 -I. -I/usr/local/cuda-8.0/include -I/usr/local/include -o obj/Random.o -c Random.cpp
Random.cpp: In function ‘void RandAddSeed()’:
Random.cpp:154:5: error: ‘memset’ was not declared in this scope
  154 |     memset(&nCounter, 0, sizeof(nCounter));
      |     ^~~~~~
Random.cpp:27:1: note: ‘memset’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
   26 | #include <openssl/ripemd.h>
  +++ |+#include <cstring>
   27 | //
make: *** [Makefile:70: obj/Random.o] Error 1

You need to #include <cstring>  in Random.cpp

p.s.

Should add seed to be written in Results.txt

Code:

fprintf(f, "PubAddress: %s\n", addr.c_str());
fprintf(f,  "Seed: %s\n", seed.c_str());

Something like this. So that we can reproduce the same result

[WanderingPhilospher]

To find a 66-bit number within 10 days, you would need to check approximately 200 (billion) giga/hashes - addresses per second.
.....
And here is the reason why someone has to invent a new random generator - or new computing technology in general

Why focus on a random generator?

This seems silly to me. Why you ask? Start at 20000... (first 66 bit key) and go sequentially, no random generator needed.

At the moment, it's a lack of resources/equipment speed. But each new generation of GPUs is getting faster and faster. Who knows that the RTX 50/60/70 series will bring in terms of "hashing"; the 40xx was a huge upgrade in speed over the 30xx cards.

TTD's pool is knocking out a lot of ranges each day; still only above 5% checked, but if more people joined (pool of resources) 66 would fall quicker, but most think they can do it solo (think pool vs solo mining).

I do think 66 will be found faster vs 64.

Because it was a community involved quest; to find the fastest python code to gen and write to a file, 1 million addresses.
Not everything is about the puzzles/challenges.

One could say what is the point of providing a bunch of info on add sub div without concrete examples, from start to finish with result, but some do it anyway.

I know it was a "community challenge", I was wondering if it has any significance to nomachine's code when you said 1M address.
Also do you remember few month back when I could find public keys similar to #125 key? Well I will tell you this but it's not going to help you or anyone else.

Here is a new angle to work with subtraction only, try to subtract #130 from end range to get this :

Code:

0308360beeb0177961b04eccc33decdf63e23d205abc8ef6355d659d1313459ba7

Now if you just subtract 1 from it:

Code:

026a0747b3229f32ce2f0f7bd77a7bd306f6c95d27e7c5bee22a417938d9988605

Now if you add it to #130, you will have :

Code:

03e067911ebf6bacf87a8088ab9344c95843aed80b070eed09f9d947c98dfc0249
00000000000000000000000000000003ffffffffffffffffffffffffffffffff

Now if you subtract the above instead of 1, you get this:

Code:

035dee726b0fe623224fa1f4d79af66a9a1829213ec675875c619266a5f184e7d1

Once again, if you add the above key to #130, you won't get 1,  instead you are actually adding -1 of #130 to #130, you can confirm that by subtracting it from #130.
Ok, why did we get a different result in our first addition? Because we just subtracted 1 from our offset the first time, so no -n result, but when we subtracted a larger key than our offset, the second addition should have given us 1, but why it added -1 of #130 to #130? Because I knew which key was greater than the other, but if you subtract the larger key > 3fffff..... from our offset, the second addition would have resulted in G.
I don't know why I'm explaining modular effect here, this is useless, unless you know a few tricks.

Again, it is hard to follow your work. "Now if you subtract the above instead of 1, you get this:" this is confusing. Just put in code each step you are doing.

Also, the #130 end range is 3ffffffffffffffffffffffffffffffff, and not 400000000000000000000000000000000.

It's really hard following your steps. And I really try lol. Not expecting your steps will teach me something new, but to at least say, yep, his work was correct.

Example:

Code:

Take pub x that is the pub of priv key y
subtract or add 0xf or 16 from it and you get
pub z
etc
etc

[moderator's note: consecutive posts merged]

[alek76]

Should add seed to be written in Results.txt

Code:

fprintf(f, "PubAddress: %s\n", addr.c_str());
fprintf(f,  "Seed: %s\n", seed.c_str());

Something like this. So that we can reproduce the same result

Experiment with the least significant bits up to 2^30, which seed is more suitable in terms of solution speed. I like your ideas  
Added new code to mods on Github. Saving Seed to the Result.txt file.
Then run with the -s option. Seed for mod 006, key generation methods are different.

Code:

VanitySearch.exe -stop -t 1 -bits 28 -r 1 -s 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY

The installed SEED works if the -r (rekey) option is present. Updated.
Without the -r (rekey) option, the start key is selected with the -start option OR -s option and use -bits option.
file Result.txt

Code:

Seed: 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8

You can reproduce the result  

[digaran]

Should add seed to be written in Results.txt

Code:

fprintf(f, "PubAddress: %s\n", addr.c_str());
fprintf(f,  "Seed: %s\n", seed.c_str());

Something like this. So that we can reproduce the same result

Experiment with the least significant bits up to 2^30, which seed is more suitable in terms of solution speed. I like your ideas  
Added new code to mods on Github. Saving Seed to the Result.txt file.
Then run with the -s option

Code:

VanitySearch.exe -stop -t 1 -bits 28 -r 1 -s 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY

The installed SEED works if the -r (rekey) option is present. Updated.
Without the -r (rekey) option, the start key is selected with the -start option.
file Result.txt

Code:

Seed: 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8

You can reproduce the result  

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

[alek76]

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one.
If we get lucky. 

[WanderingPhilospher]

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one.
If we get lucky.  

You should probably explain what you have in code above. You have 2 different seeds and you say saved to result.txt file. So I can see Diagran’s point.

Also, explain how any of these seeds or different random options actually help?!
Even if one random option is faster by 9 million percent, which would still be minimal in the scheme of things, the hard work still has to be done, taking the private key and transforming it down to the H160.
My VBC random is fast; finds a key in a 36 bit range in an avg of 8 seconds. User has option to choose a range or simply enter a bits number such as 66.
However, the generation of the random key, and its speed, really doesn’t matter IMO. It takes less than .4 seconds to generate thousands of keys, and yet, the actual computation must begin…the actual work.

[dextronomous]

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one.
If we get lucky. 

hi there,

could you make the github hold your different exe files, so we dont have to compile to test all these mods,
i could compile but am a tad late for sleeping i guess. and is this what demining mentiones just wondering

/* Magic Mersenne Twister constants */
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL
#define UPPER_MASK 0x80000000UL
#define LOWER_MASK 0x7fffffffUL
Technical Description CVE-2023-39910
The cryptocurrency wallet entropy filling mechanism used in Libbitcoin Explorer 3.0.0–3.6.0 is weak, also known as the Milk Sad problem.  Using the Mersenne Twister mt19937 PRNG limits the internal entropy to 32 bits regardless of settings. This allows remote attackers to recover any wallet private keys generated from the entropy results of “bxseed” and steal funds. (Affected users need to transfer funds to a new secure cryptocurrency wallet)
is this issue present still in your vanitygen, thanks for the exes.

[alek76]

Also, explain how any of these seeds or different random options actually help?!
Even if one random option is faster by 9 million percent, which would still be minimal in the scheme of things, the hard work still has to be done, taking the private key and transforming it down to the H160.
My VBC random is fast; finds a key in a 36 bit range in an avg of 8 seconds. User has option to choose a range or simply enter a bits number such as 66.
However, the generation of the random key, and its speed, really doesn’t matter IMO. It takes less than .4 seconds to generate thousands of keys, and yet, the actual computation must begin…the actual work.

If loop the seed generation until the Starting key is equal to the target key puzzle bit 32. This takes a long time. We need to know not only the seed. what algorithm was used and the number of rounds. Therefore, I created a function for separating a 512-bit key, one was used as a master key, the other as a chain key. There you can also add serialization and make several keys from a chained key. And make them starting keys. This time is again needed to create the code.

/* Magic Mersenne Twister constants */
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL
#define UPPER_MASK 0x80000000UL
#define LOWER_MASK 0x7fffffffUL
Technical Description CVE-2023-39910
The cryptocurrency wallet entropy filling mechanism used in Libbitcoin Explorer 3.0.0–3.6.0 is weak, also known as the Milk Sad problem.  Using the Mersenne Twister mt19937 PRNG limits the internal entropy to 32 bits regardless of settings. This allows remote attackers to recover any wallet private keys generated from the entropy results of “bxseed” and steal funds. (Affected users need to transfer funds to a new secure cryptocurrency wallet)
is this issue present still in your vanitygen, thanks for the exes.

I know this very well; this protocol was developed a long time ago. Why are you telling me this again???
1. This piece of software code is present, AND IT IS NOT USED.
For this, OpenSSL and other key generation functions were added. Read the background of this fork! What's added there? And what was removed there on purpose. And why was all this done?
2. Regarding the exe, it has already been explained to you. Don't be pushy. You need to put in the effort if you want results.

The values of random keys fixed by the rseed(seed) function are used to check for possible mathematical errors and the correct assembly of the code by the compiler. The constant values used to check the correctness of calculations and speed tests are also present in the GPU code. If these Magic Mersenne Twister constants macro definitions are confusing, you can change the code in Engine.cu - remove rseed(seed) and Rand(256). Opt out of the GPU test.

[nomachine]

Added new code to mods on Github. Saving Seed to the Result.txt file.
Then run with the -s option. Seed for mod 006, key generation methods are different.

Code:

VanitySearch.exe -stop -t 1 -bits 28 -r 1 -s 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY

The installed SEED works if the -r (rekey) option is present. Updated.
Without the -r (rekey) option, the start key is selected with the -start option OR -s option and use -bits option.
file Result.txt

Code:

Seed: 45730C0CCA52F09AC21B00E4ADA360E9709152473494E91DFD74B6E11938BF30
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8
Seed: B6D88248ED9FA96F42684121433DCACEB655BF37E0B65C007E58D0AD59ADECBF
PubAddress: 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M82GSgY8p5EkUe
Priv (HEX): 0xD916CE8

You can reproduce the result  

Thanks. Btw...We don't need such a long seed lenght - even 9 gets the job done.

Code:

  // Seed
  if (seed.length() == 0) {
    // Default seed
    seed = Timer::getSeed(9);
  }

  if (paranoiacSeed) {
    seed += Timer::getSeed(9);
  }

 

[digaran]

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one.
If we get lucky. 

I'm still unable to understand the process, what does it mean selecting the fastest one? Ok, let me get this straight, you are generating what, private keys from a seed? I wanna know how is it possible to generate 1 key from 2 different seeds, this should be impossible unless you are not using random, or you have just changed the key generator, but still doesn't explain how these 2 seeds generated the same private key:

Code:

45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf

ELI5, please.

[nomachine]

Am I understanding this correctly that you have found seed collisions? Because I see different seeds with the same key as output, or is this something else?

This is not a collision. The one that was used is saved. With the -r 1 option you can select the fastest one.
If we get lucky. 

I'm still unable to understand the process, what does it mean selecting the fastest one? Ok, let me get this straight, you are generating what, private keys from a seed? I wanna know how is it possible to generate 1 key from 2 different seeds, this should be impossible unless you are not using random, or you have just changed the key generator, but still doesn't explain how these 2 seeds generated the same private key:

Code:

45730c0cca52f09ac21b00e4ada360e9709152473494e91dfd74b6e11938bf30
b6d88248ed9fa96f42684121433dcaceb655bf37e0b65c007e58d0ad59adecbf

ELI5, please.

The one in the file is the fastest. But there is something else here. This script can be modified to search for a seed - you give it a WIF as input and it rotates all the seeds to hit the fastest one.