Fun fact, if you have a bitcoin full node on the same computer where you run Wasabi, it is automatically used without requiring custom settings.
There is however no privacy benefit of doing so, it only saves a bit of bandwidth and storage.
Defaults matter, a lot.
Thank you for the fun fact! It's always great to have some bit of information tidbits about Bitcoin. Although, I bet it's not that fun when your computer starts heating up like a furnace from running a full node and Wasabi at the same time. But hey, Beats taking out an actual furnace or turn on the AC to cool down now doesn't it? Might as well save on electricity while helping with security and privacy, amirite?
Thanks for sharing that insight with me, my friend. It's true that technical details like this – even ones as seemingly minor as which computer a bitcoin full node is located on – can have significant ripple effects when it comes to enhancing user privacy and security.
It underscores the important point that in building any decentralized, privacy-focused system or application, attention to detail and intelligent design will always pay dividends. It's critical for developers and users alike to stay sharp and actively engaged with every aspect of the ecosystem if we hope to continue building a better future for all.
And yes, defaults arguably matter more than people realize in standards-driven discussions or regulatory environments often dominated by lobbies acting behind closed doors. Anchoring at sound defaults upholds confidentiality against adversarial tools designed upset equilibrium since deep ethical questions often arise from potential burden imposed on legislators' constituents dignity so developers should embrace them viewing autonomy assurance provided there rather than solely performative gestures animated nearly unlikely pretend-to-be-oriented schemas giving more false raw-simplicity impressions than complex/relevant ingredients needed when implementing real concepts.\
I disagree about there not being any privacy benefit. Every Wasabi instance that's paired with a local node performs exactly the same non-coinjoin/non-broadcasting network operations, making it impossible to use network activity to determine which instance received which transaction outputs. (This is called information theoretic perfect privacy.)
Wasabi instances that use BIP157/8 compact block filters each perform different network operations depending on their transaction history. These operations are performed over Tor, with Wasabi frequently rotating network identities, which defeats simple attacks---but is still far from perfect. If the threat model includes global passive surveillance, record-now-decrypt-when-post-quantum surveillance, crypto or protocol vulnerabilities in Tor or Wasabi, or other threats, then it may be possible to identify the IP address of a wallet controlling a certain address.
More importantly "it only saves a bit of bandwidth and storage" ignores what is, to me, the primary benefit of running a full node: the assurance that the bitcoins you receive have all the characteristics necessary to make them easy to sell in the future, specifically that every previous transfer of those bitcoins was valid according to the consensus rules and that all of those transfers are documented on the block chain currently known to have the most proof of work.
Very great points, thanks for clarifying with so much nuance.
Do you think the false positive rate of block filters provides a reasonable defense even if Tor is broken? Blocks that do not contain users addresses are downloaded too.
It depends a lot on the threat model. Let's consider two scenarios:
1. Mallory is monitoring all traffic to a given IP address (no Tor, or Tor is completely broken) and wants to learn which outputs it controls. Every transaction downloaded by that IP address which doesn't belong to its wallet increases the anonymity set of the transactions which do belong to that IP addresses's wallet. Because BIP157/8 involves downloading whole blocks (typically a few thousand transactions), it would create decent-sized anonymity sets even if there was never a false positive; adding the occasional false positive block just improves that.
By comparison, Bitcoin Core is like having a 100% false positive rate; now the anonymity set is every transaction in the entire best block chain.
2. Mallory knows a Bitcoin address and wants to find the IP address of the wallet controlling that Bitcoin address (again, no Tor). If Mallory has the ability to surveil IP addresses that the wallet might be using, she can spent a tiny bit of money to that address to get the wallet to download that block. Many other wallets will also download that block, either because they had transactions in it or because of the false positive rate, so that's the initial anonymity set. Mallory can then send another tiny bit of money to the address. The wallet she's interested in will download that new block but many of the other wallets which previously downloaded it won't (they didn't have a tx in that block or it wasn't a false positive for them). This shrinks the anonymity set. Each time Mallory sends a bit more money to the address, the anonymity set shrinks further, until she finds the IP address.
By comparison, Bitcoin Core is immune to this attack. It downloads every seemingly-valid block unconditionally.
2. is an interesting attack I did not yet think about, thanks!
Is there some math to calculate how much your anonset shrinks with each address reuse block? I guess it depends on the false positive rate of the block filters, but how does this overlap with other users' addresses?
And sadly you can't even ignore those low value coins, as you only learn about their value after downloading the block.
You could not to download blocks on reused addresses in general, but that means you might miss a lot of value from "honest" address reuse transactions...
Unfortunately, with stock BIP158, you can't avoid monitoring for reused addresses until you've spent all the coins you want to spend that you previously received to those addresses. That's because BIP158 "basic" filters use the output scriptPubKey to track both receiving bitcoins and spending them.
For example, Alice receives some bitcoins to bc1pfoo in a transaction in a block. The filter for that block commits to OP_0 foo.
Later, Alice spends that transaction output. The filter for that later block also commits to OP_0 foo.
If, in between those two blocks, someone else sent bitcoins to bc1pfoo, then the filter for that block would also commit to OP_0 foo. It wouldn't be possible for Alice's wallet to determine whether the filter made that commitment because new bitcoins were received to bc1pfoo or because of a spend of the bitcoins she had previously received.
Since there is in fact a privacy improvement to doing no filtering at all, it would be good to have a high bandwidth mode where every block is downloaded.
Also, does this still work if your local node is a pruned node?
