pull down to refresh
42 sats \ 1 reply \ @lontivero 12 May \ parent \ on: Wasabi Wallet v2.6.0 released w/ SLIP39 multi share support bitcoin
Your question is not about Wasabi but about Umbrel and how to expose the Bitcoin Node RPC. I don't know how your infrastructure is configured but if you have your node's RPC enabled and the RPC port is opened in your Umbrel then you should be able to connect to it and you could test the connection using bitcoin-cli. My suggest to ask to Umbrel team/community how to expose the RPC.
Finally, Wasabi requires compact filters from your node if you want to synchronize and operate without using any external filters' providers. That means that you have to enable the creation of compact filters in your node.
Once you install the bitcoin node and enable the rpc interface, lunch Wasabi and it will detect your node.
Wasabi was developed by a company which closed its doors last year. Since then, a tiny group of volunteers took the responsibility to continue with the project and has been focused on guaranteeing the survival of the wallet. 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 still to completely redesign Wasabi's architecture to eliminate central points of failure and protect Wasabi users and volunteers.
Even though every release highlights user-oriented features such as Silent Payments, SLIP39, support for newer hardware wallets, and similar improvements, the most important changes are structural. These changes allow others to run coordinators, backend servers, or both. It also allows Wasabi to synchronize and operate without a central server by connecting to your own node.
The next goal for the team is to shut down the backend and let others host tiny indexers that users can connect to.
If you are interested, I explain all this a bit better in the Bitcoin Talk forum thread I posted: https://bitcointalk.org/index.php?topic=5476197.msg65272894#msg65272894
I strongly recommend using Wasabi as a privacy-oriented wallet and not as a mixer.
This means that you should welcome both large chunks and smaller amounts (10k, 20k sats) because this increases your capacity to make payments privately and avoid change.
Having a variety of denominations makes it much easier to find combinations of coins for payments you need to make. Even if Wasabi can't avoid creating change for your transaction, only a tiny portion of your wallet will be known by someone else, and the labeling system (in my opinion, the most powerful tool in Wasabi) will help you avoid leaking more information to others.
Having very few coins, or in the extreme case only one coin, is a privacy nightmare. This means that whatever payment you need to make will involve a large portion of your wallet, which also means you cannot avoid change, and then your future payments will be trackable. For example, a wallet with only one coin generates a peel chain that is trivial to follow.
There are situations where consolidating can make sense, such as when coins are too small and you fear they could become unspendable or too costly to spend, but in general, it is not the best approach for privacy.
The "Wasabi is a mixer" mentality consists on sending to Wasabi, participate in many coinjoins and then consolidate everything to send it to a non-privacy-focused wallet. Do not do that.
Okay okay, if you want/need to do it then there are a couple of ways to do it to mitigate a bit these problems:
- Coinjoin to another wallet: Wasabi can send your coins in a coinjoin to another wallet. In this case it tries to use as much coins as possible (never more than ten) and send that amount to a different wallet in a set of outputs. It doesn't do a big consolidation but it at least doesn't generate much outputs
- Pay in coinjoin: It requires a few command lines but it is a super powerful tool that allows you to send money in a coinjoin where you are the one who specify the amount of the output. Here you can see a donation to El Salvador bitcoin address in a Wasabi coinjoin: https://mempool.space/tx/8c58beccc25acc763c528515b3a23bb92eeb6dc41b519ef681f76dfcc76cc19d#vout=433
Blockchain.com displays an address for a p2pk script.
> let pk = PubKey "048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd";;
val pk: PubKey =
048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
> pk.GetAddress(ScriptPubKeyType.Legacy, Network.Main);;
val it: BitcoinAddress =
1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9
{Hash = c22eb0572ca07b9db7eff8ae5447f68d17f63535;
Network = Main;
ScriptPubKey = OP_DUP OP_HASH160 c22eb0572ca07b9db7eff8ae5447f68d17f63535 OP_EQUALVERIFY OP_CHECKSIG;
Type = PUBKEY_ADDRESS;}
Let me translate the vulnerability report here: wasabi coinjoin client implementation had a bug that made it trust on the coordinator as samourai whirlpool does. The difference is that in Wasabi is was because a bug while in whirlpool it is by design.
GENESIS