Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Bajula]

Just for a fun little "thing" : for those frustrated by how long this takes.. someone could sort out how long it would take with a gpu and bitcrack and now it suddenly looks like a month is no big deal.

[1715407301]

1715407301

[1715407301]

1715407301

[1715407301]

1715407301

[zielar]

On first machine (600GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 384GB

On second machine (80GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 64GB
Search bits = 90
Search Keys....  from 20000000000000000000000 to 3ffffffffffffffffffffff

... and nothing changes from two days on both machines.
Something is wrong?
Am I to understand that no more changes are expected in these processes?

Can someone modify the code in such a way that the process is visible (along with the percentage)?

After string

Code:

for (uint64_t i = 1; i < GSTEP; i++) {

insert

Code:

if(i%1000000==0){
     time_t tt = time(NULL);
     tim = localtime(&tt);
     printf("%d:%d:%d Loop generate %zu from %zu, %g%% \n", tim->tm_hour, tim->tm_min, tim->tm_sec, i, GSTEP, (double)(i/(GSTEP/100)));
}

showed percentage at generated array. Where 1000000 each showed. May changed.

After string

Code:

for (uint64_t i = skip; i < g_max; i++) {

Insert

Code:

if(i%10000000==0){
            
            time_t tt = time(NULL);
            tim = localtime(&tt);
            uint64_t real_i = i - skip;
            uint64_t real_diff = g_max - skip;
            printf("%d:%d:%d Search in %zu from start %zu end %zu, real_i:%zu \t \t real_diff:%zu \tPercent %g%% \n", tim->tm_hour, tim->tm_min, tim->tm_sec, i, skip, g_max, real_i, real_diff, (double)(real_i/(real_diff/100)));
        }

showed percentage each 10000000 try searched.

9.c: In function ‘main’:
9.c:107:2: error: ‘tim’ undeclared (first use in this function); did you mean ‘time’?
  tim = localtime(&tt);
  ^~~
  time
9.c:107:2: note: each undeclared identifier is reported only once for each function it appears in

[mrxtraf]

On first machine (600GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 384GB

On second machine (80GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 64GB
Search bits = 90
Search Keys....  from 20000000000000000000000 to 3ffffffffffffffffffffff

... and nothing changes from two days on both machines.
Something is wrong?
Am I to understand that no more changes are expected in these processes?

Can someone modify the code in such a way that the process is visible (along with the percentage)?

After string

Code:

for (uint64_t i = 1; i < GSTEP; i++) {

insert

Code:

if(i%1000000==0){
     time_t tt = time(NULL);
     tim = localtime(&tt);
     printf("%d:%d:%d Loop generate %zu from %zu, %g%% \n", tim->tm_hour, tim->tm_min, tim->tm_sec, i, GSTEP, (double)(i/(GSTEP/100)));
}

showed percentage at generated array. Where 1000000 each showed. May changed.

After string

Code:

for (uint64_t i = skip; i < g_max; i++) {

Insert

Code:

if(i%10000000==0){
            
            time_t tt = time(NULL);
            tim = localtime(&tt);
            uint64_t real_i = i - skip;
            uint64_t real_diff = g_max - skip;
            printf("%d:%d:%d Search in %zu from start %zu end %zu, real_i:%zu \t \t real_diff:%zu \tPercent %g%% \n", tim->tm_hour, tim->tm_min, tim->tm_sec, i, skip, g_max, real_i, real_diff, (double)(real_i/(real_diff/100)));
        }

showed percentage each 10000000 try searched.

9.c: In function ‘main’:
9.c:107:2: error: ‘tim’ undeclared (first use in this function); did you mean ‘time’?
  tim = localtime(&tt);
  ^~~
  time
9.c:107:2: note: each undeclared identifier is reported only once for each function it appears in

Sorry
Before string

Code:

printf("Build Hash, MEM size = %dGB\n", (uint32_t)(HASH_SIZE*one_table_bytes>>30));

insert

Code:

struct tm *tim;

example

Code:

    uint64_t one_table_bytes;
    one_table_bytes = (uint64_t)&table[1] - (uint64_t)&table[0];
    
    struct tm *tim;//Inser this line

    printf("Build Hash, MEM size = %dGB\n", (uint32_t)(HASH_SIZE*one_table_bytes>>30));
    secp256k1_gej pt;

[zielar]

Thank you so much.... Now that's working.

[mrxtraf]

Thank you so much.... Now that's working.

5-10 percetn from found prize  Jock 
Good luck.

[zielar]

Thank you so much.... Now that's working.

5-10 percetn from found prize  Jock 
Good luck.

I am not selfish and I remember someone if somebody helped me. If I manage to take the next wallet - you can be sure that I will not miss you when sharing the prize :-)

[Babi Ngetot]

can some one help me  bulding BitCrack on linux ?

[iparktur]

I do not know English - I use GOOGLE TRANSLATER.
I shall try to write. As on a condition of health I can not work on the computer more than three hours per day.
At me the very weak computer (the processor AMD A6-3420M APU with HD Graphics AMD Radeon HD 6520G) - gives speed only 0.63 MKey/s
I use the CPU (-d 1), not the video card (for software clBitCrack.exe)
Really I can search in a range with accuracy
FROM - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX0000000001:
TO - XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFFFFFFFFFF

Here all meanings X for each of 54 positions should be known, i.e. I can search only in the first 10 positions
Therefore I am compelled to search for other method to narrow keyspace of search in hexadecimal
For this purpose I have seen(overlooked) all found variants and has counted factor of increase (step) from the previous address to the next.
The positions from addresses #50 up to addresses #70 were interesting to me
For this purpose I each position of "grown-up" of the address I divided into a position of the "younger" address.
In a result I have received such factors (K*):

50 00000000000000000000000000000000000000000000000000022bd43c2e9354 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk - K*3.3687335859160928
51 00000000000000000000000000000000000000000000000000075070a1a009d4 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS - K*2.048065899832177
52 000000000000000000000000000000000000000000000000000efae164cb9e3c 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim - K*1.6041007864337676
53 00000000000000000000000000000000000000000000000000180788e47e326c 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT - K*1.4747074651267212
54 00000000000000000000000000000000000000000000000000236fb6d5ad1f43 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy - K*3.0122337265933986
55 000000000000000000000000000000000000000000000000006abe1f9b67e114 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa - K*1.4717313228011604
56 000000000000000000000000000000000000000000000000009d18b63ac4ffdf 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi - K*3.126406400159927
57 00000000000000000000000000000000000000000000000001eb25c90795d61c 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz - K* 1.4465302194572583                                            
58 00000000000000000000000000000000000000000000000002c675b852189a21 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf - K*2.6256582308911342
59 00000000000000000000000000000000000000000000000007496cbb87cab44f 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt - K*2.1616937162108232
60 0000000000000000000000000000000000000000000000000fc07a1825367bbe 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su - K*1.2561547139608029
61 00000000000000000000000000000000000000000000000013C96A3742F64906 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB - K*21.4396439850506547
62 Unknown Private Key 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi      
63 Unknown Private Key 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4            
64 Unknown Private Key 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN      
.....
65 000000000000000000000000000000000000000000000001a838b13505b26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe - K*31.7464340386176884
66 Unknown Private Key 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so      
67 Unknown Private Key 1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9    
68 Unknown Private Key 1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ
69 Unknown Private Key 19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG        
.....
70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR
71    Unknown Private Key    1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU    
72    Unknown Private Key    1JTK7s9YVYywfm5XUH7RNhHJH1LshCaRFR
73    Unknown Private Key    12VVRNPi4SJqUTsp6FmqDqY5sGosDtysn4      
74    Unknown Private Key    1FWGcVDK3JGzCC3WtkYetULPszMaK2Jksv
.....
75 0000000000000000000000000000000000000000000004c5ce114686a1336e07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt

Accuracy of "hit" rather high and the error makes no more than +128 addresses.
But factors (steps) have the very large difference:
Minimal - K*1.2561547139608029
Maximal - K*3.3687335859160928
I think, that after addresses #61 presumably factor will be even more in a range from K*4 up to K*6
It is possible, that the organizer specially has arranged addresses with balance with such different steps.
My idea has appeared " complete delirium "!

[jpyao78]

On first machine (600GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 384GB

On second machine (80GB RAM):

Code:

Check bit = 90 only, pubkey is:
035c38bd9ae4b10e8a250857006f3cfd98ab15a6196d9f4dfd25bc7ecc77d788d5
Build Hash, MEM size = 64GB
Search bits = 90
Search Keys....  from 20000000000000000000000 to 3ffffffffffffffffffffff

... and nothing changes from two days on both machines.
Something is wrong?
Am I to understand that no more changes are expected in these processes?

Can someone modify the code in such a way that the process is visible (along with the percentage)?

for machine's memory is 600GB
at least this code need update:
uint32_t entry = xst.n[0] & (HASH_SIZE-1);
to
uint64_t entry = xst.n[0] & (HASH_SIZE-1);

and update
typedef struct hashtable_entry {
    uint32_t x;
    uint32_t exponent;
} hashtable_entry;
to
typedef struct hashtable_entry {
    uint32_t x;
    uint64_t exponent; //this will take more memory
} hashtable_entry;

[itod]

There is 1 way to this  simple brute force and you need to study here is this https://github.com/pikachunakapika/BitCrack
Is method 2 is a baby-step-giant-step http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/
 https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89
Reply but it is not suitable for people who do not have Linux and who are not familiar with the basics of programming ,C, C+
Yes, and my wallet 12gyE8EKXsePJVDFECRda8vxRQvVoWpsEB  

BTW, I do not see here any code that deals with private keys with known public keys, #65, #70, #75, etc, which were moved to expose public keys. Is that code public at all?

[supika]

There is 1 way to this  simple brute force and you need to study here is this https://github.com/pikachunakapika/BitCrack
Is method 2 is a baby-step-giant-step http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/
 https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89
Reply but it is not suitable for people who do not have Linux and who are not familiar with the basics of programming ,C, C+
Yes, and my wallet 12gyE8EKXsePJVDFECRda8vxRQvVoWpsEB  

BTW, I do not see here any code that deals with private keys with known public keys, #65, #70, #75, etc, which were moved to expose public keys. Is that code public at all?

65 000000000000000000000000000000000000000000000001A838B13505B26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe

70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR

75 0000000000000000000000000000000000000000000004C5CE114686A1336E07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt

[Gibreil]

Any info on who published this puzzle and what's their goal? Also, how would one go on about calculating those pvk decimal values and covert them to the private keys?

I don't know why but I'm smelling a big scam. Because a newbie that offer more than 12 000€ to solve a following of numbers this is strange...

The OP is not offering anything

He just have an overstatement. OP did not say anything in his thread regarding with payments. However, if you just look at the title Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it. You can emphasize also that he will pay 32 BTC as a reward for those who solves the puzzle. I think all the address will never been located or determined because even those are in blockchain, all users have anonimity. in short, we can hide ourselves but we do not know if there are pros that can locate the IP.

[itod]

There is 1 way to this  simple brute force and you need to study here is this https://github.com/pikachunakapika/BitCrack
Is method 2 is a baby-step-giant-step http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/
 https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89
Reply but it is not suitable for people who do not have Linux and who are not familiar with the basics of programming ,C, C+
Yes, and my wallet 12gyE8EKXsePJVDFECRda8vxRQvVoWpsEB  

BTW, I do not see here any code that deals with private keys with known public keys, #65, #70, #75, etc, which were moved to expose public keys. Is that code public at all?

65 000000000000000000000000000000000000000000000001A838B13505B26867 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe

70 0000000000000000000000000000000000000000000000349B84B6431A6C4EF1 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR

75 0000000000000000000000000000000000000000000004C5CE114686A1336E07 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt

I said "code", as in "source code", this is printout from the output.

[BurtW]

I think, that after addresses #61 presumably factor will be even more in a range from K*4 up to K*6
It is possible, that the organizer specially has arranged addresses with balance with such different steps.
My idea has appeared " complete delirium "!

We already know exactly how the author of the puzzle generated the private keys because he told us exactly how he did it right here in this thread.

The private keys were made by taking a random number and then masking it to the desired bit length:

#1 = 256 bit random number bit wise ANDed with (2¹ - 1)
#2 = 256 bit random number bit wise ANDed with (2² - 1)
#3 = 256 bit random number bit wise ANDed with (2³ - 1)
...
#60 = 256 bit random number bit wise ANDed with (2⁶⁰ - 1)
#61 = 256 bit random number bit wise ANDed with (2⁶¹ - 1)
#65 = 256 bit random number bit wise ANDed with (2⁶⁵ - 1)
#70 = 256 bit random number bit wise ANDed with (2⁷⁰ - 1)
#75 = 256 bit random number bit wise ANDed with (2⁷⁵ - 1)
...
#160 = 256 bit random number bit wise ANDed with (2¹⁶⁰ - 1)

So, there is no pattern to be discovered.

[iparktur]

We already know exactly how the author of the puzzle generated the private keys because he told us exactly how he did it right here in this thread.

The private keys were made by taking a random number and then masking it to the desired bit length:

#1 = 256 bit random number bit wise ANDed with (2¹ - 1)
#2 = 256 bit random number bit wise ANDed with (2² - 1)
#3 = 256 bit random number bit wise ANDed with (2³ - 1)
...
#60 = 256 bit random number bit wise ANDed with (2⁶⁰ - 1)
#61 = 256 bit random number bit wise ANDed with (2⁶¹ - 1)
#65 = 256 bit random number bit wise ANDed with (2⁶⁵ - 1)
#70 = 256 bit random number bit wise ANDed with (2⁷⁰ - 1)
#75 = 256 bit random number bit wise ANDed with (2⁷⁵ - 1)
...
#160 = 256 bit random number bit wise ANDed with (2¹⁶⁰ - 1)

So, there is no pattern to be discovered.
[/quote]

Yes I understand.
Just thought - what if .....

[Firebox]

Hi, folks! Great topic!
Need some of your guru's help. As far as I understood, if we have i.e.
61. 00000000000000000000000000000000000000000000000013C96A3742F64906 - 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
62.                                                                                                                      - 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
63.                                                                                                                      - 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4
64.                                                                                                                      - 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
65. 000000000000000000000000000000000000000000000001a838b13505b26867  - 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
means that privat keys for #62, 63 & 64 will be somewhere between 13C96A3742F64906:1a838b13505b26867. Am I right?
If yes, how can I narrow the keyspace for #62 only? Even approximate range I believe will be ok fo try. Can a simple hex math be used in this case?
Sorry if its a noob question.

[jpyao78]

Hi, folks! Great topic!
Need some of your guru's help. As far as I understood, if we have i.e.
61. 00000000000000000000000000000000000000000000000013C96A3742F64906 - 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
62.                                                                                                                      - 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
63.                                                                                                                      - 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4
64.                                                                                                                      - 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
65. 000000000000000000000000000000000000000000000001a838b13505b26867  - 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
means that privat keys for #62, 63 & 64 will be somewhere between 13C96A3742F64906:1a838b13505b26867. Am I right?
If yes, how can I narrow the keyspace for #62 only? Even approximate range I believe will be ok fo try. Can a simple hex math be used in this case?
Sorry if its a noob question.

62   2000000000000000 - 3FFFFFFFFFFFFFFF
63   4000000000000000 - 7FFFFFFFFFFFFFFF
64   8000000000000000-  FFFFFFFFFFFFFFFF

[iparktur]

Hi, folks! Great topic!
Need some of your guru's help. As far as I understood, if we have i.e.
61. 00000000000000000000000000000000000000000000000013C96A3742F64906 - 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
62.                                                                                                                      - 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
63.                                                                                                                      - 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4
64.                                                                                                                      - 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
65. 000000000000000000000000000000000000000000000001a838b13505b26867  - 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
means that privat keys for #62, 63 & 64 will be somewhere between 13C96A3742F64906:1a838b13505b26867. Am I right?
If yes, how can I narrow the keyspace for #62 only? Even approximate range I believe will be ok fo try. Can a simple hex math be used in this case?
Sorry if its a noob question.

And who prevents you to narrow a range of search?
For search the private keys for address 62 is selected keyspace 2000000000000000 - 3FFFFFFFFFFFFFFF
In this space it is possible to find about 2305843009213693952 variants.
The project has started for a long time, therefore it is possible to assume, that about three quarters of addresses is checked up and among them no required.
I.e. it is necessary to you to check up 2305843009213693952:4 = 576460752303423488 variants
Can try to begin with 3800000000000001

- keyspace 3800000000000001:3FFFFFFFFFFFFFFF

If this quantity of variants 576460752303423488 you divide into speed of generation of keys of your computer that receive a rough operating time

Good luck!

[BurtW]

Hi, folks! Great topic!
Need some of your guru's help. As far as I understood, if we have i.e.
61. 00000000000000000000000000000000000000000000000013C96A3742F64906 - 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
62.                                                                                                                      - 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi
63.                                                                                                                      - 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4
64.                                                                                                                      - 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
65. 000000000000000000000000000000000000000000000001a838b13505b26867  - 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
means that privat keys for #62, 63 & 64 will be somewhere between 13C96A3742F64906:1a838b13505b26867. Am I right?
If yes, how can I narrow the keyspace for #62 only? Even approximate range I believe will be ok fo try. Can a simple hex math be used in this case?
Sorry if its a noob question.

And who prevents you to narrow a range of search?
For search the private keys for address 62 is selected keyspace 2000000000000000 - 3FFFFFFFFFFFFFFF
In this space it is possible to find about 2305843009213693952 variants.
The project has started for a long time, therefore it is possible to assume, that about three quarters of addresses is checked up and among them no required.
I.e. it is necessary to you to check up 2305843009213693952:4 = 576460752303423488 variants
Can try to begin with 3800000000000001

- keyspace 3800000000000001:3FFFFFFFFFFFFFFF

If this quantity of variants 576460752303423488 you divide into speed of generation of keys of your computer that receive a rough operating time

Good luck!

Since the entire search space for #62 is 2000000000000000 to 3FFFFFFFFFFFFFFF

If you search the last 1/4 of the space from 3800000000000001 to 3FFFFFFFFFFFFFFF you will have exactly a 25% chance of finding the key assuming nobody else with much faster hardware finds it first.

Good luck!  You are going to need it.

[Firebox]

Great! Thanks you all, mates, for a constructive answers!

...therefore it is possible to assume, that about three quarters of addresses is checked up and among them no required...

That exactly what I have thought and want to use with the profit. Means that, as the speed of my hardware is only ~25 MKey/s I have not enough of my life to check all that range and, asuming that three quarters of addresses have already been checked, I will better focuse only on the last quarter.

Good luck!  You are going to need it.

Thanks, bro! Soon I will share with you my reward