Wasabi Wallet - Total Privacy For Bitcoin

[Kruw]

For those users who are very active in CoinJoins, I believe it's better to stop and wait after everything settles down, because there are Bitcoins being traced related to the ByBit hack.

We have debated over this many times before, but just to avoid any problems, don't risk tainting your outputs.

This is entirely Boltz's fault, not coinjoin's. You can see I had already responded to Boltz: https://stacker.news/items/926257/r/kruw?commentId=927104

[JollyGood]

This has to be a something worth considering. At least for the time being, it might be one the ways to ensure your own coinjoins are not being associated with any stolen funds from any hack (including the ByBit hack). If people decide they do not care and want to continue with coinjojns it could be a massive error on their part.

For those users who are very active in CoinJoins, I believe it's better to stop and wait after everything settles down, because there are Bitcoins being traced related to the ByBit hack.

We have debated over this many times before, but just to avoid any problems, don't risk tainting your outputs.

[FinneysTrueVision]

For those users who are very active in CoinJoins, I believe it's better to stop and wait after everything settles down, because there are Bitcoins being traced related to the ByBit hack.

We have debated over this many times before, but just to avoid any problems, don't risk tainting your outputs.

‘Lazarus used this service so therefore all users of that service is also guilty' is the same logic being used to censor transactions coming from eXch. People should not stop doing coinjoins or swapping or using bridges out of fear that somebody might not like where their coins are coming from. If you think those policies are unfair then you should stop using Boltz and any other exchange that decides to discriminate against honest users based on their transaction history.

[Wind_FURY]

For those users who are very active in CoinJoins, I believe it's better to stop and wait after everything settles down, because there are Bitcoins being traced related to the ByBit hack.

We have debated over this many times before, but just to avoid any problems, don't risk tainting your outputs.

This is entirely Boltz's fault, not coinjoin's. You can see I had already responded to Boltz: https://stacker.news/items/926257/r/kruw?commentId=927104

I personally don't blame any side. I understand Bolt's move of filtering the coins that enter their system in order to protect their users from being "tainted", and to avoid the risk of having their accounts locked by centralized exchanges.

It's the same situation with Wasabi Wallet's old coordinator, which was a very understandable move from my own personal viewpoint.

[Kruw]

SLIP39 integration is coming to Wasabi in the next release - https://github.com/WalletWasabi/WalletWasabi/pull/13800

[JollyGood]

Sooner or later competitors will release similar functioning software or advanced forks therefore Wasabi Wallet has to innovate and stay ahead. This is another step in the right direction. In the end, if the improvements continue it is only going to help the end users because they have more options within the app.

SLIP39 integration is coming to Wasabi in the next release - https://github.com/WalletWasabi/WalletWasabi/pull/13800

[Wind_FURY]

Sooner or later competitors will release similar functioning software or advanced forks therefore Wasabi Wallet has to innovate and stay ahead. This is another step in the right direction. In the end, if the improvements continue it is only going to help the end users because they have more options within the app.

SLIP39 integration is coming to Wasabi in the next release - https://github.com/WalletWasabi/WalletWasabi/pull/13800

But they will always need the Wasabi core developers for their own updates and other back-end innovations. The Forks need those core developers, and therefore they will need to incentive them sooner or later.

Plus if the Forks believe that they could continue development of the code, and actually does produce better code than the Wasabi core developers, then Wasabi will simply copy the code because it is Open Source.

[lontivero]

Sooner or later competitors will release similar functioning software or advanced forks therefore Wasabi Wallet has to innovate and stay ahead. This is another step in the right direction. In the end, if the improvements continue it is only going to help the end users because they have more options within the app.

SLIP39 integration is coming to Wasabi in the next release - https://github.com/WalletWasabi/WalletWasabi/pull/13800

Wasabi dev here.

Wasabi development has been focused on guaranteeing the survival of the wallet almost exclusively since zkSNACKs abandoned the project. This means changing an originally centralized, trusted, client-server architecture to a standalone, trustless piece of software with decentralized services run by volunteers. In other words, the goal is to completely redesign Wasabi's architecture to eliminate central points of failure and protect Wasabi users and volunteers.

However, users need a reason to upgrade their Wasabi clients other than a "better architected" wallet; they would upgrade only if Wasabi has something new and better to offer them than their current version. That's THE reason why Wasabi releases include support for receiving Taproot, Silent Payments, manual coin selection to spend, SLIP39, support for new hardware wallets and others alike—things that are not a priority at all but allow the development to move release after release, removing dependencies from centralized services and achieve eventually the biggest goal.

Small and almost insignificant changes like allowing users to choose the provider for the fee rate and USD/BTC exchange rates, removing the concept of coordination fee, separating the coordinator as an independent service that can be run by anyone and allowing users to configure a coordinator and set its parameters, optimizing the coordinator and backend to run on small computers or cheap VPS instead of requiring monstrously big and expensive hardware, allowing the coordinator to run simply with an aggressively-pruned Bitcoin node, removing the client dependency on tens of centralized APIs—these kinds of changes are the ones that really matter for Wasabi's future.

Wasabi innovates by making the wallet more resilient while adding nice features. But resiliency is THE feature anyway, so in the next version we are going to release Shamir Secret Sharing backups but also a mechanism to allow Wasabi to detect new releases, download them and verify them without having to trust on GitHub's goodwill (because we don't trust GitHub or any other centralized big tech service provider—yes, yes, we use Nostr for that). The next version will be the first in which Wasabi will be able to synchronize without having to connect to any central server, just connecting to an RPC node with compact filters. The next version removes the concept of backend; instead, there is only an indexer, a server component that provides Wasabi compact filters and/or standard BIP158 filters. This is a super cheap piece of software that can take standard BIP158 filters from your node, cache them, and provide them to clients in a way that Wasabi clients understand. The next version gets filters from RPC, blocks from RPC, fee rates from RPC, and broadcasts transactions using RPC, which allows users to use Wasabi without needing to use anything from anywhere or anyone.

There are tons of things that have been redone, redesigned, or changed completely just to facilitate the way to the final goal. It's hard to enumerate them all: a complete redesign of the Tor integrations, a complete change in the technology of serialization, a complete redesign of the Bitcoin node integration, a redesign of the Wasabi configuration (WIP), include the backend and the coordinator in the linux release—all while removing more than 25,000 lines of code.

Very few can compete against Wasabi in this regard because Wasabi is an idea, an ideologically-driven commitment of volunteers doing what they think must be done and risking what nobody else wants to risk in order to do good.

Update: here you have what guides the development:

* https://github.com/orgs/WalletWasabi/discussions/13661
* https://github.com/orgs/WalletWasabi/discussions/13796

[JollyGood]

Great to read a post from a Wasabi developer.

The Wasabi development team have put a lot of effort in to carrying the wallet forward, that cannot be denied therefore the development team deserve a lot of credit. I think manually selecting a coordinator of your choice is a big advantage to have over competitors and the option for manual coin selection to spend is another huge step alongside the other milestones you mentioned.

As zkSNACKs is no longer part of the project, those that abandoned it previously because of the implementation of blockchain analysis will probably return to it at some stage (if they already have not) as they become aware Wasabi Wallet has nothing to do with zkSNACKs.

Wasabi dev here.

Wasabi development has been focused on guaranteeing the survival of the wallet almost exclusively since zkSNACKs abandoned the project. This means changing an originally centralized, trusted, client-server architecture to a standalone, trustless piece of software with decentralized services run by volunteers. In other words, the goal is to completely redesign Wasabi's architecture to eliminate central points of failure and protect Wasabi users and volunteers.

However, users need a reason to upgrade their Wasabi clients other than a "better architected" wallet; they would upgrade only if Wasabi has something new and better to offer them than their current version. That's THE reason why Wasabi releases include support for receiving Taproot, Silent Payments, manual coin selection to spend, SLIP39, support for new hardware wallets and others alike—things that are not a priority at all but allow the development to move release after release, removing dependencies from centralized services and achieve eventually the biggest goal.

[Wind_FURY]

As zkSNACKs is no longer part of the project, those that abandoned it previously because of the implementation of blockchain analysis, will probably return to it at some stage (if they already have not) as they become aware Wasabi Wallet has nothing to do with zkSNACKs.

?

Who will "return"?

Because it's an actual Open Source project, ANYONE is welcome to contribute code during their spare time though, no? Including former zkSNACKs employees whether they choose to be anonymous developers, or actually let everyone know who they are and their past affiliation with zkSNACKs.

I believe Bitcoin Core developers could receive grants from different organizations and from Bitcoin companies/services as well.

[JollyGood]

All the people that had used Wasabi Wallet in the past when it was owned by zkSNACKs but abandoned it in favour of other coinjoin providers or mixers because they were against the implementation of blockchain analysis will probably return to download the latest version to at least test (if not use regularly).

Now that zkSNACKs are not involved in Wasabi Wallet and there is no blockchain spying taking place, it should change the decision made by those that stopped using it in the first place.

?

Who will "return"?

[Wind_FURY]

All the people that had used Wasabi Wallet in the past when it was owned by zkSNACKs but abandoned it in favour of other coinjoin providers or mixers because they were against the implementation of blockchain analysis will probably return to download the latest version to at least test (if not use regularly).

Now that zkSNACKs are not involved in Wasabi Wallet and there is no blockchain spying taking place, it should change the decision made by those that stopped using it in the first place.

?

Who will "return"?

The user. I thought you were saying the developers. But OK, it wasn't a problem before zkSNACKs stopped developing Wasabi Wallet though, no? As I have debated before, the people in the community who didn't like zkSNACKs' trade-off could start their own coordinator. People had the right to criticize zkSNACKs, that's understandable, BUT it was NOT right, technically, to tell everyone to stop using Wasabi Wallet.

Tell them to stop using zkSNACKs' coordinator because they're working with blockchain analytics, or any coordinator that works with blockchain analytics. But practically, they're good to have "clean" outputs. If you have "tainted" UTXOs, this might work - Send your tainted UTXOs to yourself through the Lightning Network, then CoinJoin through a coordinator that works with blockchain analytics.

[JollyGood]

I do not know at which stage Wasabi Wallet (whilst owned by zkSNACKs) allowed external coordinators to be selected but the idea it was wrong for any member (you did not mention names) to advocate others to stop using Wasabi Wallet as being technically wrong is a debate that will be about matters of opinion. If any coinjoin service uses/employs blockchain analysis, they should not be used.

Average people with zero technical knowledge could not start their own coordinator and even if they had the skills to do so, they would not keep their service open indefinitely if there was a lack of traffic. Having said that, zkSNACKs has nothing to do with Wasabi Wallet and the current developers are not using blockchain analysis.

But OK, it wasn't a problem before zkSNACKs stopped developing Wasabi Wallet though, no? As I have debated before, the people in the community who didn't like zkSNACKs' trade-off could start their own coordinator. People had the right to criticize zkSNACKs, that's understandable, BUT it was NOT right, technically, to tell everyone to stop using Wasabi Wallet.

Tell them to stop using zkSNACKs' coordinator because they're working with blockchain analytics, or any coordinator that works with blockchain analytics. But practically, they're good to have "clean" outputs. If you have "tainted" UTXOs, this might work - Send your tainted UTXOs to yourself through the Lightning Network, then CoinJoin through a coordinator that works with blockchain analytics.

[Wind_FURY]

I do not know at which stage Wasabi Wallet (whilst owned by zkSNACKs) allowed external coordinators to be selected

Peter Todd and other developers were already saying that if some people weren't happy about the trade-off zkSNACKs took, then they could start their own coordinator. I'm not very technical, but I believe users could already change the coordinator in a .config file.

but the idea it was wrong for any member (you did not mention names) to advocate others to stop using Wasabi Wallet as being technically wrong is a debate that will be about matters of opinion.

If any coinjoin service uses/employs blockchain analysis, they should not used.

Or perhaps, just don't use that coordinator.

 ¯\_(ツ)_/¯

Average people with zero technical knowledge could not start their own coordinator and even if they had the skills to do so, they would not keep their service open indefinitely if there was a lack of traffic.

That's a different topic for a different debate, but OK.

[lontivero]

Average people with zero technical knowledge could not start their own coordinator and even if they had the skills to do so, they would not keep their service open indefinitely if there was a lack of traffic.

Right now we are delivering the coordinator as part of the Linux packages, which means that Linux users can start a new coordinator just by typing $ ./wcoordinator and pressing enter. In v2.7.0, I will expose it automatically as an onion service and make sure it detects and connects to the Bitcoin node, if any. The idea is to make it trivial for anyone to run a Wasabi coordinator.

We should not assume all coordinators will be public but rather the opposite. Even a company could run its own coordinator for its own use. Just imagine different company departments making payments to different providers or even paying themselves. They would prefer to pay in coinjoins to avoid revealing each department's budget to other departments and providers.

Imagine you receive donations. You don't want all your donors to know how much everybody else has given or how much they own, and you don't want to let donors know how much you are paying to whom. Having your own coordinator has many advantages over huge public coordinators.

[Kruw]

Check out Wasabi's new video guide! https://www.youtube.com/watch?v=tKwGkR3EcJY

[Kruw]

Wasabi v2.6.0 is out! Check out the release notes here: https://github.com/WalletWasabi/WalletWasabi/releases/tag/v2.6.0

[lontivero]

Wasabi and Bitcoin Knots

Wasabi used to depend on Bitcoin Knots but since v2.6.0 that's not the case anymore. Bitcoin Knots provided an RPC feature that was not available in Bitcoin Core: GetBlock with previous outputs (verbosity 3), which was necessary to create the Wasabi custom compact filters without needing to keep a UTXO set as it did in previous versions. Additionally, both client and server made use of another exclusive RPC, GetMempoolInfo with fee rate histogram, which allowed Wasabi to estimate the fee rate better.

After Bitcoin Core merged the PR that extended the RPC GetBlock to provide previous outputs and the fee histogram was made optional in Wasabi, there is no more need for Bitcoin Knots. These changes were done long ago, much before the current discussion about OP_RETURN, and the reason behind them is purely technical.

Wasabi also redistributed Bitcoin Knots binaries as part of the Wasabi Wallet installers, something that makes no sense anymore in v2.6.0. Even though Wasabi v2.6.0 installers still come with Bitcoin Knots, why? Well, because the release was done while the OP_RETURN discussion started warming up, and we didn't want users to misinterpret our motives (You can see removing Knots was discussed months ago: https://github.com/orgs/WalletWasabi/discussions/13796).

The next Wasabi release will not redistribute Bitcoin Knots binaries because it is not a required dependency anymore and because Wasabi devs are not the ones to decide on behalf of Wasabi users what Bitcoin node they have to use.

[NotATether]

Wasabi used to depend on Bitcoin Knots but since v2.6.0 that's not the case anymore. Bitcoin Knots provided an RPC feature that was not available in Bitcoin Core: GetBlock with previous outputs (verbosity 3), which was necessary to create the Wasabi custom compact filters without needing to keep a UTXO set as it did in previous versions. Additionally, both client and server made use of another exclusive RPC, GetMempoolInfo with fee rate histogram, which allowed Wasabi to estimate the fee rate better.

After Bitcoin Core merged the PR that extended the RPC GetBlock to provide previous outputs and the fee histogram was made optional in Wasabi, there is no more need for Bitcoin Knots. These changes were done long ago, much before the current discussion about OP_RETURN, and the reason behind them is purely technical.

Getblock with previous outputs is good. Now I can do things like checking the source address of the transaction without having to store several hundreds of megabytes of UTXOs in-memory, many of which are just OP_RETURNs or some kind of Ordinal anyway.

[btc-freedom-money]

wasabi cold wallet with VM possible?
In the wasabi docs I got my hopes up for a moment that it's possible to transfer some kind of file which is then signed then transferred back. But it seems that is only used with coldcard.
I would have liked if it's possible to transfer that file to another VM and then sign it there and then transfer back to the first VM again. The first VM is wasabi hot wallet and the second wallet is wasabi cold wallet which is the same software but the VM doesn't have an internet connection which makes it a cold wallet.
But is this possible with Wasabi?

Also is there really no way to do multi signing? It  would be great to be able to multi sign on different devices. Multi signing is the most secure feature a wallet can have because it protects against both hackers and robbers with threat of violence. The biggest threat then would be a vulnerability or back door in wasabi wallet.