Before 2.8.0

[lontivero]

After merging the BIP157 synchronization PR and the new Node Discovery PR, we need to polish the details to make the user experience less traumatic as possible.

v2.8.0 will force a re-downloading of all necessary compact filters, this is painful. Checkpoints help a bit to reduce number of filters to download and to wait for but the first time it will be disappointing. Without any further optimization this process can take more than an hour.

Synchronizations after the initial synchronization will be painless, except for those sync'ing with p2p because of the time it requires to find a compact-filter-compatible node. But in general the experience would be good or at least acceptable.

So, what needs to be done?

1. Optimize time required to connect to nodes that provide compact filters.
2. Save the list of nodes discovered to avoid rediscover them again and again and again
3. Do not synchronize blockheaders from height 0 but from 480000 (this should improve the initial download time)
4. Remove the backend rpc servers and any reference in code in the client
5. Display information about the progress
6. Do not display error when it is not connected to RPC
7. allow empty rpc endpoint (which means that the user doesn't have a node and will use the p2p network)

[Kruwed]

5. Display information about the progress

How about this design? Each layer of the synchronization process is shown in parallel:

[Kruwed]

I think 2.8.0 is ready for a release candidate.

1. Optimize time required to connect to nodes that provide compact filters.

The new peer connection system is already 10x faster than the old one, further optimizations are marginal compared to the existing improvement.

2. Save the list of nodes discovered to avoid rediscover them again and again and again

This is a good roadmap, but I think it's a bad idea to add this before the next release. Populating a long term peer list means testing will also take a long time.

3. Do not synchronize blockheaders from height 0 but from 480000 (this should improve the initial download time)

I haven't noticed initial download time lagging from this, my filter headers begin downloading from block 481825 in under 60 seconds after first launch.

4. Remove the backend rpc servers and any reference in code in the client

I think this is done?

5. Display information about the progress

See above comment with a new design proposal. I think this is done though, sync progress already has a countdown when you open your wallet.

6. Do not display error when it is not connected to RPC

This is done.

7. allow empty rpc endpoint (which means that the user doesn't have a node and will use the p2p network)

This is done.

[remcoros]

I just tested the master branch on Debian trixie. Some findings related to RPC and a UI glitch:

note: I already had (correct) RPC host/credentials set before the update to the custom build from master.

2026-06-20 15:08:21.848 [19] WRN | RPCClientExtensions.cs:222     | System.Net.Http.HttpRequestException: Failed to make http request 'http://bitcoind.startos:8332/' after 3 attempts.
   at WalletWasabi.WebClients.Wasabi.RetryHttpClientHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
   at NBitcoin.RPC.RPCClient.SendCommandAsync(RPCRequest request, CancellationToken cancellationToken)
   at NBitcoin.RPC.RPCClient.GetBestBlockHashAsync(CancellationToken cancellationToken)
   at WalletWasabi.BitcoinRpc.RpcClientBase.GetBestBlockHashAsync(CancellationToken cancellationToken)
   at WalletWasabi.Extensions.RPCClientExtensions.SupportsBlockFiltersAsync(IRPCClient rpc, CancellationToken cancellationToken)
2026-06-20 15:08:21.852 [19] WRN | Global.cs:436                  | Was not able to connect to the Bitcoin RPC server 'http://bitcoind.startos:8332' with the credentials provided. Please configure valid RPC credentials in settings and restart.

then I opened the settings, my previous settings are still there:

Click "Verify connection", it says it worked?:

Now, the "Done" button is broken (clicking on it, does not close the window).

Click outside the window / restart Wasabi. Still says it cannot connect to RPC in the status icon and in the logs.

Verified that RPC (and credentials) actually work using wget:

[remcoros]

btw, the release build (Contrib/release.sh) was failing due to NU1903 (error NU1903: Warning As Error: Package 'SQLitePCLRaw.lib.e_sqlite3' 2.1.11 has a known high severity vulnerability, GHSA-2m69-gcr7-jv3q).

some packages need bumping and the package.lock.json updated. For example:

WalletWasabi/WalletWasabi.Daemon/packages.lock.json

Line 220 in b7651b8

"Microsoft.Data.Sqlite": {

Microsoft.Data.Sqlite 10.0.2 (which uses SQLitePCLRaw.bundle_e_sqlite3 2.1.11) has been delisted from nuget.org: https://www.nuget.org/packages/Microsoft.Data.Sqlite/#versions-body-tab

[Carti-it]

dotnet/efcore#38257 appears that it might be fixed in .NET 10.0.11. Many projects are affected by this issue.