7 ms·
As an experiment I sent 0.0005 BTC to the address corresponding to the private key in the documentation (L1uyy5qTuGrVXrmrsvHWHgVzW9kKdrp27wBC7Vs6nZDTF2BRUVwy ->
by benmanns 12y ago
As an experiment I sent 0.0005 BTC to the address corresponding to the private key in the documentation (L1uyy5qTuGrVXrmrsvHWHgVzW9kKdrp27wBC7Vs6nZDTF2BRUVwy -> 17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV). Within seconds someone had already transferred it out to 1ENnzep2ivWYqXjAodTueiZscT6kunAyYs.
[address] https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX49VXuaV https://blockchain.info/address/17XBj6iFEsf8kzDMGQk5ghZipxX4...
[thief?] https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6kunAyYs https://blockchain.info/address/1ENnzep2ivWYqXjAodTueiZscT6k...
- benmanns 12y agoWow! Tried it with the other private key[0] and the same thing happened. Upon some searching it looks like the recipient belongs to a Russian named amaclin on the Bitcoin forum[1] who has a script running to empty published private keys as soon as a transaction hits the network. [0] https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHVCvRxkF https://blockchain.info/address/14bZ7YWde4KdRb5YN7GYkToz3EHV... [1] https://bitcointalk.org/index.php?topic=655092.msg7358079#msg7358079 https://bitcointalk.org/index.php?topic=655092.msg7358079#ms...
- amaclin 12y agothank you
- amaclin 12y agoHelp me please to understand the following transactions: https://blockchain.info/address/1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj https://blockchain.info/address/1HcBw7XNKm6NoVJ4s5sSZPL9JGeB... (look from bottom to top) Send 0.0001 to 1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj , then spend change to 1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj, then spend change to 1HcBw7XNKm6NoVJ4s5sSZPL9JGeB8a9STj... etc 9 times. And the last transaction is sending 9 utxos to 1Q76cQw9Rmw4TathPdYdR34GXSGKZKnLQy - the address of private key which was published earlier on page https://www.npmjs.org/package/simplebtc https://www.npmjs.org/package/simplebtc wtf?
- ogig 12y agoWhat was the intention of your experiment? I find the outcome interesting but don't get why would you do that on a first place.
- benmanns 12y agoThe first thing I did when seeing private keys in the documentation was to check if they had anything in them. When they came up empty, I figured someone else would come along and do the same thing. I suppose my experiment was to see how quickly it would happen.
- sneak 12y agoYou can also send coins to any brainwallet (using the simple sha256(sha256(input))) that is under 10 characters or so and see the coins immediately get swept. Someone's obviously monitoring the blockchain for new transactions to known keys for sweeping.
- ejr 12y agoI wouldn't be surprised if there are swarms of bots doing this job already. In effect, they're like the stock market robo-traders.
- ChrisClark 12y agoDefinitely, but I'd say the Bitcoin market trading bots are more like the stock market trading bots. ;)
- nly 12y agoWhile I'm not aware of such a naive brainwallet algorithm being used, it's fairly unlikely that all <= 10 character SHA or double-SHA hashes are being monitored. While the number crunching hardware to generate the rainbow table exists, and it could be done overnight, the storage required of such a beast would be pretty immense. 62^10 (case insensitive alphanumeric) * 16 byte hashes = 13.4 exabytes of storage. This why rainbow tables are pretty much irrelevant these days for anything using password-derived keys.
- imaginenore 12y agoRainbow tables do NOT store every possible combination. http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Rainbow_table
- Retric 12y agoCase insensitive alphanumeric is 36 (26+10) case sensitive alphanumeric is 62 (26 + 26 +10). Second you don't need to store all the data. Your solution to just stores the hashes and uses their position to calculate the key. Saving 10 bytes out of (10byte key+16byte hash.) However, you would then need to check every hash in order which is slow at look up time. Next thought is sorting the hashes so lookups are fast. Notice that the first byte is repeated frequently so break the list up into 256 lists and you don't need to save the first byte. Continuing this idea you end up a tree data structure: http://en.wikipedia.org/wiki/Radix_tree http://en.wikipedia.org/wiki/Radix_tree. Problem is it's still a lot of data. However, look up is now so fast you don't need to full key any more store say 8 bytes and test the next 2. Wait, do we really need ASCII key values or just a number to reduce the search space 2 bytes cuts things from 1 day to (1/256^2) or ~1second. But wait, we don't need to store the full hash just enough that false positives are low. A 4 byte hash + 3 bytes in a radix tree gives means ~1 in 256^4th hashes match and you spend 1/200th of a second looking at each match, which seems vary reasonable. Unfortunately even at ~1/4 the storage it's still to much space. Continuing this idea of the trade off between storage and speed, you might end up with a rainbow table. http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Rainbow_table
- httpagent 12y agoThere's an interesting thread here of a guy called /u/btcrobinhood who monitors these wallets and attempts to return the funds to the original holder. meta: http://www.reddit.com/r/bestof/comments/296zn4/ http://www.reddit.com/r/bestof/comments/296zn4/ original context: http://np.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_gone_pc_not_compromised/cihzwdc?context=7 http://np.reddit.com/r/Bitcoin/comments/295las/35_of_my_btc_...