Topic: [BitcoinTalk Node Tutorial #3] Sparrow terminal / infinite Whirlpool mixes (Read 568 times)

This tutorial is not longer valid.
Since Sparrow 1.9.0 the mixing feature is no longer supported.

Hi all!

I have made this post before I decided to create my series of tutorials for my BitcoinTalk node.

However it is a great candidate for my 3rd tutorial, so I changed the title and I linked it with my previous tutorials.

That's my point:  Attackers only have to pay for block space once to enter Whirlpool in order to participate in infinite Sybil attacks.  With WabiSabi, mining fees create an economic defense against Sybil attackers because they would have to incur a continuous cost to attack each round.


Generating change outputs is not inevitable when using Wasabi, you can pay your destination directly within a coinjoin transaction and never receive change.


You can coinjoin any amount with the WabiSabi protocol, zkSNACKs' coordinator sets a 5000 sat minimum, but that's an arbitrary setting for DoS protection, there's no fundamental reason why a UTXO would get "too small to coinjoin".  There's even an extra tool in Wasabi to precisely eliminate change when spending outside of a coinjoin: https://twitter.com/wasabiwallet/status/1664718704628645890


I know it's hard to believe that all participants have the same sized UTXOs, but you can verify with your own eyes that they actually do:


Even if you have some non standard amount like 0.09698481 as an output like the coinjoin above does, there's no way to determine if it is a payment, if it is change, or which inputs created it.


Since we have no reason to believe that the round was Sybil attacked, then it's best not to assume it was deanonymized based on a guy from Twitter saying "it looks like".


WabiSabi provides more privacy than Whirlpool because even UTXOs that do not have identical values to yours contribute to the crowd you are hiding in, not just the ones that have identical values.  There are 195 outputs containing a total of 44.125 BTC in the attacker's transaction, so it's even possible that the attacker with the 12.475 BTC input created zero out of the 3 outputs for 5.36870912 BTC because all of his coins were split into addresses containing smaller amounts.

This is why guessing one possible outcome without ruling out the others and calling it "deanonymization" is bad: Since there's no consequences to the accuser for accusing, why not make the accusation?


Common ownership is revealed from Whirlpool's premix transactions, I never claimed common ownership is revealed "once you enter Whirlpool".


Users of WabiSabi are never faced with this decision because they can send their payments directly in a coinjoin so they never encounter change.  Even if you had change because you spent coins outside of a coinjoin, you can always coinjoin your change.

The same can not be said with Whirlpool because you always get stuck with traceable Bitcoin no matter what you do. You cannot send a payment directly in a Whirlpool coinjoin unless the recipient wants an amount of exactly 0.5, 0.05, 0.01, or 0.001 BTC.  You also can't coinjoin change below 0.001 BTC.


Thanks for the responses, Wasabi being private by default finally puts an end to the need for these sorts of guides since all you have to do to transact anonymously is "Receive, wait, send".

You still have to pay to enter whirlpool and the anon set gets bigger over time.

Generating change outputs is inevitable when using Wasabi. There's no way that all participants have the same sized UTXOs. Eventually UTXOs get too small to coinjoin in wasabi and they become doxxic.

If chain analysis companies sybil attacked the Wasabi mix, then it's not just some guess. Additionally anyone else could could have sybil attacked the mix. UTXOs sizes are identical in any given whirlpool pool so I am not sure how Wasabi provides more privacy when only 2 other UTXOs are identical.

Once you enter whirlpool, common ownership is not revealed.

This is a user decision. The same can be said of Whirlpool. If you generate change, you can CoinJoin in a smaller pool. Once a UTXO gets small enough, it becomes too small to CoinJoin.  


This thread has grown to become unmanageable for me. I am glad that you like Wasabi. I hope it is as private as you seem to think it is. I will revisit Wasabi and see if there is any value that I can get out of it.
 

A blockchain analyst can't Sybil attack Wasabi's for free like they can with Whirlpool's coinjoins.  In Whirlpool, Sybil attack victims pay the mining fees for Sybil attackers.  In WabiSabi, Sybil attackers have to pay for their own mining fees.


The same post-mix practices are not "just as possible" when you use Wasabi because there is no peeling chain created by change and there is no common input ownership revealed.  


Where is the deanonymization?...  You are the SECOND person to use this example as "Wasabi being de-anonymized" when the only proof is a guy on Twitter saying "It looks like" and guessing the only coinjoin exit tx that's a payment without ruling out the coinjoin exit txs that are remixes: https://twitter.com/ErgoBTC/status/1723700744576971012


I have no doubt law enforcement will be happy to freeze his coins based on their distaste for Bitcoin anyways, but this suspicion is not based on conclusive proof since the spent UTXO accused of belonging to the attacker was created alongside 2 identical UTXOs with the same value in the coinjoin, making it merely a guess.  I would make the same guess based on script analysis, timing analysis of peers, amount analysis, and destinations of premix and postmix funds, but this sort of "shooting in the dark" style approach of layering multiple non deterministic heuristics will eventually create collateral damage.


So what?  When you merge inputs in a coinjoin, common ownership isn't revealed.


If you decide to generate change by making a payment outside of a coinjoin instead of inside of a coinjoin, you can just still just coinjoin the change instead of creating a peeling chain.  
 

I admire your pessimism, but the WabiSabi coinjoin protocol is "magic" and actually did fully solve Bitcoin privacy because you are no longer dealing with the nature of UTXOs, you are dealing with the nature of ecash style cryptography: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020202.html

With WabiSabi, you can even perform a Bitcoin payment so privately that the sender is not even aware of the address of the receiver: https://twitter.com/MrKukks/status/1619294492854747138


WabiSabi coinjoins don't create any doxxic change at all, "traceable leftovers" are fully eliminated for anyone who isn't the biggest whale in the transaction.  That's why Whirlpool's coinjoins are flawed and WabiSabi coinjoins are not.


Yes, I've contributed to Wasabi.  I contributed to Samourai as well, but my bug reports were deleted: https://bitcointalksearch.org/topic/2-new-bug-reports-deleted-from-samourai-wallets-gitlab-repo-5471645

Chain analysis companies can sybil attack Wasabi mixes as well. All that is necessary is to control x number of inputs but I don't think they need even waste energy doing that since all of the same bad post-mix practices are just as possible when you use Wasabi.

On top of that, there's multiple instances of Wasabi mixes being de-anonymized by normal bitcoiners without access to industry level chain analysis tools. The recent hack on Rick who lost 25 bitcoin for storing his coins in a password manager has had help from the bitcoin community to track down some of his coins to Binance. https://twitter.com/RMessitt/status/1724135148055097364

I'm sure chain analysis can easily follow the rest with all of their tools.   

---
Address clusters and peeling chains are absolutely possible with Wasabi.
- If you ever try to spend an amount greater than a single UTXO, you need to merge inputs.
- If you spend less than a single UTXO, then change is generated which give birth to the beginning of a peeling chain.
- If you don't use this change UTXO, then you have a UTXO that sits idle forever and Wasabi has a "dust bug" or "tracable leftovers" as you've called it. 
 
Acting like your privacy cannot be compromised when mixing with Wasabi is blatantly false. They aren't magic. They may offer some privacy in certain instances but not as much as you seem to believe. The user of any wallet needs to be aware of basic privacy practices. Address clusters like merging inputs and peeling chains are unavoidable. That's the very nature of UTXOs. 

"traceable leftovers" is a misnomer. Any UTXO can be "traced". You're conflating a bad privacy practice with a mixer "flaw". It's not an accurate comparison. There are plenty of users who don't merge their doxxic change. I know multiple people who use whirlpool and never merge doxxic change outputs and thus they never create address clusters or peeling chains. There's multiple ways to spend CoinJoin change without doxxing yourself: https://www.whatisbitcoin.com/privacy/spend-coinjoin-change

Your concern about Tor is reasonable but OP is broadcasting though their own node which runs behind Tor so it's not an issue. It seems like you're just here to flex on the OP and tout Wasabi as better than Whirlpool.

Are you affiliated with Wasabi?

I am not spreading FUD, address clusters from common input ownership and peeling chains from leftover change ARE unique to Whirlpool coinjoins.  

You are spreading FUD about Wasabi's coinjoins because common input ownership is not revealed, and peeling chains are not produced (unless you are a whale with more coins than all the other participants), and there is no coin control necessary.  Anyone can verify this is FUD by simply looking at the Bitcoin blockchain:


Whirlpool does not provide this sort of complete privacy for your entire funds like Wasabi does.  You always generate traceable leftovers:




No, I'm not being disingenuous, people following the guide will automatically be deanonymized since they are not using Tor.  The worst possible outcome is that people get a false sense of security (and pay sats for it!)

This is FUD. Address clusters and peeling chains are not unique to Whirlpool CoinJoins. The exact same thing can happen with Wasabi mixes (which you are obviously here to shill) without proper coin control practices.

I followed all of the txs you mentioned and you're right. They are linked to each other via a peeling chain but that doesn't mean that the common ownership heuristic doesn't apply to Wasabi txs after they get mixed. Not using adequate coin control practices can absolutely result in txs being linked together but that has nothing to do with Whirlpool specifically.

I think you're being a bit disingenuous with your response and are more interested in flexing on OP while you tout Wasabi in your signature and website link. 

Answer to o_e_l_e_o for the question above:

It didn't work. For some reason I am unable to create the whirlpool accounts for an airgapped wallet. I could only add accounts 1 - 9. I scrolled down but there is no "whirlpool accounts" option, whereas for a hot wallet the option was there.

So I did something else. I created a hot wallet in Samourai with the Whirlpool Accounts enabled. I sent some sats and it made some coinjoins. So, I had 3 UTXOs in my Postmix account with some mixing rounds each (3, 5, 6 respectively).

Then I created a hot wallet in Sparrow with the same seed phrase. Indeed there were 3 UTXOs in Postmix, so I pressed "Start Mixing" and it started all over again. Now, my UTXOs have more mixes (4,5,7 respectively).

So, this workaround worked, but the original approach you mentioned didn't work for me.

I will try it and I will update this post as soon as I have an answer.

So let's say I create an airgapped Sparrow wallet, set it up to be a coinjoin wallet so it creates the usual four accounts, and then from my hot Sparrow wallet mix coins directly to the xpub of the cold postmix account. A year later if I bring that cold Sparrow wallet online, then the previously coinjoined UTXOs will already be in the postmix account. Would Sparrow detect that and allow me to continue to coinjoin them?

You can add the four accounts manually by opening your wallet, clicking on the "Settings" tab, clicking "Add Account..." and scrolling down to "Whirlpool Accounts".

Yes, but then you would have to pay the pool fee and the Tx0 fee again, which would necessitate you either joining a smaller pool or consolidating some UTXOs together to stay in the same pool, which negates the point of doing this in the first place. I want to keep coinjoining as if nothing has happened.

No I have only tried importing the seed phrase to the existing wallet.

Obviously you can start a new wallet (hot software wallet) and start fresh adding the seed phrase. This can potentially work. I expect the utxos to be in the deposit account. If they are there then of course you can coinjoin a bit more

Shouldn't the software know how to generate the individual private keys based on the seed you imported into it? Have you tried importing a master private key or individual private keys (if it's possible) to see if you will be able to sign the transactions then?

I don't think so. Here is why...

In order for this to happen, adding the seed phrase should create 4 accounts (deposit, premix, postmix, badbank) and send the coins to the deposit account. I think the deposit account lives under the default derivation path, so technically perhaps it wouldn't need to "send" the coins to this account because this is also the default derivation path for the cold wallet.

Now, let me share my own experience, because I have tried something very similar.

I think you have actually found a "bug" here.

I have added the seed phrase to a cold wallet I had and it didn't generate the 4 accounts. When I imported my seed phrase, it didn't actually become a hot wallet. I was unable to sign transactions without using my HW. Essentially, I had a hot wallet where I could see the seed phrase, but I couldn't use it as a hot wallet. I had to sign using my HW instead.

Give it a try, I think it will behave exactly as I mentioned above.

Here's a question I haven't been able to find a straight answer to - can you bring the cold storage online and continue remixing for free?

Let's say I generate a new wallet on my airgapped computer, import the relevant xpub in to Sparrow, and mix a few coinjoin outputs to this cold wallet. A year later, I want to spend these coins, but I want to coinjoin them a bit more first. Can I import the seed phrase for this cold wallet in to Sparrow (making it a hot wallet), have Sparrow detect the UTXOs as coinjoin outputs, and pick up exactly where they left off and keep remixing?

By the way, I have tried something more.

I have added my Cold PubKey on Sparrow and I have set my PostMix UTXOs to automatically send there after several rounds of mixing.

More specifically I have:

1. imported my XPUB on another wallet in Sparrow
2. gone to the Postmix UTXO tab in my hot wallet and pressed "mixing to..." button. I have set a value of 20 mixes. This translates to "send to the other wallet once the utxo has 20 mixes or more".

Using those steps above you can literally set it and forget it.

The only thing you have to do is send funds to a Deposit address and the whole process is done automatically.

Currently my mobile experience with Bitcoin is:

Sentinel  I have some addresses in Sentinel and I use them to receive funds (on the go). Those are addresses from my cold storage wallet. I could also monitor the XPUB of course, but I didn't want to. I only have 10 - 20 addresses ready to be deployed in case I need to receive funds.

Zeus I use Zeus to connect to LND node (CLN is also available of course). I like Zeus because it is mandatory to connect to own node in order to use it, so it helped me privacy-wise. Also the main dev is very approachable and we had a small conversation once (not too technical). The main reason why I use it is for LN transactions. I don't manage my channels with it.

I have tried Samourai and I have used it for a while (connected to my Dojo). I liked it very much, but for several reasons I don't want to have an on-chain bitcoin wallet on my phone.
In general, when "on the go", I need to have super minimal functionalities. I try to minimalise most of my everyday clutter (I hope this word makes sense here). I only need to pay fast or receive fast. I can pay fast with LN and receive fast both on-chain and on LN. So my set-up is very convenient so far. Of course being connected to my node is a must for me.
 

Ok, that's an even better set up.

Do you also use Samourai on the go while pointed at your Dojo? Or do you just use Dojo for Sentinel?

Did you check the logs to find out what was going on?

That's pretty much the opposite of my experience. I was pretty taken aback when I first installed Sparrow at just how easy it was to connect to my own node on the same device. Literally one click on the button which says "Bitcoin Core" in Sparrow and it was done. It's a little bit more involve to connect it to your Electrum server or a node/server on a different machine, but I've still gone through those processes several times with different machines and OSs without ever having too much trouble.

There's a huge problem with "endless free coinjoins" - Sybil attackers get endless free coinjoins as well.  As you might imagine, Chain analysis companies attacking the coinjoin pool disproportionately benefit from these free remixes because they have a lower time preference than real Bitcoiners that actually transact.

In the past when I ran Sparrow Wallet from the command line, or at all really, I had issues getting it to connect to anything. There was no firewall running. With a Bitcoin node, the connection would not get established, and the same thing happened with public Electrum servers but that must have a more obscure reason.

I had never tried connecting a private server to it, though.

So Sparrow is a pretty good wallet, once you get the connection working first.

Thanks. Who said I don't run my own mempool instance?  I do run my own mempool instance

I run 2 nodes, to be honest. Specifically:

1. I run Umbrel on an RPi. There I run btc core + electrs + dojo + robosats + LND (which I plan to remove soon) + my own mempool instance

2. I run Raspbian Lite (no GUI) on an RPi. I wanted to have clean custom setups here. So, for now, I run btc core + electrs + Sparrow + CLN (which doesn't work as expected but I don't have time to figure out what's wrong)

Next steps:
0. I will properly install Tor on the second RPi. The first node (umbrel) works with TOR as expected.
1. I want to remove LND forever
2. I want to properly install CLN
3. I want to install mempool instance on the second node.

First you'll need to install and run a Tor daemon on your Raspberry Pi.

Inside the Sparrow terminal, go to to Preferences -> Server -> Edit, and then select whether you are using Bitcoin Core or Private Electrum. Select Continue. On the next screen go down to "Use Proxy?" and select "Yes", in "Proxy URL" put 127.0.0.1 on port 9050. This will route all external Sparrow traffic via Tor.

---

Excellent set up, by the way. Your own node, own Electrum server, Sparrow, all via Tor, for endless free coinjoins. Which Electrum server package are you running on your Raspberry Pi? Next up you'll want your own instance of https://github.com/mempool/mempool.

Thanks for the info. It doesn't affect the tutorial itself though. Any addition is welcome, so If you have any technical details, let me know and I can add them to the OP.

You would not gain any privacy with this method if you do not enable Tor, the Whirlpool coinjoin coordinator can simply link your inputs to your outputs for every mix by looking at the IP address that registered them.

And unfortunately, Whirlpool coinjoins reveal common input ownership and create toxic change that can be used to track your future transactions:

Good tutorial.

One suggestion:  You can use systemd to start Sparrow as a daemon on system startup, eliminating the need to start it manually.

This tutorial is no longer valid.
Since Sparrow 1.9.0 the mixing feature is no longer supported.



Links to other tutorials from the series:
[BitcoinTalk Node Tutorial #1] Running Bitcoin Core on Raspbian Lite (GUI-less) https://bitcointalksearch.org/topic/bitcointalk-node-tutorial-1-running-bitcoin-core-on-raspbian-lite-gui-less-5476754
[BitcoinTalk Node Tutorial #2] Installing Electrs from source https://bitcointalksearch.org/topic/bitcointalk-node-tutorial-2-installing-electrs-from-source-5477339
[BitcoinTalk Node Tutorial #4] Connecting BISQ to our node https://bitcointalksearch.org/topic/bitcointalk-node-tutorial-4-connecting-bisq-to-our-node-5478756
[BitcoinTalk Node Tutorial #5] Hosting a Monero node on the same machine https://bitcointalksearch.org/topic/bitcointalk-node-tutorial-5-hosting-a-monero-node-on-the-same-machine-5480371

---

Sparrow terminal / infinite Whirlpool mixes

Installing Sparrow
Steps:

Find the proper version for our architecture and download with wget:


Install the deb file using the command:

By default, the Sparrow binary will be in

---

Running Sparrow
Note:
Using ssh can be tricky. If you initiate a session, start sparrow and then close ssh, it will close sparrow too. So we will use the "screen" command. If it is not installed, run:

Steps:
Run screen command:

Navigate to the path mentioned above ("/opt/sparrow/bin") and run Sparrow.

It will load the following screen:


Insert the preferences tab and go to server:


Then choose the option you desire for the node to which you wish Sparrow to be connected. Personally I run Sparrow on the same linux device as my node, so it looks like this:


Then head back to the wallets tab and click on it:


Click on "Create wallet":


Go to the "Deposit" tab:


It will give you an address where you can send your funds:


Go to the UTXO tab and click on "Mix Selected"


Once the process goes further, head back to "Postmix" tab:


There, you will be presented with your UTXOs



Final Steps
Click: this will get you out of the Sparrow app and it will leave it running on the background.

Whenever you decide, you can enter
Sparrow will be presented to you exactly where you left it and you can enjoy your free mixes.