Quick theft

[pbies]

Those BTC from transactions to brain wallets were sent with a exact fee of 1.0 mBTC. That's ~21 USD.

[NotATether]

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".

[pbies]

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.

[LoyceV]

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?

[d3bt3]

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?

It was an empty string. So guessing already in the list.

[pbies]

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.

[Cricktor]

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.

[pbies]

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?

[o_e_l_e_o]

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.

[LoyceV]

What about _replacing_ the transaction?

Highly unlikely to be successful.

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. They could give their own transaction priority and return the funds.

[BlackHatCoiner]

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.

[LoyceV]

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.

[PrimeNumber7]

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.

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.

[pbies]

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?

[BlackHatCoiner]

Is 2o8397tyh23047cj309487ycjm29 enough known or not?

This seems a very invalid address.

[LoyceV]

Who would be the one to choose which brainwallets are "known" or not?

Whoever created the "burn it in fees"-service, obviously

[PrimeNumber7]

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?

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.

[pbies]

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?

[NotATether]

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).

[pbies]

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?