Bitcoin puzzle transaction ~32 BTC prize to who solves it

[alek76]

Hi again everyone. I added mods with different ways of generating keys. The getKeysFromRandomSeed() function is made in two versions, located in folders 005 and 006, respectively. Just replace the files and rebuild the project.
https://github.com/alek76-2/VanitySearch/tree/main/mod/005
https://github.com/alek76-2/VanitySearch/tree/main/mod/006
logs:

Code:

VanitySearch_bit66_hb03.exe -stop -t 1 -bits 66 -r 10 -level 0 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
[                                                           ]
[===========================================================]
[                Changes by Alek76 modify 0.05              ]
[===========================================================]
[          Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9         ]
[===========================================================]
[    Options added argv [-start] [-bits] and disable SSE    ]
[                                                           ]
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so [Compressed]
Start Sat Nov  4 19:48:20 2023
Base Key: Randomly changed every 10 Mkeys
Number of CPU thread: 1
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3E83B482ABFAF4B33
[1.08 Mkey/s][GPU 0.00 Mkey/s][Total 2^23.37][Prob 0.0%][50% in 2.97319e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 38C4111B5590EB61D
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.33][Prob 0.0%][50% in 3.11891e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 36524D9A4683DCF53
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.90][Prob 0.0%][50% in 3.11697e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3DAEDA8D12C373053
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^25.16][Prob 0.0%][50% in 3.11948e+34y][Found 0]

[WanderingPhilospher]

Hi again everyone. I added mods with different ways of generating keys. The getKeysFromRandomSeed() function is made in two versions, located in folders 005 and 006, respectively. Just replace the files and rebuild the project.
https://github.com/alek76-2/VanitySearch/tree/main/mod/005
https://github.com/alek76-2/VanitySearch/tree/main/mod/006
logs:

Code:

VanitySearch_bit66_hb03.exe -stop -t 1 -bits 66 -r 10 -level 0 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
[                                                           ]
[===========================================================]
[                Changes by Alek76 modify 0.05              ]
[===========================================================]
[          Tips: 1NULY7DhzuNvSDtPkFzNo6oRTZQWBqXNE9         ]
[===========================================================]
[    Options added argv [-start] [-bits] and disable SSE    ]
[                                                           ]
[ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ]
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so [Compressed]
Start Sat Nov  4 19:48:20 2023
Base Key: Randomly changed every 10 Mkeys
Number of CPU thread: 1
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3E83B482ABFAF4B33
[1.08 Mkey/s][GPU 0.00 Mkey/s][Total 2^23.37][Prob 0.0%][50% in 2.97319e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 38C4111B5590EB61D
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.33][Prob 0.0%][50% in 3.11891e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 36524D9A4683DCF53
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^24.90][Prob 0.0%][50% in 3.11697e+34y][Found 0]
[i] Generate Keys HMAC-SHA512 1024 Rounds From Random SEED
Bit 66 CPU Base Key thId 0: 3DAEDA8D12C373053
[1.03 Mkey/s][GPU 0.00 Mkey/s][Total 2^25.16][Prob 0.0%][50% in 3.11948e+34y][Found 0]

Cool features.

I peeked into your random bits code and it is wonky. A lot of code to make sure it falls within the 2000…3FFF… (66 bitrange)

[alek76]

Cool features.

I peeked into your random bits code and it is wonky. A lot of code to make sure it falls within the 2000…3FFF… (66 bitrange)

But it’s reliable, let him check) There, he also added cleaning to prevent memory leaks. You can change the algorithm in mod 006. After the random seed, do the sha256 function and then the HMAC-SHA512 function. The number of rounds can be set to any value. here - #define hmac_sha512_nb_round 2048.
I think the mod 005 algorithm is better, I like it better)

[WanderingPhilospher]

Cool features.

I peeked into your random bits code and it is wonky. A lot of code to make sure it falls within the 2000…3FFF… (66 bitrange)

But it’s reliable, let him check) There, he also added cleaning to prevent memory leaks. You can change the algorithm in mod 006. After the random seed, do the sha256 function and then the HMAC-SHA512 function. The number of rounds can be set to any value. here - #define hmac_sha512_nb_round 2048.

I’ll take your word; I was just saying it seems like a lot of code.

I rewrote the Rand function.

My old way, for #66 as an example, would have been to set
Base key at 0x2000…
And then use the Rand function you are using, with an nbit flag and pass a 65 to it.

But got tired of passing a base key when I wanted to change ranges.

[nomachine]

I am currently testing the speed of fastecdsa.encoding for h160

Code:

import os
import time, hashlib, binascii
from fastecdsa.encoding.sec1 import SEC1Encoder
from fastecdsa.curve import secp256k1
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")

dec = 30568377312064202855
def generate_h160():
    h160 = hashlib.new('ripemd160', hashlib.sha256(bytes.fromhex(binascii.hexlify(SEC1Encoder.encode_public_key(secp256k1.G * dec, compressed=True)).decode('utf-8'))).digest()).digest()
    return h160

with timing("generate_h160"):
    h160 = generate_h160()
    print(h160.hex())

3b510a18bbf7b99bf5d2bdcde07a76bddda8f376
generate_h160 Average Time: 0.00011618 seconds

This is very fast...Very close to secp256k1 as ice:

Code:

def generate_h160():
    h160 = ice.privatekey_to_h160(2, True, dec)
    return h160

 About ~30x faster than normal ecdsa in python

[dextronomous]

this shit is sick, fast, i mean, go go nomachine we will overcome all,

52e763a7ddc1aa4fa811578c491c1bc7fd570137
generate_h160 Average Time: 0.00000000 seconds

now alek, can you send a exe to pm or github. thanks man.

[alek76]

now alek, can you send a exe to pm or github. thanks man.

The program takes exactly 1 minute to assemble. These mods don't need OpenSSL, you don't have to build it if it's difficult for you. Just replace Int.cpp, Int.h and Random.cpp, Random.h with the original ones and comment out the lines #include <openssl.... The original files are in the root directory. I think it's worth learning how to assemble programs. Understand correctly, I can’t keep up with all the adjustments. In essence, this is a branching of the code; for this purpose, the “mod” directory has been added.

[digaran]

About ~30x faster than normal ecdsa in python

Why only 1 hash? 1 hash can not determine the overall speed, if you want to see the actual speed rate, you'd have to benchmark your code by going in a loop, set a range and generate 1 billion rmd160, then check the time, after all you are going to generate trillions of them when brute forcing. Base your upgrades on bulk generation of hashes, if your speed is 100M/s, 2M more or less is not significant. 5M, 10M? That's something.

[alek76]

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.

[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]