Beware of possibly new type of chain analytics for correlating pkeys to IPs
1769 sats \ 10 comments \ @CruncherDefi 18 May bitcoin
I noticed someone sending low-fee transaction to thousands of addresses. Fee rate is so small (1 sat/kbyte) that it won't get confirmed and will stay in mempool. BUT when someone sends tx to your address, your bitcoin core will pick it up as your own transaction. And it will treat it as your own transaction and so it will periodically rebroadcast it (because it stays in unconfirmed state due to low fee rate).
If attacker listens for those rebroadcasts over long enough time window they can connect UTXO owners to IP addresses with high certainty.
My recommendation is to add 'walletbroadcast=0' to your bitcoind config to protect yourself from this attack. It will disable the 'my own transaction periodic rebroadcast' feature.
write
preview
related posts
52 sats \ 0 replies \ @90fda0cb36 18 May freebie
Tor fixes this.
reply
15 sats \ 0 replies \ @kristapsk 19 May
Use only Tor + I2P with your Bitcoin Core wallet if you want to be private, no clearnet.
reply
10 sats \ 0 replies \ @WeAreAllSatoshi 18 May
Thank you for sharing. Good idea to post in ~privacy too
reply
0 sats \ 0 replies \ @oomahq 19 May
Tor and I2P probably help here. Maybe also the encrypted v2 transfer protocol available since v26 (https://bips.xyz/324#goals), but not so sure.
reply
0 sats \ 5 replies \ @tolot 19 May
Wtf? The p2p nature of transactions broadcasting is not an attack, it'simply how a p2p network works. Since things are as such, the logical conclusion is that basically you can never assume that the creator of the transaction is the one who broadcasts it. Or better, it's reasonable to say that the node that you see as the broadcaster to you of the transaction is not the creator of the transaction.
reply
1000 sats \ 4 replies \ @CruncherDefi OP 19 May
Please read my post carefully with understanding.
The p2p nature of transactions broadcasting
I am talking about rebroadcasting. And rebroadcasting logic behaves differently for cases:
  1. you are the owner of public key (even if only on receiving site)
  2. you are not the owner of public key
And any externally visible difference for those two cases can be leveraged to deanonymize users.
reasonable to say that the node that you see as the broadcaster to you of the transaction is not the creator of the transaction.
And that's why I pointed out the 'repeatable rebroadcast' part. Single measurements obviously won't reveal the owner. But repeated measurements over time will do it faster than you would expect.
reply
0 sats \ 3 replies \ @tolot 19 May
How is rebroadcasting different from broadcasting in the p2p network? Can you point to some resources?
reply
100 sats \ 2 replies \ @CruncherDefi OP 19 May
Never said it is different. Rebroadcasting means repeated broadcasting.
And the "repeating tx broadcasting forever (because of low feerate)" part is privacy compromising. Hope that helps clear things up. For more info just google "bitcoin rebroadcasting".
reply
30 sats \ 1 reply \ @tolot 19 May
How is it compromising if you rebroadcast repetedly any tx in the mempool? What exactly does it compromise? It gives out the information that you have a mempool that holds transactions longer than the median holding time of the network, that's it. That tx is possibly not yours.
reply
100 sats \ 0 replies \ @CruncherDefi OP 19 May
How is it compromising if you rebroadcast repetedly any tx in the mempool? What exactly does it compromise?
IP address to all peers.
It gives out the information that you have a mempool that holds transactions longer than the median holding time of the network, that's it. That tx is possibly not yours.
Yeah, unless you wait for 2 weeks (or whatever the default eviction mempool policy is) after which the transaction rebroadcasting links it to your IP. I repeat again. Bitcoin core treats those transaction as your own when your pubkey is the receipient. And will not stop trying to rebroadcast them.
Sorry, I have a policy that I don't engage in reply chains for more than 3 replies. Hope that replies so far were helpful.
reply