I have 13.33 GiB of such. Plain text. Nothing found. Ppl switched to random wallets.
Was the address in the OP in your list already? If so: did someone else beat you to it, or did you only find it later? 
Topic: Quick theft - page 2. (Read 1079 times)
While I clean up my databases from these bloated tables, I will export the list of words, I'll see if I can make some brainwallets out of that. It'll probably be a non-exhaustive list, and in any case, I think it would be better to make a list of brainwallets out of "password dumps".
I have 13.33 GiB of such. Plain text. Nothing found. Ppl switched to random wallets.
Those BTC from transactions to brain wallets were sent with a exact fee of 1.0 mBTC. That's ~21 USD.
Implies that the hackers are lazy and didn't think about getting traced.
While I clean up my databases from these bloated tables, I will export the list of words, I'll see if I can make some brainwallets out of that. It'll probably be a non-exhaustive list, and in any case, I think it would be better to make a list of brainwallets out of "password dumps".
Those BTC from transactions to brain wallets were sent with a exact fee of 1.0 mBTC. That's ~21 USD.
WTF, creating such a big list of brainwallets might be possible after all.
So inside my site database, I was doing some routine maintenance, when I stumbled upon a table that had 27K+ records inside it (most of them junk words and phrases/numbers). To my surprise, it turned out to be the table for search queries.
I don't get that much traffic, compared to say Bitcoin Magazine, but I am pretty sure that there is at least some user input there, in the sea of robot input with random combinations of words inside my posts.
So inside my site database, I was doing some routine maintenance, when I stumbled upon a table that had 27K+ records inside it (most of them junk words and phrases/numbers). To my surprise, it turned out to be the table for search queries.
I don't get that much traffic, compared to say Bitcoin Magazine, but I am pretty sure that there is at least some user input there, in the sea of robot input with random combinations of words inside my posts.
Have you ever heard about any brainwallet (or simply saying just a sha256 hashed phrase) which produces wrong private key? As upper boundary is not fff...fff, but a little less, do we know any example of sha256 result which "bigger" than allowed private key?
No, I haven't. To follow on from BlackHatCoiner's calculations above, there are this many outputs from SHA256 which generate an invalid private key:Code:
432,420,386,565,659,656,852,420,866,394,968,145,599
So you would need to test, on average, 1.34*1038 different strings to have a 50% chance of finding a single string whose SHA256 output falls outside of the valid range. That's 134 billion billion billion billion. So probably never going to happen. Although you could get round this near impossible scenario by simply coding your brain wallet generator to perform modulo n on any SHA256 output it generates. (Although technically speaking you will reduce your entropy since the first x number of keys are now twice as likely to be generated than any other key, with x being equal to the number I gave above.)
Have you ever heard about any brainwallet (or simply saying just a sha256 hashed phrase) which produces wrong private key? As upper boundary is not fff...fff, but a little less, do we know any example of sha256 result which "bigger" than allowed private key?
Let's take the numbers. There is exactly this number of valid private keys:Code:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
(115792089237316195423570985008687907852837564279074904382605163141518161494336)
(115792089237316195423570985008687907852837564279074904382605163141518161494336)
And this number of possible SHA256 outputs:
Code:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
(115792089237316195423570985008687907853269984665640564039457584007913129639935)
(115792089237316195423570985008687907853269984665640564039457584007913129639935)
Dividing the first number by the second, and multiplying by 100, gives about 99.9999999999999999999999999999999999996%.
There's about 0.00000000000000000000000000000000000037% (!!!) chance to find a hash that can't be a valid private key.
Fact: The Bitcoin network uses so much computational power that has dropped the target to:
Code:
00000000000000000009FD7E0000000000000000000000000000000000000000
(956871428990014096800480126306339386063092842672160768)
(956871428990014096800480126306339386063092842672160768)
This means there's a 0.0000000000000000000008% chance to solve the next block. Therefore, it's about 2 quintillion times more probable to solve the next block than to find a hash that isn't a valid Bitcoin private key. (Although, it's about 1 quintillion, because in mining you hash the block header twice, in comparison with brain wallets)
Edit: actually, the total SHA256 outputs are 2^256 (not 2^256-1), I forgot the value 0. Anyway, same results.
It could be more efficient if you utilize walletnotify which automatically execute Bash script when you receive Bitcoin.
Will that be fast enough, compared the the (no doubt) specialized software used by brainwallet crackers? I think the confusion here is that it seems pbies is talking about taking any arbitrary string, passing it through SHA256 (or some other function) to create a (usually) valid private key in hex, and then encoding that as a WIF. In this case he is correct in saying that there are many different strings from outside the range given which when first SHA256ed will result in the same private key (although it is almost certainly impossible to find such a collision).
Have you ever heard about any brainwallet (or simply saying just a sha256 hashed phrase) which produces wrong private key? As upper boundary is not fff...fff, but a little less, do we know any example of sha256 result which "bigger" than allowed private key?
I think the confusion here is that it seems pbies is talking about taking any arbitrary string, passing it through SHA256 (or some other function) to create a (usually) valid private key in hex, and then encoding that as a WIF. In this case he is correct in saying that there are many different strings from outside the range given which when first SHA256ed will result in the same private key (although it is almost certainly impossible to find such a collision).
However, the point I made above is not incorrect: There is a 1-to-1 relationship between valid hex private keys and WIFs. All you are doing with a WIF is changing the encoding. Just as there is exactly one unique binary representation of each decimal number, there is exactly one unique WIF of each hex private key.
However, the point I made above is not incorrect: There is a 1-to-1 relationship between valid hex private keys and WIFs. All you are doing with a WIF is changing the encoding. Just as there is exactly one unique binary representation of each decimal number, there is exactly one unique WIF of each hex private key.
Valid WIF does not need to come from hex number in a specific range. It can even have less than 1/3 characters of original length of WIFs.
Do you contradict yourself here, acknowledging the "original" length of a WIF private key is not what you say it is?Let's make some statements to clear up the situation:
- A WIF private key is a series of bytes encoded in base58. Specifically, it's a version byte (0x80 for mainnet) followed by the private key (in hex), followed by a compression byte (0x01 for compressed, empty for uncompressed) and finally, followed by a checksum.
- Compressed WIF private keys are 52 characters long and start with either a "L" or a "K". Uncompressed WIF private keys are 51 characters long and start with "5".
- You can encode any series of bytes to WIF (version_byte + number + compression_byte + checksum), but this won't make it a valid Bitcoin private key. To do so, the number has to be between [1, n-1] where n the prime order of the generator point of secp256k1.
- Each number gives a unique WIF private key. And that's true for beyond that range.
- If you take a phrase and convert it to WIF, it is highly unlikely to be a valid Bitcoin private key.
Valid WIF does not need to come from hex number in a specific range.
WIF is just the string encoding and it doesn't matter at all. The numerical value that the WIF represents is the important part. If it is not in range then the key is invalid so you either have to reject it as invalid or "change" it to become valid, one way is to reduce it modulo curve order to make it valid. But the original value was still invalid... No, it is not invalid as long as can be converted to WIF. We are talking about different things here.
It is. Putting a number outside the range I have given through the same steps you would use to generate a WIF private key does not make it a valid private key.And every string every length can be converted to WIF. Eventually it will give the same WIF as other string.
No, it won't. The process for generating a WIF from a hex key simply involves adding a network byte, an optional compression byte, a checksum, and then converting the whole thing from hex to Base58. There is a 1-to-1 relationship between private keys in hex and private keys in WIF. You will not find two different hex keys which generate the same WIF string.You are totally wrong.
Valid WIF does not need to come from hex number in a specific range. It can even have less than 1/3 characters of original length of WIFs.
Yes, it will give the same result, example: you have string which you convert to WIF and 64-digits hex - both will give the same WIF. The problem here is to compute them to give the same WIF.
If I go outside your range [1,...] with hex I can create such hex that will give the same WIF as in your range. Because the range is full space.
If I give some phrases and convert them to WIF I can still receive one of the WIFs created from hex within your range.
No, it is not invalid as long as can be converted to WIF. We are talking about different things here.
It is. Putting a number outside the range I have given through the same steps you would use to generate a WIF private key does not make it a valid private key.And every string every length can be converted to WIF. Eventually it will give the same WIF as other string.
No, it won't. The process for generating a WIF from a hex key simply involves adding a network byte, an optional compression byte, a checksum, and then converting the whole thing from hex to Base58. There is a 1-to-1 relationship between private keys in hex and private keys in WIF. You will not find two different hex keys which generate the same WIF string. ...
This is a brilliant post!
Ready solution!
But...
The transactions are taken by the thieves immediately mostly (as I have seen) so the second transaction is made in the same block.
That means the thieves operate on protocol level, not bitcoin-cli. When you get the balance the BTC is already gone!
And that means there is very little chance to get BTC as when there is input, exactly in the same 5 seconds is made output transaction.
I was thinking about the full bashscript, and would be something like this:
And most of people would think to put this on a while, but i would use the yes command for this task
Code:
balance=$(./bitcoin-cli getinfo | grep balance | cut -d " " -f7 | sed 's/,//')-0.0001 | bc); ./bitcoin-cli sendtoaddress "1MyColdWallet..." $balance
And most of people would think to put this on a while, but i would use the yes command for this task
Code:
yes $(my script)
Yeah, something like that, but the commands should be "inline".
I mean to say, each and every call to the JSON-RPC queues an additional task. This is an unacceptable latency when you have thousands of addresses to check. So the JSON-RPC layer has to be skipped completely once the loop is entered.
@PawGo
I'm not sure implementing this on a protocol level would be a good idea, this is tantamount to introducing an address blacklisting feature. Currently, there is no way for the protocol to know which addresses are cracked (i.e. stolen) or not, so such a feature would be abused by governments to enforce arbitrary closing of addresses i.e. asset freeze for any user.
One of these days, somebody should make a database. With a few hundred gigabytes of memory. It should have all of the common brainwallet private keys and legacy addresses inside it.
Then, you make a "lite" version of Bitcoin Core with only methods for address check balance and make [RBF] transaction. So that Core loads faster.
Now, run a loop, checking each and every address for a balance, then you create a transaction that burns the ENTIRE balance in fees. Attackers won't be able to bump this transaction with their own, because nearly the entire balance has already been allocated to miners anyway.
Bitcoin - even the stolen coins contribute to the network security. (Denial-of-service for theives.)
Then, you make a "lite" version of Bitcoin Core with only methods for address check balance and make [RBF] transaction. So that Core loads faster.
Now, run a loop, checking each and every address for a balance, then you create a transaction that burns the ENTIRE balance in fees. Attackers won't be able to bump this transaction with their own, because nearly the entire balance has already been allocated to miners anyway.
Bitcoin - even the stolen coins contribute to the network security. (Denial-of-service for theives.)
You don't have to check the address balance, you could check the wallet balance...
Code:
./bitcoin-cli getinfo | grep balance
The idea is to be faster than the Theft, so, if we can skip the steps of building the transaction maybe we can spend the coins faster.
Code:
./bitcoin-cli sendtoaddress "1MyColdWallet..." $balance
I was thinking about the full bashscript, and would be something like this:
Code:
balance=$(./bitcoin-cli getinfo | grep balance | cut -d " " -f7 | sed 's/,//')-0.0001 | bc); ./bitcoin-cli sendtoaddress "1MyColdWallet..." $balance
And most of people would think to put this on a while, but i would use the yes command for this task
Code:
yes $(my script)
Any number outside this range is invalid. This is not an arbitrary limit; it is inherent to the secp256k1 curve which bitcoin uses. n is the prime order of the generator point G, with the largest valid private key being n - 1. Trying to use a private key of zero will output the point at infinity on the curve.
No, it is not invalid as long as can be converted to WIF. We are talking about different things here.
And every string every length can be converted to WIF. Eventually it will give the same WIF as other string.
You are talking about soft limit, that all the given space (000...-fff...) would be used by this range. So there will be no more different keys produced.
The hard limit is bits in Base58check for WIF. But even then you can use shorter or longer WIF to/from which you can send BTC.
Now, run a loop, checking each and every address for a balance, then you create a transaction that burns the ENTIRE balance in fees. Attackers won't be able to bump this transaction with their own, because nearly the entire balance has already been allocated to miners anyway.
Bitcoin - even the stolen coins contribute to the network security. (Denial-of-service for theives.)
Bitcoin - even the stolen coins contribute to the network security. (Denial-of-service for theives.)
That's very interesting concept. It may be extended into "management of address", where owner signs kind of message which "blocks" given address (we may say it would be irreversible) and any output sent would be burn in the way you described (or any other). Or sends back. To have it working flawlessly, it had to be implemented in every node, not to have 'centralized' database. Which means there would be a way to mark address as 'closed' (like closed account in bank).
That would allow for example "addresses managers" (like exchanges, shops, casinos etc, any companies which produces deposit addresses for customers) to block used addresses of given/past clients.
Now, run a loop, checking each and every address for a balance, then you create a transaction that burns the ENTIRE balance in fees. Attackers won't be able to bump this transaction with their own, because nearly the entire balance has already been allocated to miners anyway.
Don't loop every address naively, the thief would get lots of time advantage to broadcast non-RBF transaction. I don't know if it's best option, but bloom filter could help. Also run it on few different region to handle transaction propagation delay.
Jump to: