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.)
Topic: Quick theft - page 3. (Read 1079 times)
Given 00..02 key is 64-digits hexadecimal representation of 32 bytes, which can be converted to WIF by Base58Encode_check (a function from Python, just for example). This goes: 1. current hexadecimal -> 2. bytes -> 3. add 0x80 at front -> 4. add checksum by sha256 (twice?) -> 5. base58encode it
The whole point of a WIF private key is simply to encode mainnet/testnet, compressed/uncompressed, and to include a checksum. If you import a WIF private key to your wallet, your wallet converts it back to the raw hex or binary before plugging it in to the elliptic curve multiplication equation to calculate your public key.If you already have a raw private key in binary or hex, then you do not need to SHA256 it at any point to calculate the public key. You only need to use SHA256 to turn in to a WIF private key.
I would name raw private key to be binary (with no direct ASCII representation on screen/web) and consist of any number of bytes, even zero, up to reasonable quantity, which also would go through sha256 and base58encode to make WIF from it.
This is simply not correct. A private key must fall between the following hex numbers (inclusive):Code:
0000000000000000000000000000000000000000000000000000000000000001
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
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.
The private key 000....0002 I have given above is a raw private key. It is not passed through SHA256 as in the case of a brain wallet. It is simply used as-is, and multiplied by the generator point G to find the public key.
I don't agree.
Given 00..02 key is 64-digits hexadecimal representation of 32 bytes, which can be converted to WIF by Base58Encode_check (a function from Python, just for example). This goes: 1. current hexadecimal -> 2. bytes -> 3. add 0x80 at front -> 4. add checksum by sha256 (twice?) -> 5. base58encode it
I would name raw private key to be binary (with no direct ASCII representation on screen/web) and consist of any number of bytes, even zero, up to reasonable quantity, which also would go through sha256 and base58encode to make WIF from it.
It's from the binary raw private key which is SHA256ed, made readable for us meatbags by the hex representation of the private key.
The private key 000....0002 I have given above is a raw private key. It is not passed through SHA256 as in the case of a brain wallet. It is simply used as-is, and multiplied by the generator point G to find the public key.Fix: [0, ...
No. 0 is not a valid private key.
Thanks for explanation.
I can see also that there is difference in Base58 (Python):
1. Base58encode which just turns bytes/text to base58 string
2. b58encode_check which first sha256 the given data and later converts to base58 string (with checksum, which verifies correctness of private key)
EDIT:
Fix: [0, ...
Back to Python: so there are 32 bytes, which give 64 hex digits, and this is what I am converting to WIF. Surely no CR/LF is allowed at the end of the hex number.
I can see also that there is difference in Base58 (Python):
1. Base58encode which just turns bytes/text to base58 string
2. b58encode_check which first sha256 the given data and later converts to base58 string (with checksum, which verifies correctness of private key)
EDIT:
It's the number in hex. A private key can be any decimal number in the range of [1, 115792089237316195423570985008687907852837564279074904382605163141518161494336].
Fix: [0, ...
Back to Python: so there are 32 bytes, which give 64 hex digits, and this is what I am converting to WIF. Surely no CR/LF is allowed at the end of the hex number.
Tell me, the code you have written here with 000...002 - is it ASCII encoded string (byte 48, byte 48, ... byte 50) that is SHA256ed later Base58Check, or is it hex number so mostly binary bytes - many zeroes and one 2 (whole divided by 2 because of hex 00-ff = two digits per byte)?
It's the number in hex. A private key can be any decimal number in the range of [1, 115792089237316195423570985008687907852837564279074904382605163141518161494336].I know public address and private key (WIF) but not these simple brain wallets...
By public address you perhaps mean public key? Which part of brain wallets is difficult to understand? Numbers (or private keys in this context) can have multiple representations. Hexadecimal, decimal, ASCII, Base58, Base64 etc. Function SHA256 takes binaries as input, and prints the hash. So, Loyce's "2" is read as "10" by the computer. Representation is synonym to translation of a message. All it matters is to have your message translated to binary. 
That's a different address. The address 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m is generated from the private key "2", or more accurately:
Tell me, the code you have written here with 000...002 - is it ASCII encoded string (byte 48, byte 48, ... byte 50) that is SHA256ed later Base58Check, or is it hex number so mostly binary bytes - many zeroes and one 2 (whole divided by 2 because of hex 00-ff = two digits per byte)?Code:
0000000000000000000000000000000000000000000000000000000000000002
I always have problem understanding the differences with these simple keys. I know public address and private key (WIF) but not these simple brain wallets...
It's from the binary raw private key which is SHA256ed, made readable for us meatbags by the hex representation of the private key. You can check this on https://bitaddress.org in the section Wallet Details. Enter "0000000000000000000000000000000000000000000000000000000000000002" without quotation marks in the Enter Private Key field and click on button View Details...
Brainwallets usually take the ASCII string representation of some secret and SHA256("secret brainwallet string of chars"), see also the Brain Wallet section on https://bitaddress.org. But bitaddress.org doesn't accept too short brainwallet secret strings, though (needs little tweak in the Javascript code to accept them).
21 mBTC:
That's a different address. The address 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m is generated from the private key "2", or more accurately:Code:
0000000000000000000000000000000000000000000000000000000000000002
Exactly the same explanation as I gave above for brain wallets though. Malicious entities are constantly watching all addresses generated from such "special" private keys with scripts ready to sweep any coins in seconds.
You are right.
Tell me, the code you have written here with 000...002 - is it ASCII encoded string (byte 48, byte 48, ... byte 50) that is SHA256ed later Base58Check, or is it hex number so mostly binary bytes - many zeroes and one 2 (whole divided by 2 because of hex 00-ff = two digits per byte)?
I always have problem understanding the differences with these simple keys. I know public address and private key (WIF) but not these simple brain wallets...
21 mBTC:
That's a different address. The address 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m is generated from the private key "2", or more accurately:Code:
0000000000000000000000000000000000000000000000000000000000000002
Exactly the same explanation as I gave above for brain wallets though. Malicious entities are constantly watching all addresses generated from such "special" private keys with scripts ready to sweep any coins in seconds.
21 mBTC:
in: a149d13dd2dcc44366b447de2fc8c15ed7289e93ab3c72a94e94bf80be9b3584
out: 7b3fd1cf0d8c2f781fe0a25ad98538491ee4b9e827e83b5ac1e243ef2b670d91
in: a149d13dd2dcc44366b447de2fc8c15ed7289e93ab3c72a94e94bf80be9b3584
out: 7b3fd1cf0d8c2f781fe0a25ad98538491ee4b9e827e83b5ac1e243ef2b670d91
There must be fierce competition to be the first! They usually use very high transaction fees to steal funds.
I remember looking in to such a brain wallet address several years ago, and finding three different transactions being broadcast trying to sweep the funds within the space of 2 seconds of the deposit transaction being broadcast: https://bitcointalksearch.org/topic/m.46603379. I suspect there were probably plenty more being being broadcast, but since they were all being rejected by almost every node that we simply didn't learn about them. If someone is spending the resources to run a full node anyway, then it costs very little extra for them to have a database brain wallet address to scan for deposits with every block and have a small script set up to attempt to sweep those addresses as soon as possible. 
I don't think it's necessary to pamper such a minority of "victims". It may sound cruel, but you can't rescue everyone.
In that case: think of it as making it less profitable for the thiefs 
What would it take to "white hat" this? Kinda like my (never implemented) Crazy idea for a community project: empty compromised paper wallets?
...
It's still a race to be the fastest.
...
It's still a race to be the fastest.
Is it worth the hassle? It doesn't happen very often that larger amounts of coins, like >500k sat, hit those addresses. Well, those 0.9BTC recently were quite some surprise to me as it's a long time ago that the equivalent of a five digit fiat value was sent in coins to such addresses. I can't wrap my head around how to be so reckless and uninformed.
Anyway, I don't monitor the thousands of addresses of vulnerable brainwallets or keys derived from publicly available data. It should be common knowledge by now that such "wallets" are stupid and a recipe to loose coins.
I don't think it's necessary to pamper such a minority of "victims". It may sound cruel, but you can't rescue everyone. People involved with crypto coins need to respect and take responsibility for their doing. Your safety net is to learn how it works, learn best practices and don't try to invent some likely stupid procedures that others have already fallen victim to. I may sound snobby. I made mistakes, too. I try my best to learn from my and other's mistakes.
You get two additional addresses 3DnW8JGpPViEZdpqat8qky1zc26EKbXnmM (14 tx) and bc1qngw83fg8dz0k749cg7k3emc7v98wy0c74dlrkd (6 tx) from the compressed private key.
Thanks, I was too lazy to look those up.My crazy idea:
Step 2 is where I don't know how to do it (yet), but I do know there are brain wallet hunters out there who use a similar system to steal funds.
Step 4 is the tricky part: if for instance the funds come from an exchange, the owner won't be able to sign a message. But if I don't do this, the site owner will take the funds for sure so I consider this a white hat thing to do.
It's still a race to be the fastest. - ~
- Setup a system to sweep all keys the moment they get funded
- Send funds/dust to an addy that leaves a hint to find this topic
- Return the funds to the owner after signing a message from the original sending address
Step 2 is where I don't know how to do it (yet), but I do know there are brain wallet hunters out there who use a similar system to steal funds.
Step 4 is the tricky part: if for instance the funds come from an exchange, the owner won't be able to sign a message. But if I don't do this, the site owner will take the funds for sure so I consider this a white hat thing to do.
I am observing empty string brainwallet (empty string converted to BTC private key = WIF). While ago someone has put on it 900 mBTC, which has disappeared quickly within minutes (or less, seconds).
Two days ago someone put ~21 mBTC on the same address. In the same block it has been taken by someone else. Once again only seconds.
Two days ago someone put ~21 mBTC on the same address. In the same block it has been taken by someone else. Once again only seconds.
While I see the movement of the 0.9BTC on July 27th, txs 37e166a1e52e96bcfe535738082e328ef8db56aafd6945d9cad6f2afdb34b4a4 and theft with 57a9a8192a86e168a4c77f933894897f16077c44ae5b959debfe3d9aaa654f13, I don't see transactions regarding 0.021BTC in the days since that event. Do you have a transaction ID for those 21mBTC, are you on mainnet?
This is an interesting one. It produces 2 used addresses:
Uncompressed: 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (Transaction count 717, Total received 59.99123751 BTC 38,217.82 USD)
Compressed: 1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV (Transaction count 129, Total received 1.19590736 BTC 1,213.40 USD)
Uncompressed: 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (Transaction count 717, Total received 59.99123751 BTC 38,217.82 USD)
Compressed: 1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV (Transaction count 129, Total received 1.19590736 BTC 1,213.40 USD)
You get two additional addresses 3DnW8JGpPViEZdpqat8qky1zc26EKbXnmM (14 tx) and bc1qngw83fg8dz0k749cg7k3emc7v98wy0c74dlrkd (6 tx) from the compressed private key.
Quote
While ago someone has put on it 900 mBTC, which has disappeared quickly within minutes (or less, seconds).
Two days ago someone put ~21 mBTC on the same address.
I don't see the 21 mBTC.Two days ago someone put ~21 mBTC on the same address.
I don't see those 21mBTC either.
I wouldn't even call it a brain wallet. My guess is some buggy wallet implementation causes people to send funds to an address derived from a private key created using nothing instead of random data.
I'm amazed how many people send funds to this address!
I'm amazed how many people send funds to this address!
I can't believe it to be a buggy wallet, I mean wouldn't it have been fixed by now. So many snatched off transaction, many only with dust.
On the other hand I can't believe there are people out there who think the empty string "brain" wallet is a safe place to submit even the bare minimum of Satoshis allowed by the network. Absolute bonkers...
There must be fierce competition to be the first! They usually use very high transaction fees to steal funds.
Seems to pay off. Just for fun I monitor a few of such publicly known private keys' addresses. It's crazy how often some of the popular ones get hits (vanitygen address example 1BoatSLRHtKNngkdXEeobR76b53LETtpyT (uncompressed: 932 tx), 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T (uncompressed SHA256("correct horse battery staple"), 4147 txs!) and 1HwWGwdzk5Ed7sMjpn9kadJQs5VEZ192wa, 22 tx).
carefully all bitcoin addresses have someone monitor automatic all time including used addresses and leaked passwords address
I testing on bitcoin testnet with some addresses public on the internet and use that address to receive testnet faucet
The next days my testnet faucet receive is gone someone monitored and scanned the address all time I think that is an automatic system that monitors and schedule time scan everyday
I testing on bitcoin testnet with some addresses public on the internet and use that address to receive testnet faucet
The next days my testnet faucet receive is gone someone monitored and scanned the address all time I think that is an automatic system that monitors and schedule time scan everyday
Note that quick theft doesn't only happen to brain wallets, but to addresses whose unlocking script is known. For example, any satoshi you send to 2MxN427kzSLQozTCFtm4QyFotQfvYZKyLS8 will be immediately spent. I tried it in 14f8e61c04095d1ac7ba7d7f7b089f72a73441ec43c9abe928db988bbec969ea, and it didn't last even a second; it was spent in ed6bed780fbbc0385928996cde804a9ce95bac0daaa4bfee845d448b9e338986 immediately.
This is because the redeem script is very much known. To spend an output you need to find a number that once hashed twice with SHA256, it'll return "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000", which if you notice, is the genesis block's hash in big-endian.
This is because the redeem script is very much known. To spend an output you need to find a number that once hashed twice with SHA256, it'll return "6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000", which if you notice, is the genesis block's hash in big-endian.
3. this is automatic work along with outside-Bitcoin-Core communication, as the script/program is very fast and as the incoming transaction comes, it is right away sent in the same block?
So someone has written program that quickly sends incoming BTC and is strictly connected to the network, right?
So someone has written program that quickly sends incoming BTC and is strictly connected to the network, right?
It is not a rocket-science task. Recently I have written something similar (https://bitcointalksearch.org/topic/m.60709184) but it was written for private use (clearing known addresses from a given xpub), so I think it is not a good tool for that purpose (quick 'stealing' incoming coins) - script is quite slow (one-threaded) and taking into consideration that there are hundreds or thousands known private keys where some dust comes from time to time, it processes transaction too slow to be competitive.
There must be fierce competition to be the first!
Exactly because of this, they have used this method in the past as a way to spam bitcoin network. They send coins to private keys that either they reveal first or are already known (weak keys, brain wallets, etc.) and get others to spam the network with a lot of duplicate transactions that nodes have to try and verify, replace or reject constantly. I am observing empty string brainwallet (empty string converted to BTC private key = WIF).
This is an interesting one. It produces 2 used addresses:Uncompressed: 1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN (Transaction count 717, Total received 59.99123751 BTC 38,217.82 USD)
Compressed: 1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV (Transaction count 129, Total received 1.19590736 BTC 1,213.40 USD)
This is a brain wallet.
I wouldn't even call it a brain wallet. My guess is some buggy wallet implementation causes people to send funds to an address derived from a private key created using nothing instead of random data.I'm amazed how many people send funds to this address!
Quote
These individuals set up bots to monitor all these addresses, used and unused, and as soon as any coin is deposited immediately sweep it to their own wallet.
There must be fierce competition to be the first! They usually use very high transaction fees to steal funds. Jump to: