[Feature request] Bump the speed of remixes

[Cyberwiz9000]

Problem: The speed of the initial mix is pretty fast, the speed of remixes can take ages. Goal: To gain reasonable privacy in a reasonable time and then store my coins in cold storage multisig.

As I understand, this is at least partly a Whirlpool issue, however perhaps Sparrow devs could make a workaround or collaborate with Whirlpool devs.

So for the initial mix you pay a fee and the initial mix get's priority over remixes. This way the initial mix gets done a lot faster. Remixes are free, so that is a nice feature. However remixes can take ages to complete. I don't like it when my coins are vulnerable in a hot wallet while they are mixing, not to mention my computer has to stay online and I don't have the security of multisig when mixing.

Let's say I want 3 mixes, it would be nice to be able to choose to pay a fee for 2 initial mixes, speeding up the process a lot. After the 2 initial mixes the coins can go back to postmix for 1 more free mix.

I'd like to hear from anyone if this idea is feasible and if so, how much could be done in Sparrow itself without touching Whirlpool.

Finally, thanks to all the devs for the hard work being done.

[RequestPrivacy]

I think you're missing the point by miles - to say it politely. I suggest you try to understand the design of whirlpool first. Good resources can be found here and here.

After reading these two articles I think you will appreciate the way whirlpool is implemented a bit more and maybe come to a different conclusion to the one given above.

That being said, I'm in no way a dev of Sparrow wallet and want to emphasize that this is just another users perspective.

[Transisto]

One possible reason why remixes are slower than they could be is that some users run a modified client that register multiple outputs via multiple tor connections. There is zero evidence of this happening but there's AFAIK no way to eleminate this kind of "cheating" with how whirlpool works. Joinmarket is working on fidelity bonds to incentivize the uniqueness of the entity you're mixing with.

[RequestPrivacy]

I don't follow @Transisto: do you suggest that somebody is sybil attacking by having multiple instances or that a person just tries to increase his "count" unfairly? Bc the later point would be kind of stupid, since the count is a very bad proxy for "anonset gained".

[Transisto]

I don't follow @Transisto: do you suggest that somebody is sybil attacking by having multiple instances or that a person just tries to increase his "count" unfairly? Bc the later point would be kind of stupid, since the count is a very bad proxy for "anonset gained".

Since there is supposed to be no association between any of your UTXO after the first mix, all of your outputs could be registered independently for remix.

The fact that sparrow and samourai client allow you to only register a single UTXO per pool is a completely artificial limitation. Either someone could run many instances or they could modify the open-source code to remove that limit.

[Cyberwiz9000]

I think you're missing the point by miles - to say it politely. I suggest you try to understand the design of whirlpool first. Good resources can be found here and here.

After reading these two articles I think you will appreciate the way whirlpool is implemented a bit more and maybe come to a different conclusion to the one given above.

That being said, I'm in no way a dev of Sparrow wallet and want to emphasize that this is just another users perspective.

I had read these articles before, but to make sure I have read them again. I have come to the same conclusion, I don't see why my OP is missing the point.

I will quote here from the article you have linked:

For a coinjoin mix to happen, there needs to be 2 to 3 premix UTXOs in each transaction. This ensures that the entropy remains high, and we are not simply mixing the same coins with each other over and over, which would provide little benefit. In addition, the premix UTXOs provide the miner fees for the transaction.

There are generally many more postmix UTXOs than premix UTXOs available to the pool. In practice, this means that your premix UTXOs will usually be mixed to postmix quickly, but once in the Postmix wallet it may take awhile before a postmix-to-postmix transaction happens. Selecting postmix UTXOs for remixing is done at random and therefore subject to variance - you might get several mixes in a short period, or wait a day for progress. Leave Sparrow open in the background (note the Minimize to System Tray functionality in the View menu) and postmix transactions will occur as the UTXOs get selected into a round. Note also that random periods between mixes helps break pattern analysis.

So it is clear that it takes a lot longer to remix because the target is to have at least two premix UTXOs in the pool. My question/suggestion was to make it possible to do for example 2 "initial mixes" and after that let it do the regular remixes for free. My thought was that this would be a trade-off: a faster, more expensive remix with a bit less privacy improvement compared to a regular free remix.

Now this is an idea, I have seen many complaints about how slow the remixes are in Whirlpool, but I haven't come across suggestions to fix it. If there is a similar discussion going on already I apologize, if not, and people can explain me how this is not possible, or give other workarounds, that is fine as well.

[Cyberwiz9000]

One possible reason why remixes are slower than they could be is that some users run a modified client that register multiple outputs via multiple tor connections. There is zero evidence of this happening but there's AFAIK no way to eleminate this kind of "cheating" with how whirlpool works. Joinmarket is working on fidelity bonds to incentivize the uniqueness of the entity you're mixing with.

That may be possible, but premixes are prioritized over remixes in the protocol, as I mentioned above, so we don't have to look further than that for now imho.

[Cyberwiz9000]

since the count is a very bad proxy for "anonset gained".

Okay, so now you lost me completely here, if there is no gain in anonset gained from remixing

I don't follow @Transisto: do you suggest that somebody is sybil attacking by having multiple instances or that a person just tries to increase his "count" unfairly? Bc the later point would be kind of stupid, since the count is a very bad proxy for "anonset gained".

Assuming that by "count" you mean the number of mixes, the articles you mentioned clearly states that more mixes means a better anonset, and that was also my understanding before. So am I misunderstanding you or what am I missing?

[Cyberwiz9000]

I don't follow @Transisto: do you suggest that somebody is sybil attacking by having multiple instances or that a person just tries to increase his "count" unfairly? Bc the later point would be kind of stupid, since the count is a very bad proxy for "anonset gained".

Since there is supposed to be no association between any of your UTXO after the first mix, all of your outputs could be registered independently for remix.

The fact that sparrow and samourai client allow you to only register a single UTXO per pool is a completely artificial limitation. Either someone could run many instances or they could modify the open-source code to remote that limit.

Hmm, perhaps I should just run more instances of Sparrow so I can mix faster :)

[Transisto]

One possible reason why remixes are slower than they could be is that some users run a modified client that register multiple outputs via multiple tor connections. There is zero evidence of this happening but there's AFAIK no way to eleminate this kind of "cheating" with how whirlpool works. Joinmarket is working on fidelity bonds to incentivize the uniqueness of the entity you're mixing with.

That may be possible, but premixes are prioritized over remixes in the protocol, as I mentioned above, so we don't have to look further than that for now imho.

That's not possible with how whirlpool works. The first mix is not the same as remix, Because the coordinator fees and network fees are to be taken out of the extra amount set by the premix.

Remix are free and 3/5 of participant in a mix have to be remix. There is thus an imbalance that slows things down. I've been running a rpi remixing for about two years 24/7, Should I feel bad for using free remix? No because it's providing liquidity to someone wanting mix large amount with as many unique participant.

Anyway whirlpool seems to be working at providing privacy, but I'd never trust the privacy of a single mix and remixes take an inconvenient amount of time. Adjust your time preference accordingly.

[Cyberwiz9000]

One possible reason why remixes are slower than they could be is that some users run a modified client that register multiple outputs via multiple tor connections. There is zero evidence of this happening but there's AFAIK no way to eleminate this kind of "cheating" with how whirlpool works. Joinmarket is working on fidelity bonds to incentivize the uniqueness of the entity you're mixing with.

That may be possible, but premixes are prioritized over remixes in the protocol, as I mentioned above, so we don't have to look further than that for now imho.

That's not possible with how whirlpool works. The first mix is not the same as remix, Because the coordinator fees and network fees are to be taken out of the extra amount set by the premix.

Remix are free and 3/5 of participant in a mix have to be remix. There is thus an imbalance that slows things down. I've been running a rpi remixing for about two years 24/7, Should I feel bad for using free remix? No because it's providing liquidity to someone wanting mix large amount with as many unique participant.

Anyway whirlpool seems to be working at providing privacy, but I'd never trust the privacy of a single mix and remixes take an inconvenient amount of time. Adjust your time preference accordingly.

So I understand what you are saying, we need the premix/remix system and there is an imbalance which is hard to avoid. I have no issues with the fact that remixes are free, I understand that they provide liquidity.

And yes more mixes is better, my target is at least 3 rounds, if it would be faster I would do more. I like the Sparrow wallet and it is great that Whirlpool supports multiple wallets (Sparrow and Samourai for now afaik).

Now all that being said, I was looking for ideas to speed up my own and everyone else their coinjoins. Both Wasabi and Joinmarket are quite a bit faster (from my testing, experiences may vary).

We all know the issues with Wasabi, and once Wasabi 1.x liquidity dries up, my main coinjoin solution (in pure throughput) will be needing a replacement and I am sure I am not alone. But many old Wasabi users will be put off my the speed of the remixes.

Joinmarket seems a good long term (more decentralized) alternative, but the client implementations are pretty bad right now and the mixes fail too often imho. Perhaps the Sparrow devs could add Joinmarket in addition to Whirlpool, that might be nice.

Anyway, I will continue on my quest for faster coinjoins until then :)

[Cyberwiz9000]

So I have found following workarounds:

• Running multiple instances of Sparrow, just need to create a new wallet for each instance. Looks to be working well.

• Manually move my coins that had 1 mix back into deposit and mix again. This works, but the downsides are: I have to drop to a lower pool in the second manual round (because the fees drop me below the previous threshold). But I have to do this anyway to be able to mix in multiple pools concurrently. After the mixes I have to label them manually so I know how many mixes I did before.

• Using different pool sizes concurrently, works well.

With all of these together it looks like I can speed up the mixes substantially. It would be nice if this could be implement in Sparrow in a more automated way.

[RequestPrivacy]

So for the initial mix you pay a fee and the initial mix get's priority over remixes. This way the initial mix gets done a lot faster.

The initial mix doesn't get "priority" by paying "the fee" or "a higher fee". It is the reason the mix starts in the first place. Like you already discovered and quoted above, it is needed to provide new liquidity. Since the remixers have all equal output utxos, they are also needed to provide the transaction fees for the coinjoin.

since the count is a very bad proxy for "anonset gained".

Okay, so now you lost me completely here, if there is no gain in anonset gained from remixing

Assuming that by "count" you mean the number of mixes, the articles you mentioned clearly states that more mixes means a
better anonset, and that was also my understanding before. So am I misunderstanding you or what am I missing?

Okay lets say you did your first mix. Your mix count sits for days on count 1, what you equate to a anonset of 5 (since that's the number of participants).

What your missing is that one of your mixing peers might have been chosen for a remix. Your anonset increased to 9 without your mix count changing (you hide in a crowd of your utxo, the one of the 3 non mixing peers + 5 for the one who has done a remix, which resulted in 5 more equal outputs in his consecutive coinjoin).

So without you ever getting an increasing mix count your anonset can grow to 5+4*n where 0 <= n <= 4 so maximal 21 (n is the number of peers who participated in your initial mix but had a remix). And that is just the result of TWO layers of coinjoin. The math behind this is like an avalanche: it explodes with time. There's a tool called boltzmann in the samourai repo which can do the math for you and "follow" all possible paths. You'd be surprised how fast it can grow with time.

EDIT: obviously after one mix your minimal anonset isn't necessarily 5 as I suggested above, since your 4 peers could have doxxed themselves already. So could also be 0.

My question/suggestion was to make it possible to do for example 2 "initial mixes" and after that let it do the regular remixes for free.

You would break the equal outputs of whirlpool. (3 equal utxos + 2 unequal premix utxos) go in, 5 equal outputs come out. How do you want to transfer your "speedy" bonus fee to the outputs? After all, if all outputs are equal which one is the one the whirlpool coordinator should "speed up"?

tl;dr: you're missing the point if you think that the mix count is the definite benchmark for your anonset. It isn't. It is a rather bad proxy. You shouldn't aim to increase it a all costs. Since you have 4 coinjoin peers vs your ONE utxo, I'm inclined to think that you should even hope that your peers get a remix, since you can achieve a faster and way bigger anonset if they keep remixing. It's a numbers game and the numbers are better off if you don't view peers as competition but helpful friends.

[Cyberwiz9000]

tl;dr: you're missing the point if you think that the mix count is the definite benchmark for your anonset. It isn't. It is a rather bad proxy. You shouldn't aim to increase it a all costs. Since you have 4 coinjoin peers vs your ONE utxo, I'm inclined to think that you should even hope that your peers get a remix, since you can achieve a faster and way bigger anonset if they keep remixing. It's a numbers game and the numbers are better off if you don't view peers as competition but helpful friends.

Your answers gave me better insights in the way it works. I understood only the very basics, but there is more nuance to it (there always is more nuance and deeper understanding in Bitcoin :) ).

Just to make it clear, I never meant to imply that free remixes were bad or that coinjoin peers are competition, I was just hoping to pay a bigger fee and get the remixes done faster.

It also is a matter of representation, in the Sparrow wallet, the only thing to go on to get an idea how big the anon set is are the number of mixes.

Anyway thanks all for the help and insights.

[RequestPrivacy]

Sorry if I my explanation wasn't the best but it was well after midnight here. Keep on studying and if you have Telegram Messenger hop into the Samourai and Sparrow group. You will gain tremendous knowledge regarding the tools, their incentives and functioning.

It also is a matter of representation, in the Sparrow wallet, the only thing to go on to get an idea how big the anon set is are the number of mixes.

100% on point. The representation with mix counts is a bad one (same applies to Samourai, this isn't Sparrow specific) but all other possibilities are way more computation intensive. So it is born out of the lack of better alternatives.

[RequestPrivacy]

For future reference a newer article explaining whirlpool:

Track Me If You Can — How Bitcoin Forward-Looking Anonymity Sets Work