Topic: Quick theft (Read 1079 times)
I suspect that consensus for brain wallet's BTC theft can be achieved by highest fee. Still thinking about that though.
legendary
Activity: 2492
Merit: 1092
Leading Crypto Sports Betting & Casino Platform
So someone has written program that quickly sends incoming BTC and is strictly connected to the network, right?
I think the answer is yes, and also, this kind of theft is not unique to Bitcoin alone, I actually think this started with Ethereum.I remember when my first Ethereum wallet was hacked, what the op explain is what happened, as soon as transaction is getting confirmed, it is immediately sent out to another address, this is not something human being can do, human being can never be that fast.
A program written the Hackers is responsible for transactions.
Quote
Someone engaging in what I describe would choose the brainwallets that are known to the person engaging in this behavior. This will include brainwallets both used and unused.
Who and how would choose that person?
A programmer at a mining pool could be be doing this too.
Makes you wonder if you could take the addresses of all the known brainwallets / known compromised addresses find out which pools are mining the transactions and see if there is any commonality.
Doubt there would be anything to find, and it would be just about impossible to figure anything out if the programmer is using any form of opsec but it is an interesting thought.
-Dave
Makes you wonder if you could take the addresses of all the known brainwallets / known compromised addresses find out which pools are mining the transactions and see if there is any commonality.
Doubt there would be anything to find, and it would be just about impossible to figure anything out if the programmer is using any form of opsec but it is an interesting thought.
-Dave
It would be better (from a big O notation standpoint) to have a *set* of all addresses associated with "known" brainwallets, and a hashtable whose key --> value pairs are address --> private keys. Another option would be to use a bloom filter when checking all addresses of outputs from all broadcast (or confirmed) transactions.
Who would be the one to choose which brainwallets are "known" or not? Is 2o8397tyh23047cj309487ycjm29 enough known or not?
It basically depends on whether their bots have scraped this site and others for brainwallet phrases or not. Most ommissions here are accidential, because no pirate looking for treasure would willingly overlook a map (to make a pun for this scenario).
Do I clearly understand that you want to ask each scraper for their brain wallet's list and then "block" these?
It would be better (from a big O notation standpoint) to have a *set* of all addresses associated with "known" brainwallets, and a hashtable whose key --> value pairs are address --> private keys. Another option would be to use a bloom filter when checking all addresses of outputs from all broadcast (or confirmed) transactions.
Who would be the one to choose which brainwallets are "known" or not? Is 2o8397tyh23047cj309487ycjm29 enough known or not?
It basically depends on whether their bots have scraped this site and others for brainwallet phrases or not. Most ommissions here are accidential, because no pirate looking for treasure would willingly overlook a map (to make a pun for this scenario).
Quote
Someone engaging in what I describe would choose the brainwallets that are known to the person engaging in this behavior. This will include brainwallets both used and unused.
Who and how would choose that person?
It would be better (from a big O notation standpoint) to have a *set* of all addresses associated with "known" brainwallets, and a hashtable whose key --> value pairs are address --> private keys. Another option would be to use a bloom filter when checking all addresses of outputs from all broadcast (or confirmed) transactions.
Who would be the one to choose which brainwallets are "known" or not? Is 2o8397tyh23047cj309487ycjm29 enough known or not?
Who would be the one to choose which brainwallets are "known" or not?
Whoever created the "burn it in fees"-service, obviously 
Is 2o8397tyh23047cj309487ycjm29 enough known or not?
This seems a very invalid address. It would be better (from a big O notation standpoint) to have a *set* of all addresses associated with "known" brainwallets, and a hashtable whose key --> value pairs are address --> private keys. Another option would be to use a bloom filter when checking all addresses of outputs from all broadcast (or confirmed) transactions.
Who would be the one to choose which brainwallets are "known" or not? Is 2o8397tyh23047cj309487ycjm29 enough known or not?
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.)
It would be better (from a big O notation standpoint) to have a *set* of all addresses associated with "known" brainwallets, and a hashtable whose key --> value pairs are address --> private keys. Another option would be to use a bloom filter when checking all addresses of outputs from all broadcast (or confirmed) transactions. 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.)
The biggest problem with your proposal is that what you propose (along with my suggested improvements) costs money. I suspect that many have already implemented something similar to what you propose (or perhaps, more likely, something similar to my improvements), and are quickly broadcasting transactions to addresses they control.
This sounds terrible, and no; I'm not a black hat actually. Introducing third parties who get involved within the payer and the destination is just terrible, not from an ethical neither from a technical side. It's bad from a pro-individual and ideological perspective. Having third parties protect the users, besides censorship vulnerable, defeats the purpose of making humans more responsible for their actions. Protecting dumb people from doing dumb decisions doesn't stick with self-custody and censorship resistance.
You make many good points I don't expect it to happen, I just said it would get interesting 
My opinion: miners shouldn't get involved in deciding which transaction gets confirmed on anything else than economic grounds.
It would get interesting if a white hat organisation gets support from mining pools to protect dumb users from sending their funds to known compromised addresses.
This sounds terrible, and no; I'm not a black hat actually. Introducing third parties who get involved within the payer and the destination is just terrible, not from an ethical neither from a technical side. It's bad from a pro-individual and ideological perspective. Having third parties protect the users, besides censorship vulnerable, defeats the purpose of making humans more responsible for their actions. Protecting dumb people from doing dumb decisions doesn't stick with self-custody and censorship resistance. Don't catch them fish. Educate them fishing.
What about _replacing_ the transaction?
Highly unlikely to be successful.What about _replacing_ the transaction?
Highly unlikely to be successful. Any even semi-competent attacker will not flag their stealing transaction to be opted in to RBF, since any other attacker could immediately replace it and steal it from them. Since their transaction will not be opted in to RBF, then any replacement transaction, even with a higher fee rate, will be rejected by the vast majority of nodes and therefore highly unlikely to be mined.That is, until Core version 24.0 is released and we move to full RBF. Then it will start to depend on how many nodes choose to enable full RBF and how many continue to work with opt-in RBF.
That's the solution to "steal" BTC incoming to your wallet.
If you happen to be faster than the existing bots, which I doubt. My node and wallets usually never see only the funding transaction of a known private key's derived address(es) but commonly almost immediately the "stealing" transaction by the existing stealer bots.
What about _replacing_ the transaction?
That's the solution to "steal" BTC incoming to your wallet.
If you happen to be faster than the existing bots, which I doubt. My node and wallets usually never see only the funding transaction of a known private key's derived address(es) but commonly almost immediately the "stealing" transaction by the existing stealer bots.
Bitcoin-cli -getinfo does not give unconfirmed amount for any wallet.
Walletnotify does not give amount which has moved to/from wallet.
And because of the above, there is no automatic way using Bitcoin Core to steal the funds (using these two options above).
EDIT:
There is a way!
If you do:
walletnotify=script %s
Then in %s is transaction id. You can then ask for this transaction's amount:
bitcoin-cli -rpcwallet=your_wallet gettransaction $1
Then you can extract the amount by jq and awk.
With given amount you can immediately send the amount to your address with bitcoin-cli.
That's the solution to "steal" BTC incoming to your wallet.
Walletnotify does not give amount which has moved to/from wallet.
And because of the above, there is no automatic way using Bitcoin Core to steal the funds (using these two options above).
EDIT:
There is a way!
If you do:
walletnotify=script %s
Then in %s is transaction id. You can then ask for this transaction's amount:
bitcoin-cli -rpcwallet=your_wallet gettransaction $1
Then you can extract the amount by jq and awk.
With given amount you can immediately send the amount to your address with bitcoin-cli.
That's the solution to "steal" BTC incoming to your wallet.
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?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? 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.
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.)
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. ...
That's exactly what I was thinking.
Thank you very much for confirmation!
So someone has written program that quickly sends incoming BTC and is strictly connected to the network, right?
Correct.This is a brain wallet. Brain wallets are inherently insecure, and this is an incredibly insecure one at that, given that this brain wallet is generated from an empty string. There are public databases out there which show tens of thousands insecure brain wallets, along with their associated generation string, which have been used in the past, and there are individuals out there with private databases with hundreds of thousands more potential brain wallets generated from things like words, common phrases, song lyrics, book/movie quotes. 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.
To me there are a few possible options on why this could happen:
-It is some kind of scam, where maybe people "generate" a wallet, but in reality the program gives an already known address where the scammer has the private key and quickly takes the fund via a script.
-An exchange, that takes the funds from the specific import address
-Some kind of payment provider
All of that is for sure not done by a human and could be done by a script if you know what you are doing.
-It is some kind of scam, where maybe people "generate" a wallet, but in reality the program gives an already known address where the scammer has the private key and quickly takes the fund via a script.
-An exchange, that takes the funds from the specific import address
-Some kind of payment provider
All of that is for sure not done by a human and could be done by a script if you know what you are doing.
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.
Tell me if I am wrong:
1. this is not manual work when someone is sitting beside Bitcoin Core and manually making an outgoing transaction for incoming BTCs
2. this is not automatic work when Bitcoin Core is scripted for example in Python or Bash via API/CLI/RPC, that when there is coming anything it will be sent right away
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?
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.
Tell me if I am wrong:
1. this is not manual work when someone is sitting beside Bitcoin Core and manually making an outgoing transaction for incoming BTCs
2. this is not automatic work when Bitcoin Core is scripted for example in Python or Bash via API/CLI/RPC, that when there is coming anything it will be sent right away
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?
Jump to: