Wasabi Wallet - Total Privacy For Bitcoin

[alani123]

Sadly I don't think we've reached a point in BTC mixing tech where it can be so immutable and decentralised that whoever runs it doesn't matter.

Samurai Devs were arrested we see how that project is going.
Wasabi mixing Dev was halted, now only one party is involved.

With the recent DeFi hack some people where cheering when an entire chain, Arbitrum, took a centralised decision and unilaterally seized millions in ETH.

We're at a point where precedent is created.
If the seizure is demanded from those running coordinators it's likely going to be the go to route for the future. Either assist in the search, shut down or face liability.

The conclusion is we need better tech.

[Wind_FURY]

Sadly I don't think we've reached a point in BTC mixing tech where it can be so immutable and decentralised that whoever runs it doesn't matter.

Samurai Devs were arrested we see how that project is going.
Wasabi mixing Dev was halted, now only one party is involved.

With the recent DeFi hack some people where cheering when an entire chain, Arbitrum, took a centralised decision and unilaterally seized millions in ETH.

We're at a point where precedent is created.
If the seizure is demanded from those running coordinators it's likely going to be the go to route for the future. Either assist in the search, shut down or face liability.

The conclusion is we need better tech.

That's TRUE. But how do the developers actually improve the technology if they don't try things and if they're not going to get implicated. It's the best path to build anything of value for the community.

Plus for "better tech", what's your opinion about Monero?

[Kruw]

Try testing the BIP157 PR! This uses Bitcoin's P2P network to obtain BIP158's block filters instead of downloading them from a central server (or your own node).

[NotATether]

Sadly I don't think we've reached a point in BTC mixing tech where it can be so immutable and decentralised that whoever runs it doesn't matter.

I'm going to ignore everyone cheering about seized coins, as it's all fun and celebrations to them until their own funds are frozen.


Anyways, mixers have basically stayed largely the same ever since someone had the brilliant idea to combine CoinJoin with exchange-withdrawn coins.

It's decent, but not the best option for privacy anymore (Monero is much better, but that does not mean you can no longer use Bitcoin).

[JollyGood]

My suggestion is simply to randomly schedule when each non-private input gets coinjoined, so that there is no timing correlation between many non-private inputs. Being able to see they coinjoin at around the same time is very telling.

Without doubt, being able to see coinjoin taking place at the same time could raise questions therefore it becomes an important issue to discuss where privacy could be affected. If it is something that was not already brought to the attention of the team, maybe they will consider adding a function (as your suggested) in a future release.

Higher anonymity score target = more remixing. https://www.youtube.com/watch?v=Kmwmo86MgvQ

You are correct however the question was to understand how that higher anonymity score would impact the scenario that BlackHatCoiner stated.

[PrivacyG]

You are correct however the question was to understand how that higher anonymity score would impact the scenario that BlackHatCoiner stated.

Unless I am missing something, it is not.  The main point is probably that even if the inputs are initially correlated, they will end up impossible to correlate again.

The idea proposed by BlackHatCoiner is great.  I heavily support it.  I thought about inputs possibly being time correlated before only about once, but I did not feed the idea too much as I typically make sure not to put so many inputs at once that it becomes obvious they are related.  It is very difficult to not time correlate things when using the Internet but the more difficult it becomes and particularly when random scheduling is enabled by default, the better for everyone.

[JollyGood]

If I understand correctly, what is being stated is that regardless of the higher anonymity score the fact that a non-private coinjoin is taking place with a time correlation could be detrimental to privacy. If there is a pattern then it might be considered linked or related. In that scenario, the time correlation completely negates the higher anonymity.

In that case, if a scheduled coinjoin for non-private inputs is the solution, it should be considered for implementation for a future release.

Unless I am missing something, it is not.  The main point is probably that even if the inputs are initially correlated, they will end up impossible to correlate again.

The idea proposed by BlackHatCoiner is great.  I heavily support it.  I thought about inputs possibly being time correlated before only about once, but I did not feed the idea too much as I typically make sure not to put so many inputs at once that it becomes obvious they are related.  It is very difficult to not time correlate things when using the Internet but the more difficult it becomes and particularly when random scheduling is enabled by default, the better for everyone.

[PrivacyG]

If I understand correctly, what is being stated is that regardless of the higher anonymity score the fact that a non-private coinjoin is taking place with a time correlation could be detrimental to privacy. If there is a pattern then it might be considered linked or related. In that scenario, the time correlation completely negates the higher anonymity.

In that case, if a scheduled coinjoin for non-private inputs is the solution, it should be considered for implementation for a future release.

You are probably right, I thought this was about inputs that did not go through any Coin Join round at all.

Anyway.  A schedule would help a lot in both cases.

[Kruw]

Try testing the new node discovery PR!

[Kruw]

Try testing the BIP157 PR! This uses Bitcoin's P2P network to obtain BIP158's block filters instead of downloading them from a central server (or your own node).

Try testing the new node discovery PR!

Both PRs are now merged! Last steps for the next release: https://github.com/orgs/WalletWasabi/discussions/14663

[Kruw]

Which loading screen design is your favorite?

A: "Multi Bar"



B: "Double Row"



C: "Single Row"

[BlackHatCoiner]

A. Multi bar, by far.

[PrivacyG]

Double Row looks confusing.  Almost like statistics rather than a progress bar.  Single Row is better but Multi Bar is best and the least confusing.

[nc50lc]

Which loading screen design is your favorite?

Single Row, it looks better, having a continuous loading bar makes sense if loading starts sequentially from the "Peers" to "Blocks".
But since those have separate progress, Multi Bar makes more sense.

In terms of aesthetics, I'd go with 'Single Row'.
Users will get that it's a combined bar anyways since the value under each checkpoint updates as it progress.

[ABCbits]

Which loading screen design is your favorite?
--snip--

Multi-bar. It's probably most intuitive and can be modified easier in case you want to add or remove some information.

P.S. I don't know the context or how would it used, but showing only progress of block by default is probably less confusing for less technical user or user who don't care about the detail.

[JollyGood]

I think there are probably many Wasabi Wallet users that do not know anything about Github therefore will not post issues and request there. That does not mean they do not have opinions. If there was a different option (even forums such as this) to list requested features then it might be possible to relay that information to the developers.

Requesting a scheduled coinjoin for non-private inputs does not seem to be a pointless request. There seems to be legitimate concerns behind it.

You are probably right, I thought this was about inputs that did not go through any Coin Join round at all.

Anyway.  A schedule would help a lot in both cases.

[satscraper]

Wasabi has been elevated to v.2.8.0, featuring advances in both decentralization and privacy. Plenty of changes have been made in fact, so it is better that every user reads them and analyzes them for themselves, but I would like to summarize most important:

1)Wasabi now downloads compact block filters directly via Bitcoin's P2P network instead of relying on its own centralized indexing server.

2)Payments can now be embedded directly in a coinjoin transaction.

3)Multiple addresses can be paid in a single transaction.

4)Transactions can now be sent at fee rates as low as 0.1 sat/vB.

[Kruw]

Plenty of changes have been made in fact, so it is better that every user reads them and analyzes them for themselves, but I would like to summarize most important

There is one other critical detail - 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.