Bitcoin puzzle transaction ~32 BTC prize to who solves it

[netlakes]

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!
I thought this whole riddle was about 32 BTC?
Btw I am not into this cracking kinda stuff enough to participate into this. Just clicked through the posted addresses in this thread and found this HUGE wallet which a user above me posted.
 
Insane.  
I guess if this key is crackable, the reward is so insanely high because it is nearly impossible to crack.
I'd love to know the guy knowing the result to this riddle and get to know how to solve this lol. That'd be awesome.
Like "Hey dude you heard about this riddle I made with Bitcoin? You aren't into BTC anyway, so here's how to solve it...."
"Oh that sounds fun! No worries I won't participate in solving it. *Opens Bitcoin wallet and imports priv key*"  
 
By the way: Ever thought of where this huge stack of Coins might come from? Could the source be some illegal hacking stuff offering the coins for grabs via a riddle because they can't sell them anyway? (IF it is related to any riddle at all.) Could it be an exchange wallet not related to a riddle at all? Would be really interested in seeing some blockchain analysis here to get to know who owns/owned these coins and how they have been acquired. 2011 is a long long time ago.  
Or did Mark Karpeles forgot a paper wallet sitting in between his couch again?

183hmJGRuTEi2YDCWy5iozY8rZtFwVgahM;8.59473e+12

That one must be an exchange cold wallet. Transaction happened within the last 12 months also. I bet it's Coinbase. Or Bitfinex.
 
Btw
 

[...]e+12

not familiar with these kind of numbers that begin with "e", what does it mean?
I'm stupid I know. I'm also not very good at math. Would be happy to have explained why you wrote those "e"-numbers behind the addresses. Thanks!

hi!!

 Prism switches to scientific notation when the values are very larger or very small. For example:

2.3e-5, means 2.3 times ten to the minus five power, or 0.000023
4.5e6 means 4.5 times ten to the sixth power, or 4500000 which is the same as 4,500,000
This is a standard notation used by many computer programs including Excel. Entering a value in this form is not the same as entering the logarithm of a number. This is simply a shortcut way to enter very large values, or tiny fractions, without using logarithms

Note that in other contexts, e = 2.71828183, the base of natural logarithms. But when used in displaying large or small numbers, e means "times ten to the power of...".

[1714026017]

1714026017

[1714026017]

1714026017

[racminer]

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!
I thought this whole riddle was about 32 BTC?
Btw I am not into this cracking kinda stuff enough to participate into this. Just clicked through the posted addresses in this thread and found this HUGE wallet which a user above me posted.
 
Insane.  
I guess if this key is crackable, the reward is so insanely high because it is nearly impossible to crack.
I'd love to know the guy knowing the result to this riddle and get to know how to solve this lol. That'd be awesome.
Like "Hey dude you heard about this riddle I made with Bitcoin? You aren't into BTC anyway, so here's how to solve it...."
"Oh that sounds fun! No worries I won't participate in solving it. *Opens Bitcoin wallet and imports priv key*"  
 
By the way: Ever thought of where this huge stack of Coins might come from? Could the source be some illegal hacking stuff offering the coins for grabs via a riddle because they can't sell them anyway? (IF it is related to any riddle at all.) Could it be an exchange wallet not related to a riddle at all? Would be really interested in seeing some blockchain analysis here to get to know who owns/owned these coins and how they have been acquired. 2011 is a long long time ago.  
Or did Mark Karpeles forgot a paper wallet sitting in between his couch again?

183hmJGRuTEi2YDCWy5iozY8rZtFwVgahM;8.59473e+12

That one must be an exchange cold wallet. Transaction happened within the last 12 months also. I bet it's Coinbase. Or Bitfinex.
 
Btw
 

[...]e+12

not familiar with these kind of numbers that begin with "e", what does it mean?
I'm stupid I know. I'm also not very good at math. Would be happy to have explained why you wrote those "e"-numbers behind the addresses. Thanks!

edit I just went through the BTC Top 100 Rich list and found some that had over 1million BTC transacted. That's heavy.
Also sorry for pushing this thread slightly Off Topic.

1e+12  is just 10**12   same as 1 000 000 000 000   (twelve zeros) 
1 BTC = 1e+8 satoshi = 100 000 000   (eight zeros)
so
1e+12 = 10 000 BTC

this wallet 183hmJGRuTEi2YDCWy5iozY8rZtFwVgahM holds 8.59473e+12 = 85 947 BTC
This wallet has no withdrawal.
it was created on this date 2018-07-01 and received all this amount from 1KAt6STtisWMMVo5XGdos9P7DBNNsFfjx7

[holy_ship]

One target or 45000 target won't change much.

So incompetent opinion.
1 compressed address makes 250MK
50k compressed+uncompressed 80MK
(on gf1070)

that's 3.1 times difference.

Never tried it, because most of non empty BTC addresses are compressed

Another BS  

This trick will increase your likelihood in finding the key as times increases

3rd BS.

[fecell]

hhh
this guy "1LuckyTJHcLLTnmeDZFbc1E18ZW87k36tk" has been hitting on this one https://www.blockchain.com/fr/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF
I guess he is getting desperate now 

you mean this guy - https://luckyb.it
I think somebody enter #61 address at this site as own, and small ammount was sended as reward to it.

[racminer]

One target or 45000 target won't change much.

So incompetent opinion.
1 compressed address makes 250MK
50k compressed+uncompressed 80MK
(on gf1070)

that's 3.1 times difference.

Never tried it, because most of non empty BTC addresses are compressed

Another BS  

This trick will increase your likelihood in finding the key as times increases

3rd BS.

Thank you for you very competent comments.

Competence has nothing to do with experience.

You claimed:"
1 compressed address makes 250MK
50k compressed+uncompressed 80MK
(on gf1070) "
Is it by competence that you are saying this or by experience.
I suppose you are competent enough to know that AMD and NVIDIA GPU are not the same as far as performance and scaling.
I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

For my other comments, maybe I did not express myself well (my native language is not English)  
Instead of saying that what I say is BS ...

TEACH US SOMETHING !

[zielar]

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

[racminer]

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

Good points.


Waw!!! 288 000 000 000 Mkey/s ... 

Maybe you mean 288 000 000 000 key/s

[stalker00075]

FUCK you make me nervously smoking aside with my 350Mkey/s

[brainless]

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

[yoloyet]

is this still on going? this might offer some hours of having fun

[netlakes]

hello guys, today this wallet appeared 1JMT8uyrnVAvkhiexbTL9dyyMwTqjKygU9
in my search

take a look at the transactions, can anyone explain what this is?

[racminer]

hello guys, today this wallet appeared 1JMT8uyrnVAvkhiexbTL9dyyMwTqjKygU9
in my search

take a look at the transactions, can anyone explain what this is?

https://bitcoin.stackexchange.com/questions/64504/what-does-unable-to-decode-output-address-mean

[pikachunakapika]

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

You are getting false positives which is normal with this version of the code and your big hashtable.
Read recent posts of arulbero in this thread to understand why.
Simplified said there are collisions in the hashtable.

Code:

typedef struct hashtable_entry {
    uint32_t x;
    uint32_t exponent;
} hashtable_entry;

Here uint32_t x; is to small too prevent collisions.
If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive.

[brainless]

There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.

And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist

2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts

You are getting false positives which is normal with this version of the code and your big hashtable.
Read recent posts of arulbero in this thread to understand why.
Simplified said there are collisions in the hashtable.

Code:

typedef struct hashtable_entry {
    uint32_t x;
    uint32_t exponent;
} hashtable_entry;

Here uint32_t x; is to small too prevent collisions.
If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive.

i have tested it with higher values too, need to of optimization
i created issues inside your pull of bitcrack and modified for random, check that too

[pikachunakapika]

i have tested it with higher values too, need to of optimization
i created issues inside your pull of bitcrack and modified for random, check that too

Thank your for testing!

[holy_ship]

Thank you for you very competent comments.

Welcome.

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

[racminer]

Thank you for you very competent comments.

Welcome.

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

[netlakes]

Thank you for you very competent comments.

Welcome.

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

my rx480 4gb config:

-c  -b 72  -t 256 -p 2048   

5,000,000 addresses = 85Mkey/s

-c -u  -b 72  -t 256 -p 2048   

5,000,000 addresses = 42Mkey/s

[racminer]

Thank you for you very competent comments.

Welcome.

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

8Gb Rx480

-b 72 -t 256 -p 2048

Most abandoned wallets are uncompressed .. you are certainly right.

my rx480 4gb config:

-c  -b 72  -t 256 -p 2048   

5,000,000 addresses = 85Mkey/s

-c -u  -b 72  -t 256 -p 2048   

5,000,000 addresses = 42Mkey/s

Indeed, that's what I have.
holy_ship does not seem to agree.

[zielar]

Thank you for you very competent comments.

Welcome.

I claim that an Rx480 does 105MHkey/s on 01 target and 85 MHkey/s on 2,749,473 targets (compressed only)... draw you own conclusions. This is no BS.

1. Most abandoned wallets are uncompressed.
2. If speed with one address is almost the same as with 2.7M, then you haven't found right values for -b A -t B -p C
No other options.

I am not fully accept that... B is block's number. in many apps you can read CU value (compute units) which is -b the best value.