4 ms·

I think a compelling theory is that these addresses are generated by blockchain.info accidentally hashing uninitialised memory instead of random data. Uninitia

I think a compelling theory is that these addresses are generated by blockchain.info accidentally hashing uninitialised memory instead of random data. Uninitialised memory for blockchain.info would have a very high density of bitcoin-related data, and they also generate a large amount of keys. If they (sometimes?) end up hashing uninitialised memory instead of random data, there's every chance that they'd sometimes generate keys that are hashes of bitcoin-related data. It is admittedly unlikely that they'd be hashing data that is exactly the right length to be a bitcoin address or txid, but there could also be another bug which means they hash data that is nul-terminated rather than a fixed size. Both fitwear[1] (mentioned in the pastebin) and another user[2] have reported BTC inexplicably being transferred out of their blockchain.info wallets. The next question is, if this is really what's going on, how has it happened? Is it an honest bug or has it been planted deliberately (by either a hacker or an employee) with the intention of being able to steal funds from some proportion of blockchain.info addresses? There is also every possibility that fitwear and the person who wrote the pastebin article are the same person, and that it is maliciously designed to spread FUD about blockchain.info. We shouldn't jump to any conclusions without seeing a smoking gun. [1] https://www.reddit.com/r/Bitcoin/comments/7cw2uw/how_blockchaininfo_stole_65000_from_me/ https://www.reddit.com/r/Bitcoin/comments/7cw2uw/how_blockch... [2] https://www.reddit.com/r/Bitcoin/comments/7cx2tg/my_blockchaininfo_just_got_hacked/ https://www.reddit.com/r/Bitcoin/comments/7cx2tg/my_blockcha... EDIT: But wait a minute! Blockchain.info keys are generated client-side in javascript, to the best of my knowledge, so this shouldn't explain it at all...

tlrobinson 9y ago
If that is the case then it’s likely there are many private keys that are SHA256 hashes of very low entropy data.
- jstanley 9y ago
  I've generated addresses for all nul-terminated strings over 10 chars from a memory dump of my bitcoin node, and I'm scanning my blockchain to see if any of them have been used. So far I've found nothing.
  - StavrosK 9y ago
    What tools are you using to do that?
    - jstanley 9y ago
      It's all very adhoc. I used gdb to dump the bitcoind memory, I'm using https://github.com/matja/bitcoin-tool https://github.com/matja/bitcoin-tool to output human-readable addresses, I'm using (a modified version of) https://github.com/tenthirtyone/blocktools https://github.com/tenthirtyone/blocktools to parse the blockchain files, and some custom scripts to extract addresses from the scriptpubkeys and compare them against my list of addresses taken from the bitcoind memory.
      - StavrosK 9y ago
        I see, thanks. Wouldn't it be easier to communicate with bitcoind via the RPC interface?
        jstanley 9y ago
        Yes but that is orders of magnitude too slow. It would be fine if bitcoind had an address index, but it does not. I need to setup a bitcore node one of these days...
        StavrosK 9y ago
        Not only that, it doesn't even support looking up arbitrary addresses, I've just found. I'm looking for an alternate method.
        ryan-c 9y ago
        I extract them from bitcoind's rpc interface by dumping blocks, but i started that process years ago. It'd take several months to dump everything from scratch at this point.
xorcist 9y ago
A bit of historical background might be good. Blockchain.info has had several high impacting bugs over the years that has led to their users losing funds, like biased random numbers and re-used r values. Another bug of this type shouldn't be too surprising. Many people used to recommend against their wallet for these reasons, but on the other hand they haven't closed up shop and ran off yet, which makes them head and shoulders above the average hosted wallet provider. Bitcoin is a very special space.
rrobukef 9y ago
I don't see how transactions made in 2016 (2014 even?) are part of malicious FUD, they exist and are verifiable. You could assume malice, yet their hypothesis is somewhat testable: if it is uninitialised memory you should have private keys based on word-size shifts due to alignments. 2^64 hashes is somewhat doable. Truncation should be easier to test (in case it's null-terminated).

tlrobinson 9y ago

If that is the case then it’s likely there are many private keys that are SHA256 hashes of very low entropy data.

jstanley 9y ago
I've generated addresses for all nul-terminated strings over 10 chars from a memory dump of my bitcoin node, and I'm scanning my blockchain to see if any of them have been used. So far I've found nothing.
- StavrosK 9y ago
  What tools are you using to do that?
  - jstanley 9y ago
    It's all very adhoc. I used gdb to dump the bitcoind memory, I'm using https://github.com/matja/bitcoin-tool https://github.com/matja/bitcoin-tool to output human-readable addresses, I'm using (a modified version of) https://github.com/tenthirtyone/blocktools https://github.com/tenthirtyone/blocktools to parse the blockchain files, and some custom scripts to extract addresses from the scriptpubkeys and compare them against my list of addresses taken from the bitcoind memory.
    - StavrosK 9y ago
      I see, thanks. Wouldn't it be easier to communicate with bitcoind via the RPC interface?
      - jstanley 9y ago
        Yes but that is orders of magnitude too slow. It would be fine if bitcoind had an address index, but it does not. I need to setup a bitcore node one of these days...
        StavrosK 9y ago
        Not only that, it doesn't even support looking up arbitrary addresses, I've just found. I'm looking for an alternate method.
      - ryan-c 9y ago
        I extract them from bitcoind's rpc interface by dumping blocks, but i started that process years ago. It'd take several months to dump everything from scratch at this point.

xorcist 9y ago

A bit of historical background might be good. Blockchain.info has had several high impacting bugs over the years that has led to their users losing funds, like biased random numbers and re-used r values. Another bug of this type shouldn't be too surprising. Many people used to recommend against their wallet for these reasons, but on the other hand they haven't closed up shop and ran off yet, which makes them head and shoulders above the average hosted wallet provider. Bitcoin is a very special space.

rrobukef 9y ago

I don't see how transactions made in 2016 (2014 even?) are part of malicious FUD, they exist and are verifiable. You could assume malice, yet their hypothesis is somewhat testable: if it is uninitialised memory you should have private keys based on word-size shifts due to alignments. 2^64 hashes is somewhat doable. Truncation should be easier to test (in case it's null-terminated).