WASABI v2.8.0 IS A MANDATORY UPGRADE - All previous versions of Wasabi will no longer connect to the Tor network after September 1, 2026. The Tor Project announced (with only 2 months advance notice) that they are terminating network support for versions of Tor earlier than 0.4.9.x. This is reckless since the first stable version of 0.4.9.x was only released in February, so there wasn't much change to embed the upgrade ahead of time.
10 months of work went into this massive release, there are so many new features and bug fixes that they can't all be listed. Here are the highlights in this version:
⚙️ P2P synchronization for compact filters⚙️ P2P synchronization for compact filters
Wasabi pioneered the use of compact block filters for private wallet synchronization. This involved implementing a custom indexer to build the filters, and hosting a server to provide them to clients.
Progress continued on block filters, resulting in standardized BIPs and direct support in Bitcoin node software. This version of Wasabi uses Bitcoin’s P2P network to download compact filters, eliminating the centralized server.
Onboarding new users to Wasabi is now faster thanks to wallet birthday checkpoints. Newly generated wallets no longer waste time and bandwidth downloading old blockchain history since it would be impossible for a new wallet to have previously received any transactions.
This will require a resync if you have a previous version of Wasabi installed
🚀 Pay in coinjoin🚀 Pay in coinjoin
Sending payments directly inside a coinjoin transaction uses block space more efficiently and improves privacy in several ways:
- The age of your inputs is not revealed, so the receiver does not learn how long you’ve held your coins.
- The size of your change is not revealed, so the receiver does not learn the amount of coins you have left over.
- You can batch multiple payments into one transaction without revealing they originate from the same sender.
I will write a dedicated post on SN next week going into more details
↘️Sub-1 sat/vByte transaction fees↘️Sub-1 sat/vByte transaction fees
You can now spend coins using fee rates as low as 0.1 sat/vByte, letting you save up to 90% on mining fees. If a low fee transaction gets “stuck”, you can use Replace By Fee (RBF) to speed it up.
Long live the free market.
♻️ Payment batching♻️ Payment batching
You can now pay to multiple addresses in the same transaction. This significantly reduces the amount of block space used compared to sending each payment individually.
Block space recycling.
📎 Support for arm64 Linux, Tails, and Whonix📎 Support for arm64 Linux, Tails, and Whonix
Linux users with arm64 devices are now part of the Wasabi family. Tails and Whonix installations are now automatic and no longer require manual Tor configuration.
I have not fully tested this yet, looking for feedback.
📜 Scheme scripting language📜 Scheme scripting language
The scripting language is an experimental feature that makes Wasabi programmable, queryable, and extensible.
Enhanced functionality that is helpful AI, currently an experimental feature that you must enable.
🔑 Signet test network🔑 Signet test network
Testnet3 and Testnet4 use proof of work for generating blocks, just like mainnet. Because testnet coins have no value, low mining difficulty allows an attacker with a small amount of hashpower to flood blocks or create long reorgs.
Signet is another test network that allows a set of signers to create blocks. This reduces the unpredictable behavior so developers can work with a stable environment.
I only test on mainnet, yolo.
Very poor (lazy) decision making on their part. "We don't like deprecating older versions" -> Deprecates a 1.5-month old release. Ugh. Nice fast reaction speed on your end though!
This was on my wishlist for a while. Awesome!
Wasn't it already known that 0.4.8 will reach EOL this month?
source
EOL is a product (software) lifecycle phase, which has nothing to do with choices made towards protocol features; that is a separate thing. What you do is you plan your protocol features, and then you align that into your product lifecycle, not the other way around. What is happening here is that they make a breaking protocol feature deprecation decision 21 days after the last software supporting it went EOL. And that is poor decision making.
I don't mind them stopping to maintain the specific software version, that's not the issue. And them putting effort in doing a maintenance release with a useful life of 4 months is also not a huge problem besides time wasted (I truly hate my review time being wasted by poor decision making, but in this case it didn't affect me.)
What I do mind is killing protocol features because they don't want to maintain it:
But, there is not just good, but GREAT news: BIP-110 Rule 3 will make this applicable to Bitcoin too. Make Users Slaves Again
#MUSA!What are payment methods for P2P?
"I only test on mainnet, yolo"
lol
The P2P filter sync is the part worth flagging. Client-side filtering already kept addresses local, so the residual surface on the old setup was sync metadata: client IP and block-range timing, mostly absorbed by Tor. Dropping the hosted filter server removes that trust point and the single-server availability dependency. The open question is whether it relocates the surface to peer level, which peers you pull filters from and the fetch pattern, rather than removing it outright. Feels like the same instinct that kept coinjoin going after zkSNACKs stepped back, applied to sync instead of the coordinator. How are you handling peer-selection privacy for the BIP157 fetch over Tor?