Thoughts on this private key stealing mystery

[Bountyl]

Tell me please. How did you automate this process? What programs did you use? It is also necessary to copy all hashes, check their addresses...

[1714889171]

1714889171

[Induane]

A few folk asked me if the code for iterating wallets and checking them was available anywhere:

I have it up on github; it has a few other interesting features now like anagrams. It's older code though, python2.7 only. I haven't updated it to Python3.x yet.

https://github.com/induane/walleter

[btc-room101]

Wow  

Amazing discovery of a amazing coup. The guy who made this and the guy which discovered it are pure genious.

I am really excited to find out in which priv key generation code this thing is implemented.

Amazing, if any of it were true, Upon reviewing this article, I took to myself to spend 1/2 hour and run some of these things, I have a database of 5 million BTC addresses, and every public-key ever used, both hashed and open, and I ran the addresses though the system, I found less than 1,000 addresses have been used as 'seeds', and I found of that only 'one' had ever had a transaction, ... Not VERY INTERESTING .....
IMHO this article is a sci-fi fairy-tale that can be told to bitcoin wannabe's and their boyfriends.

I am afraid arguing "against this" is like arguing against the theory of God.

You cannot prove your point.

There are an infinite number of possible variations on the embedded hints and seeds and secrets.

For example, assume not that "seed" is embedded and with "seed you can discover the private key.

Now consider k=numeric value(seed)+c

Where c is a constant.

Have fun....

Well then goes to show you didn't actually do it yourself your 'god test' is just a mind-test that you decided on your own.
Let's take two test's, one is run through all hashes in the black-chain links and try them as 'used addresses', then hash all the rainbow tables of all human made words 80gb, you will find 1,000's of used-addresses, in the rainbow, and zero in the hash-links.

Why is this? Because of determinism, and entropy, but mostly entropy the rainbow tables is has low entropy, but the links of all blocks is extreme high entropy.

The argument here  was high-entropy could lead to high-value keys, and no it doesn't; on the other hand low-entropy will lead you to +5,000 used-addresses, but sadly all the priv-keys were swept years ago.

Lastly, keep god out of this, he already knows you don't know what you think you know.

[iwuzhere]

FYI: One of the experiments the OP explained all that time ago is STILL happening to this day.  I created my own database and saw these three transactions fly by just in the last few days:

1Kfayq6DeA5SztT79nmX4LFwG2bWmZwYKE derived from txid 40f087dd977495465c75f433772d4f7d07084d3933c4a444198403935f40ceea
19PBWUGcTt4QDi4sCtaogBsn4q58EXKUE8 derived from txid 1d613bce91a4087d78d671442710367350d24e01949d880a81c4a97edfa92a99
1Gs3BeD1TdB85aSy8xvyPegQYaPJUMo2so derived from txid 27c0e69e629658c264da83391b5ab2ccee10ecd357d4da2b4b0e52cd9d7faa9f

(That last one is for 0.11959621 BTC which is over $3k USD at today's prices)

What's amazing is that you can have the private key for those addresses MONTHS in advance of it being used.  Those txids are sometimes recorded in the blockchain way in the past.  To be clear, this isn't an exploit.  I think there is some system out there that possibly isn't initializing memory (or something).  So they seem to be creating private keys based on the occasional information found in the blockchain, probably because they are processing transactions and that's what happens to be in memory at the time.  But you'd think that after all this time, someone would notice BTC going missing.   They get swept instantly though, so good luck trying to capture them.

[HCP]

Incredible to think this is still going on today... some 3.5 years after it was initially highlighted by the OP.

I wonder if something is using "random" chunks of data from the actual blockchain data, which is why occasionally we see addresses, txids and blockhashes being used. It's certainly an interesting mystery.

[NotATether]

Incredible to think this is still going on today... some 3.5 years after it was initially highlighted by the OP.

I wonder if something is using "random" chunks of data from the actual blockchain data, which is why occasionally we see addresses, txids and blockhashes being used. It's certainly an interesting mystery.

It's largely because competent wallets would never make a private key by SHA256ing something, instead of generating the random bytes properly. This looks largely restricted to ancient exchanges, web wallets and mining pools running custom software for which they can't be bothered to change it to something safer.

And I wonder if they have any bug bounties for these kinds of security vulnerabilities considering that there was a lot of time (years!) for people to ID these addresses to the major service using them.

[Timelord2067]

What's amazing is that you can have the private key for those addresses MONTHS in advance of it being used.  Those txids are sometimes recorded in the blockchain way in the past.  To be clear, this isn't an exploit.  I think there is some system out there that possibly isn't initializing memory (or something).  So they seem to be creating private keys based on the occasional information found in the blockchain, probably because they are processing transactions and that's what happens to be in memory at the time.  But you'd think that after all this time, someone would notice BTC going missing.   They get swept instantly though, so good luck trying to capture them.

Are there any instances of this also happening on Forked bitcoin block-chains?  If the issue is occurring with Bitcoin, then perhaps it has been ported to other flavours of Bitcoin that have come after it that have been spun out of thin air and are presumably based on the original code.  ??

[cryptowarz88]

Other blockchains outside for bitcoin are also subject to this. I've been able to find some private keys for rippled wallets generating the private key from random and random string generator.