Topic: Quick theft (Read 1070 times)
I suspect that consensus for brain wallet's BTC theft can be achieved by highest fee. Still thinking about that though.
legendary
Activity: 2422
Merit: 1083
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?Jump to: