Wasabi Wallet - Total Privacy For Bitcoin

[ABCbits]

--snip--

But who would run CoinJoin in Wasabi Wallet 1.x if he/she truly cared about privacy. Definitely he/she would run Wasabi Wallet 2.x, no?

Handbook you mentioned show Wasabi Wallet 1.x screenshot on "Case 2: Wasabi Coinjoin Analysis".

Plus I'm not talking about opening a direct channel to himself/herself. It's merely to use two different custodial Lightning wallets from different builders and sending a transaction to himself/herself from one wallet to the other wallet.

I see, although IIRC those custodial LN wallet expect you to provide liquidity. And with such amount, i expect available route to send such amount would be limited.

--snip--

0.1BTC outputs with the current price seems like an awful lot of money to condense in a single output. In my opinion, having the ability to create 0.01BTC outputs would be a helpful addition, but understandably, if it's not already possible today then I don't think it will be considered for a while. Because I don't think zkSNACKs is working on a newer version of WabiSabi anytime soon.

FWIW CoinJoin protocol on Wasabi Wallet 2.x create varied amount of output.

So, there are 79 denominations from 0.00005000 BTC up to 1374.38953472 BTC.

[NotATether]

FWIW CoinJoin protocol on Wasabi Wallet 2.x create varied amount of output.

So, there are 79 denominations from 0.00005000 BTC up to 1374.38953472 BTC.

I see that the denominations are quite arbitrary:

The standard denominations are: 5000, 6561, 8192, 10000, 13122, 16384, 19683, 20000, 32768, 39366, 50000, 59049, 65536, 100000, 118098, 131072, 177147, 200000, 262144, 354294, 500000, 524288, 531441, 1000000, 1048576, 1062882, 1594323, 2000000, 2097152, 3188646, 4194304, 4782969, 5000000, 8388608, 9565938, 10000000, 14348907, 16777216, 20000000, 28697814, 33554432, 43046721, 50000000, 67108864, 86093442, 100000000, 129140163, 134217728, 200000000, 258280326, 268435456, 387420489, 500000000, 536870912, 774840978, 1000000000, 1073741824, 1162261467, 2000000000, 2147483648, 2324522934, 3486784401, 4294967296, 5000000000, 6973568802, 8589934592, 10000000000, 10460353203, 17179869184, 20000000000, 20920706406, 31381059609, 34359738368, 50000000000, 62762119218, 68719476736, 94143178827, 100000000000, 137438953472 sats.

Why are many arbitrary numbers included in the denomination sizes?

[lontivero]

But who would run CoinJoin in Wasabi Wallet 1.x if he/she truly cared about privacy. Definitely he/she would run Wasabi Wallet 2.x, no?

Nobody would and nobody can because Wasabi 1.x was discontinued in 2022 and the WW1 coinjoin service provided by zkSNACKs stopped in 2023 once most liquidity went to WW 2.0.

FWIW, CoinJoin on Wasabi Wallet 1.x create output with ~0.1BTC amount. If anyone make LN channel with such amount, it would stand out. I also notice they show 2 image that shows tracking/clustering visualization, but it has low resolution nobody can verify it.

But who would run CoinJoin in Wasabi Wallet 1.x if he/she truly cared about privacy. Definitely he/she would run Wasabi Wallet 2.x, no?

Plus I'm not talking about opening a direct channel to himself/herself. It's merely to use two different custodial Lightning wallets from different builders and sending a transaction to himself/herself from one wallet to the other wallet.

0.1BTC outputs with the current price seems like an awful lot of money to condense in a single output. In my opinion, having the ability to create 0.01BTC outputs would be a helpful addition, but understandably, if it's not already possible today then I don't think it will be considered for a while. Because I don't think zkSNACKs is working on a newer version of WabiSabi anytime soon.

zkSNACKs, the company that developed Wasabi, doesn't exist anymore. It closed its doors during the first quarter of 2024, since then Wasabi has been maintained by volunteers from the community. The question here is why these people are pretending to be able to track a service that doesn't even exist, for a CoinJoin technology that was obsoleted several years ago, and presenting proofs that nobody can read or verify.

FWIW CoinJoin protocol on Wasabi Wallet 2.x create varied amount of output.

So, there are 79 denominations from 0.00005000 BTC up to 1374.38953472 BTC.

I see that the denominations are quite arbitrary:

The standard denominations are: 5000, 6561, 8192, 10000, 13122, 16384, 19683, 20000, 32768, 39366, 50000, 59049, 65536, 100000, 118098, 131072, 177147, 200000, 262144, 354294, 500000, 524288, 531441, 1000000, 1048576, 1062882, 1594323, 2000000, 2097152, 3188646, 4194304, 4782969, 5000000, 8388608, 9565938, 10000000, 14348907, 16777216, 20000000, 28697814, 33554432, 43046721, 50000000, 67108864, 86093442, 100000000, 129140163, 134217728, 200000000, 258280326, 268435456, 387420489, 500000000, 536870912, 774840978, 1000000000, 1073741824, 1162261467, 2000000000, 2147483648, 2324522934, 3486784401, 4294967296, 5000000000, 6973568802, 8589934592, 10000000000, 10460353203, 17179869184, 20000000000, 20920706406, 31381059609, 34359738368, 50000000000, 62762119218, 68719476736, 94143178827, 100000000000, 137438953472 sats.

Why are many arbitrary numbers included in the denomination sizes?

Because those denominations allow us to decompose any number with minimal or no waste, what means that Wasabi coinjoins don't generate change.

[Kruw]

Wasabi Wallet 2.7.1 was released - https://github.com/WalletWasabi/WalletWasabi/releases/tag/v2.7.1

It fixes a few small bugs:

- UTXO ban times now display again
- Receive button for Hardware Wallets now displays again
- Change avoidance suggestions no longer occasionally disappear when the exchange rate is unknown

[BlackHatCoiner]

Got my coin banned by your coordinator:

Code:

2025-10-13 13:10:05.921 [28] INFO	CoinJoinClient.CreateRegisterAndConfirmCoinsAsync (473)	Round (de74e51f4f15d9ad210f3d3c0d08fa7e2d077d55ccfbd6e12be2ecd1ff72e7b3): [TX_ID]-0 is banned until 10/13/2025 15:09:57 +00:00.

I've set minimum transaction fee for coinjoin = 2 sat/vb. Transactions with less than 1 sat/vb were getting confirmed. I just hope it wasn't because I'm naughty.

[Kruw]

Got my coin banned by your coordinator:

Code:

2025-10-13 13:10:05.921 [28] INFO	CoinJoinClient.CreateRegisterAndConfirmCoinsAsync (473)	Round (de74e51f4f15d9ad210f3d3c0d08fa7e2d077d55ccfbd6e12be2ecd1ff72e7b3): [TX_ID]-0 is banned until 10/13/2025 15:09:57 +00:00.

You shouldn't notify a coordinator of your ban timestamp, they could use it to look up your UTXO 

I've set minimum transaction fee for coinjoin = 2 sat/vb. Transactions with less than 1 sat/vb were getting confirmed.

You can set a maximum participation fee, but not a minimum.

I just hope it wasn't because I'm naughty.

If you click pause on the coinjoin when there's ~<2 mins left in registration, your inputs might not drop in time. Otherwise, this normally happens due to a bad connection or just Tor being unreliable.

[BlackHatCoiner]

You shouldn't notify a coordinator of your ban timestamp, they could use it to look up your UTXO  

I was thinking: couldn't this be an attack vector? Coordinator wants to de-anonymize user A, and bans him. Wouldn't that reveal all the UTXO owned by that user?

You can set a maximum participation fee, but not a minimum.

Sorry, I meant I used a "max" participation fee, not min. I was having the impression that your coordinator banned me because of a very low maximum participation fee, not because of connection issue. My logs said that the fetched fee rate from MempoolSpace was 3 Sat/B, whereas my settings blocked everything above 2 Sat/B.

[lontivero]

You shouldn't notify a coordinator of your ban timestamp, they could use it to look up your UTXO  

I was thinking: couldn't this be an attack vector? Coordinator wants to de-anonymize user A, and bans him. Wouldn't that reveal all the UTXO owned by that user?

No, each input is independent. The client treat them independently too, this means that if one coin fails to sign (and will be banned for that reason) all other coins will sign the transaction anyway, even when the whole coinjoin will fail anyway and won't be banned.

You shouldn't notify a coordinator of your ban timestamp, they could use it to look up your UTXO  

You can set a maximum participation fee, but not a minimum.

Sorry, I meant I used a "max" participation fee, not min. I was having the impression that your coordinator banned me because of a very low maximum participation fee, not because of connection issue. My logs said that the fetched fee rate from MempoolSpace was 3 Sat/B, whereas my settings blocked everything above 2 Sat/B.

There is not such a thing as a "participation fee", the only fee (rate) is the bitcoin network fee rate or mining fee rate. Wasabi allows the users to specify what is the maximum fee rate that they are willing to pay to the miners. That fee rate is the one that the coinjoin transaction is going to pay to the miners in concept of fee and it is decided by the coordinator, that's why users have a protection mechanism: to avoid trusting a coordinator operator.

[Kruw]

I was thinking: couldn't this be an attack vector? Coordinator wants to de-anonymize user A, and bans him. Wouldn't that reveal all the UTXO owned by that user?

Yes, this potential attack is why your other inputs remain registered even if your "targeted" input gets banned.

Sorry, I meant I used a "max" participation fee, not min. I was having the impression that your coordinator banned me because of a very low maximum participation fee, not because of connection issue. My logs said that the fetched fee rate from MempoolSpace was 3 Sat/B, whereas my settings blocked everything above 2 Sat/B.

The fee rate is committed to at the beginning of the round's input registration phase. So if a coordinator creates a round at 3 sat/vbyte, clients who set a maximum of 2 sat/vbyte will just skip participating in the round and won't register any inputs at all.

However, one thing to note is that if a blame round is created due to the original round failing, the blame round can commit to a new fee rate.

[BlackHatCoiner]

During the first mixing, the user coinjoins inputs with random amounts, received by his wallet. The set of variable amounts are chosen by the client to minimize leftovers and to ensure that enough of other participants use similar amounts, so that the user gains sufficient privacy (great anonymity set.) However, since there is no change that is returned to his wallet, before mixing the user acknowledges that all mixed inputs will be converted to a set of outputs with these preconfigured values (0.001, 0.00131072, 0.002, 0.00262144 etc.)

Since there are hard values for private coins, and since there is no change, during remixing the user has to break his private outputs into another set with different preconfigured values. But since the user pays the mining fee, it breaks the set he's already selected, and is forced to create a different set of output values every time. Doesn't that make remixing expensive over the long term?

Or is there a possibility the user gets an anonymity set = 1 output during a coinjoin? (which would be equivalent to a change)

[Kruw]

before mixing the user acknowledges that all mixed inputs will be converted to a set of outputs with these preconfigured values (0.001, 0.00131072, 0.002, 0.00262144 etc.)

"Before mixing" is a bit imprecise since there are multiple phases in a coinjoin round. After all users are finished registering their inputs, each client uses the list of input values present in the round for calculating the output values other clients are likely to choose, and then attempts to match them.

Since there are hard values for private coins, and since there is no change, during remixing the user has to break his private outputs into another set with different preconfigured values.

WabiSabi supports arbitrary input amounts, so it doesn't make a difference if your coinjoin inputs are consolidations of previous coinjoin outputs.

But since the user pays the mining fee, it breaks the set he's already selected, and is forced to create a different set of output values every time. Doesn't that make remixing expensive over the long term?

I think you are describing the exact scenario I experienced here: https://github.com/WalletWasabi/WalletWasabi/issues/10467

I skipped the "low balance" warning and turned on coinjoin with only 100k sats in my wallet. From that 100k sat total, my client selected a single 10,000 sat input and created a single output for 8,192 sats, paying an effective fee of ~18%  to gain 11 anon score.

So yes, on the extreme low end of values, the relative cost becomes huge.

Or is there a possibility the user gets an anonymity set = 1 output during a coinjoin? (which would be equivalent to a change)

Yes, whales who have a huge amount of liquidity compared to the rest of the participants in the round will only be able to partially split their coins. The unequal remainder doesn't gain any anon score.

[BlackHatCoiner]

So yes, on the extreme low end of values, the relative cost becomes huge.

And as you remix, you keep getting lower and lower values. For example, you're mixing just one (private) input of 0.005 BTC. In the first coinjoin, you could get 0.002 + 0.002 + 0.0005 + 0.00039366 + 0.0001 (= 0.00499366 BTC) output values. On the second coinjoin, at least one of these private inputs will have to be broken into at least two outputs with less values (such as: 0.0005 could be broken to another 0.00039366 & 0.0001).

I skipped the "low balance" warning and turned on coinjoin with only 100k sats in my wallet. From that 100k sat total, my client selected a single 10,000 sat input and created a single output for 8,192 sats, paying an effective fee of ~18%  to gain 11 anon score.

I think you have said that your coordinator will create outputs with min value 10,000 sats. This means that some user cannot coinjoin one input of 10,000 sat alone. Ideally, he should coinjoin something over 0.001 BTC, otherwise a great percentage of the amount will be paid in leftovers. Is that correct?

[Kruw]

And as you remix, you keep getting lower and lower values.

No, smaller inputs can also be consolidated into larger outputs within a coinjoin, so remixing doesn't require you to continue creating smaller coins.

I think you have said that your coordinator will create outputs with min value 10,000 sats. This means that some user cannot coinjoin one input of 10,000 sat alone.

Correct. Other coordinators offer minimum values of 5,000 sats and 2,100 sats.

Ideally, he should coinjoin something over 0.001 BTC, otherwise a great percentage of the amount will be paid in leftovers. Is that correct?

My minimum recommendation is 0.005 BTC, but costs are more heavily affected by mempool fees compared to decomposition leftovers.

[BlackHatCoiner]

No, smaller inputs can be also consolidated into larger outputs within a coinjoin, so remixing doesn't require you to continue creating smaller coins.

Right. Does the client prioritize the larger amounts when possible, or is it something that is picked at random?

[Kruw]

Right. Does the client prioritize the larger amounts when possible, or is it something that is picked at random?

If you run the app with --loglevel=debug, you'll see a huge nest of random adjustments that are made when you begin coinjoin input registration:

Code:

2025-11-03 18:14:20.445 [19] DEBUG	CoinJoinManager.HandleCoinJoinCommandsAsync (252)	Wallet (Testing Wallet): CoinJoinClient started.
2025-11-03 18:14:20.445 [19] DEBUG	CoinJoinManager.HandleCoinJoinCommandsAsync (253)	Wallet (Testing Wallet): StopWhenAllMixed:'False' OverridePlebStop:'False'.
2025-11-03 18:14:21.142 [19] DEBUG	WasabiHttpClientFactory.CreateHttpClientHandler (64)	Create handler satoshi-coordination
2025-11-03 18:14:24.383 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (88)	Coin selection started:
2025-11-03 18:14:24.383 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (89)	filteredCoins: 10 coins, valued at 0.00987127 BTC.
2025-11-03 18:14:24.384 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (90)	privateCoins: 9 coins, valued at 0.00954359 BTC.
2025-11-03 18:14:24.384 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (91)	semiPrivateCoins: 1 coins, valued at 0.00032768 BTC.
2025-11-03 18:14:24.384 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (92)	redCoins: 0 coins, valued at 0.00 BTC.
2025-11-03 18:14:24.384 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (103)	allowedNonPrivateCoins: 1 coins, valued at 0.00032768 BTC.
2025-11-03 18:14:24.390 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (112)	Targeted inputCount: 9.
2025-11-03 18:14:24.395 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (122)	allowedPrivateCoins: 8 coins, valued at 0.00941237 BTC.
2025-11-03 18:14:24.395 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (125)	allowedCoins: 9 coins, valued at 0.00974005 BTC.
2025-11-03 18:14:24.396 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (135)	Largest non-private coins: 0.00032768 BTC.
2025-11-03 18:14:24.401 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (175)	Created 2 combinations within 0 seconds.
2025-11-03 18:14:24.405 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (180)	bestRep: 6.
2025-11-03 18:14:24.406 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (181)	Filtered combinations down to bestRepGroups: 2.
2025-11-03 18:14:24.408 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (184)	Remaining largest non-private coins: 0.00032768 BTC.
2025-11-03 18:14:24.408 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (201)	Randomly selected large non-private coin: 0.00032768.
2025-11-03 18:14:24.409 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (211)	Selected the final selection candidate: 9 coins, 0.0001, 0.00354294, 0.00039366, 0.00059049, 0.001, 0.001, 0.00262144, 0.00016384, 0.00032768 BTC.
2025-11-03 18:14:24.412 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (275)	Optimizing selection, removing coins coming from the same tx.
2025-11-03 18:14:24.412 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (276)	sameTxAllowance: 3.
2025-11-03 18:14:24.412 [3] DEBUG	CoinJoinCoinSelector.SelectCoinsForRound (277)	winner: 6 coins, 0.00032768, 0.0001, 0.00059049, 0.00354294, 0.00262144, 0.00039366 BTC.
2025-11-03 18:14:24.425 [3] DEBUG	CoinJoinClient.CreateRegisterAndConfirmCoinsAsync (519)	Round (e1b086f4bd1a4dd2e23c1803e88b03b5b8d75a1bdf952ede39f5d2b09464910d): Inputs(6) registration started - it will end in: 00:42:52.

One of the devs has a PR to rewrite the coin selection, but I'm not sure it's high priority at the moment - https://github.com/WalletWasabi/WalletWasabi/pull/13651

[BlackHatCoiner]

How do you run the coordinator? I've downloaded the source code, built Wasabi Wallet and ran it successfully, then I configured ~/.walletwasabi/coordinator/Config.json (RPC user/pass etc.) I tried to run it with dotnet run -- -datadir=/home/user/.walletwasabi/coordinator, but according to the logs, various permission and authorization related things went wrong.

There should be a fairly straightforward way to run your own coordinator, but the docs are short on that matter.

[Kruw]

How do you run the coordinator?

I used Nix to deploy it.

I've downloaded the source code, built Wasabi Wallet and ran it successfully, then I configured ~/.walletwasabi/coordinator/Config.json (RPC user/pass etc.) I tried to run it with dotnet run -- -datadir=/home/user/.walletwasabi/coordinator, but according to the logs, various permission and authorization related things went wrong.

Since I originally set up my server, there's been a number of changes to make coordinator operation more lightweight, I just haven't applied them since I don't want to break anything in production. I've been trying to deploy a backup for testing, but I haven't quite figured it out either. Does your issue look like this?

Code:

2025-10-26 14:13:24.019 [7] CRITICAL	Program.Main (19)	System.Net.Http.HttpRequestException: Name or service not known (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion:8332)
 ---> System.Net.Sockets.SocketException (0xFFFDFFFF): Name or service not known
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|285_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(QueueItem queueItem)
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, 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.GetBlockchainInfoAsync(CancellationToken cancellationToken)
   at WalletWasabi.BitcoinRpc.RpcClientBase.GetBlockchainInfoAsync(CancellationToken cancellationToken) in WalletWasabi/BitcoinRpc/RpcClientBase.cs:line 49
   at WalletWasabi.Coordinator.StartupTask.AssertRpcNodeFullyInitializedAsync(CancellationToken cancellationToken) in WalletWasabi.Coordinator/StartupTask.cs:line 36
   at WalletWasabi.Coordinator.StartupTask.ExecuteAsync(CancellationToken cancellationToken) in WalletWasabi.Coordinator/StartupTask.cs:line 29
   at WalletWasabi.Coordinator.Extensions.RunWithTasksAsync(IHost host, CancellationToken cancellationToken) in WalletWasabi.Coordinator/Extensions.cs:line 17
   at WalletWasabi.Coordinator.Program.Main(String[] args) in WalletWasabi.Coordinator/Program.cs:line 15

edit: I used the method you described to try to run it on my laptop and connecting to the same node using my local network instead of accessing it remotely with its onion address, I got a connection refused error instead:

Code:

2025-11-07 07:45:43.928 [7] CRITICAL	Program.Main (19)	System.Net.Http.HttpRequestException: Connection refused (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.local:8332)
 ---> System.Net.Sockets.SocketException (111): Connection refused
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|285_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(QueueItem queueItem)
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, 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.GetBlockchainInfoAsync(CancellationToken cancellationToken)
   at WalletWasabi.BitcoinRpc.RpcClientBase.GetBlockchainInfoAsync(CancellationToken cancellationToken) in WalletWasabi/BitcoinRpc/RpcClientBase.cs:line 49
   at WalletWasabi.Coordinator.StartupTask.AssertRpcNodeFullyInitializedAsync(CancellationToken cancellationToken) in WalletWasabi.Coordinator/StartupTask.cs:line 36
   at WalletWasabi.Coordinator.StartupTask.ExecuteAsync(CancellationToken cancellationToken) in WalletWasabi.Coordinator/StartupTask.cs:line 29
   at WalletWasabi.Coordinator.Extensions.RunWithTasksAsync(IHost host, CancellationToken cancellationToken) in WalletWasabi.Coordinator/Extensions.cs:line 17
   at WalletWasabi.Coordinator.Program.Main(String[] args) in WalletWasabi.Coordinator/Program.cs:line 15

There should be a fairly straightforward way to run your own coordinator, but the docs are short on that matter.

The BTCPay Server plugin was really convenient for this.

[Kruw]

Wasabi v2.7.2 is out with some bug fixes: https://github.com/WalletWasabi/WalletWasabi/releases/tag/v2.7.2

[Coinjoiner21]

Hello forum.

We have set up a new coordinator: https://coinjoiner.com/.  More coordinators means greater robustness and resilience.  We aim to use leftover fees to fund developers who will work on addressing Wasabi's shortcomings (read more about this in our website).  We don't have any liquidity at the moment, so it'd be appreciated if some of you could switch coinjoining with us for a little time.

Please tell us what you think about our main idea.

[Kruw]

Hello forum.

We have set up a new coordinator: https://coinjoiner.com/.  More coordinators means greater robustness and resilience.  We aim to use leftover fees to fund developers who will work on addressing Wasabi's shortcomings (read more about this in our website).  We don't have any liquidity at the moment, so it'd be appreciated if some of you could switch coinjoining with us for a little time.

Please tell us what you think about our main idea.

Awesome, glad to see more coordinators. A minimum input count of 8 seems a bit low though, a single client can register up to 10 inputs.