Proposal for a new Bitcoin Mixing technique

[anonymixer]

There are pros and cons of using Bitcoin Mixers vs multi-participant CoinJoins.

On a 10,000 foot level, the basic differences are:

• Bitcoin Mixers allow you to jump the Transaction Graph, but rely on users trusting third parties to do this well, with no logs
• CoinJoins give a degree of anonymity on a Join by Join basis, where the anonymity set degrades over time, however there is no requirement to trust third parties
• Unless a Bitcoin Mixer co-spends many inputs in 1 Tx, their wallet(s) / cluster(s) are unlikely to be picked up by chain analysis firms
• All CoinJoins are easily identified, to the point where it's even known exactly which implementation has been used

Coin discrimination is real. Exchanges and KYC services are more frequently freezing users funds based on identifying that the user performs CoinJoins, pending further KYC checks and demand the user ceases further CoinJoin activity (Ironically, the exchanges refer to it as coin-mixing).

Using *some* Bitcoin Mixers on the other hand, the coin sent from a mixer and it's lineage, can in some cases be questionable in nature.

I have been thinking about an alternative hybrid approach, which I want to propose here and gather people's thoughts on this:

• This approach involves a centralized Bitcoin Mixer behind the scenes, continually participating in CoinJoins 24/7
• The Bitcoin Mixer would act as a JoinMarket "Market Maker". Charging 0 fees where "Market Takers" pay the Transaction Fees for each CoinJoin
• It would be impossible to track the Bitcoin Mixer's wallets/clusters, as they would be forever moving targets, not only with normal client funds but also continual CoinJoins

The issue that arises from this is that Coins sent out from the Bitcoin Mixer would then look like they had recently participated in a JoinMarket CoinJoin (because they have), as opposed to simply looking like a regular coin which had been sent from another Bitcoin User.

[1714879558]

1714879558

[1714879558]

1714879558

[1714879558]

1714879558

[1714879558]

1714879558

[1714879558]

1714879558

[1714879558]

1714879558

[suchmoon]

I must be missing something... what exactly are you proposing that would be different from e.g. running my own JM maker node or if I want it faster maybe using Wasabi? And then maybe moving the coins a few times to distance them from the CoinJoin transactions if that's really a concern. Why involve a centralized mixer in this?

[pooya87]

I think it all comes down to popularity of mixing or in other words the volume that is being mixed every minute. If there are enough people mixing their coins and running the clients including a JoinMarket node there is no need to involve a centralized mixing service since there would always be enough volume. But if it were otherwise then using that centralized service could provide the needed liquidity for everyone to be able to mix their coins using CoinJoin any time of the day.

BTW it won't fix the issue with centralized services such as exchanges freezing accounts.

[anonymixer]

I must be missing something... what exactly are you proposing that would be different from e.g. running my own JM maker node or if I want it faster maybe using Wasabi? And then maybe moving the coins a few times to distance them from the CoinJoin transactions if that's really a concern. Why involve a centralized mixer in this?

There is nothing stopping you running a JoinMarket maker node, providing you have the technical capability to do this. It also means you leaving your Bitcoin funds in hot wallets connected to the internet at all times. In my experience, despite offering strong liquidity with 0 fees as a Maker, JoinMarket takers can not come to initiate a CoinJoin until quite some time later, it may be 24 hours, it may be 4+ days.

Wasabi is not instant, they join once an hour providing something doesn't go wrong which it often does, you need a minimum of around 0.1 BTC to participate ($5,600), whilst also leaving you with plenty of "toxic waste", which you are urged to either throw away or donate to others to then co-spend on your behalf [1]. Given the high and increasing price of Bitcoin, this is very wasteful indeed. They also put incredibly low fees on the CoinJoins in my experience, with funds not confirming for 1 or 2 weeks.

With CoinJoins you do not jump the transaction graph. Large CoinJoins are impressive things on the outset, but your funds can be traced, it's difficult, but overtime your anonymity set degrades and certainly in Wasabi's case questions remain over how much they "Wasabi" join in with their own coins, leaving room for coercion and sybil attacks from authorities.

The value of a Bitcoin Mixer which did this, would be offering a user the ability to easily "dip in" to this forever spinning pool, which could have been spinning for the last 6 months continually. The user would get the best of both worlds so to speak, they would jump the transaction graph, whilst receiving coins which would always be anonymized from endless CoinJoins. Coins which were sent to the Mixer would also be added to this forever spinning CoinJoin pool. I think paying 1.5% to a service to provide this, on demand at 1 minutes notice, including getting coins Confirmed quickly is probably a fair price to pay.

[1] https://[banned mixer]/help/wasabi-change-coins

[suchmoon]

~

Ok, got it. I'm quite familiar with CoinJoin disadvantages, have been running a maker node for a long time so there is never a lack of fresh funds at depth 4 and I can live with that.

As for a centralized mixer using this - there might be some problems (e.g. liquidity and perhaps even anonymity if they try to grab more liquidity with multiple nodes).

And I'm still not certain if you're solving a problem that actually needs solving. I use CoinJoin for non-custodial mixing. I use a centralized mixer to get coins faster if I need to and if I'm willing to take the risk. Jumping the TX graph is a non-issue for me after several rounds of CoinJoins and even if it was, a centralized service using CoinJoin has the same problem, doesn't it? If I use it a few times they can't ensure that I won't get my own coins.

[anonymixer]

As for a centralized mixer using this - there might be some problems (e.g. liquidity and perhaps even anonymity if they try to grab more liquidity with multiple nodes).

Becoming a Maker, I would always provide strong liquidity, forever, which is built up from a wide variety of UTXOs which continually refreshes naturally based on regular mixing, let alone JoinMarket participation.

As far as anonynimity is concerned, I am unsure of what the issue would be? I would need to keep track of which UTXOs had been presented in combination with others, which is not a huge task, I think the JoinMarket software already does this, however I would be writing the Maker implementation code from scratch (I don't code with Python) and later a Taker implementation for on-demand ad-hoc Cold purposes (i.e. Initiating a JM CoinJoin direct from Cold Storage to Cold Storage). I wouldn't have 4 "mixing depths", I would do my own entirely separate thing picking UTXOs and Output Addresses accordingly based on my own requirements.

And I'm still not certain if you're solving a problem that actually needs solving. I use CoinJoin for non-custodial mixing. I use a centralized mixer to get coins faster if I need to and if I'm willing to take the risk. Jumping the TX graph is a non-issue for me after several rounds of CoinJoins and even if it was, a centralized service using CoinJoin has the same problem, doesn't it?

It does have the same problem, in terms of making coins produced from the Mixer look like they've been produced from a CoinJoin, which is why this is a discussion only for the moment.

There are a key couple of problems it does solve:

• Chain Analysis companies, would find it impossible to keep track of Mixer wallets / clusters. no matter how much they used it, or how much dust attacks they sent.
• Coins sent out from the Mixer could never be tainted with past activity, other than endless CoinJoins
• Coins sent to the Mixer could never be associated with the original user, due to the endless CoinJoins

If I use it a few times they can't ensure that I won't get my own coins.

If I ensured that all deposits must first be CoinJoined prior to going out again, that's never going to happen. Just saying.

[suchmoon]

Becoming a Maker, I would always provide strong liquidity, forever, which is built up from a wide variety of UTXOs which continually refreshes naturally based on regular mixing, let alone JoinMarket participation.

I mean liquidity from the taker side. I'm quite sure you would be cutting the branch you're sitting on. You would have takers subsidize your TX fees - which is about the only real advantage I can think of in this scheme, and it's an advantage mostly for the mixer, not its customers - while at the same time telling them to come use your service because it's better (faster, less technically-involved, no minimum, etc) than JM/Wasabi/whathaveyou.

As far as anonynimity is concerned, I am unsure of what the issue would be? I would need to keep track of which UTXOs had been presented in combination with others, which is not a huge task, I think the JoinMarket software already does this, however I would be writing the Maker implementation code from scratch (I don't code with Python) and later a Taker implementation for on-demand ad-hoc Cold purposes (i.e. Initiating a JM CoinJoin direct from Cold Storage to Cold Storage). I wouldn't have 4 "mixing depths", I would do my own entirely separate thing picking UTXOs and Output Addresses accordingly based on my own requirements.

Ok, I take your word for it here on tracking the UTXOs but the second part kinda contradicts your OP where you said the mixer would be a maker. Are you going to run takers too, or just produce a client and expect others to run it? And it seems that this:

All CoinJoins are easily identified, to the point where it's even known exactly which implementation has been used

May apply to your custom implementation as well, defeating another potential advantage of it.

If I ensured that all deposits must first be CoinJoined prior to going out again, that's never going to happen. Just saying. That even includes a 1 BTC merchant flying through the doors, because by the time their 1 BTC Deposit has confirmed, a Taker (Cold) CoinJoin has already been performed, with 9 other participants and is ready to go again in the same block.

You said it yourself - CoinJoin doesn't break the TX graph. So I don't think you can also claim that I'll never get my previously deposited coins and it's incorrect to say this:

The user would get the best of both worlds so to speak, they would jump the transaction graph

[anonymixer]

Ok, I take your word for it here on tracking the UTXOs but the second part kinda contradicts your OP where you said the mixer would be a maker. Are you going to run takers too, or just produce a client and expect others to run it?

The Maker and Taker code would be written from scratch. However, still interfacing and communicating with same IRC channels as the regular JoinMarket Python software. Transactions produced would still appear as if they had been produced from the Python software. I would not be running on an entirely different network, but the internals and decision making in terms of which UTXOs were selected and which Output Addresses I chose would be up to my own software.

You said it yourself - CoinJoin doesn't break the TX graph. So I don't think you can also claim that I'll never get my previously deposited coins and it's incorrect to say this:

The user would get the best of both worlds so to speak, they would jump the transaction graph

Strictly speaking, 1 CoinJoin away, I think you're definitely right. Sorry for that, but at what point does this change? I am not sure this is "absolute" as it dilutes to some extent with time?

If you sent Coins to an Entity which then performed 20 CoinJoins in a row over time (each CJ with other JM parties, each time). If you received Coins back from that later, 20 CoinJoins down the line, are these still "Your Coins"?

[suchmoon]

Ok, I take your word for it here on tracking the UTXOs but the second part kinda contradicts your OP where you said the mixer would be a maker. Are you going to run takers too, or just produce a client and expect others to run it?

The Maker and Taker code would be written from scratch. However, still interfacing and communicating with same IRC channels as the regular JoinMarket Python software. Transactions produced would still appear as if they had been produced from the Python software. I would not be running on an entirely different network, but the internals and decision making in terms of which UTXOs were selected and which Output Addresses I chose would be up to my own software.

But you would be running makers AND takers?

Strictly speaking, 1 CoinJoin away, I think you're definitely right. Sorry for that, but at what point does this change? I am not sure this is "absolute" as it dilutes to some extent with time?

If you sent Coins to an Entity which then performed 20 CoinJoins in a row over time (each CJ with other JM parties, each time). If you received Coins back from that later, 20 CoinJoins down the line, are these still "Your Coins"?

As I said earlier, I don't think that TX graph is a big JM issue to begin with... plausible deniability is good enough for me, especially by the time it gets to depth 4, let alone if it has been circling there for months. I'm just picking on your claim that the advantage of this service (over using JM directly) is that would break the TX graph, which it doesn't really do, or at least doesn't do it any better. And it could make input commingling a bigger problem. If I'm not mistaken the default maker tries to avoid co-spending my own inputs at all depths. If I send coins to your proposed service there's probably a higher a chance my coins could be spent together as early as the next CoinJoin after the initial one.

[anonymixer]

But you would be running makers AND takers?

I would probably write a Maker implementation, which ran interfaced directly between the rest of the AM Hot Wallet system and the Join Market Network, which essentially runs on auto-pilot*

I would also probably write a Taker implementation, which is kicked off on an Ad-Hoc Basis from existing GUI software I've written to manage everything, including performing Cold Signatures for Cold Trades. In this case I would be initiating a CoinJoin and Digitally Signing it off from a Hardware Wallet*

As I said earlier, I don't think that TX graph is a big JM issue to begin with... plausible deniability is good enough for me, especially by the time it gets to depth 4, let alone if it has been circling there for months. I'm just picking on your claim that the advantage of this service (over using JM directly) is that would break the TX graph, which it doesn't really do, or at least doesn't do it any better. And it could make input commingling a bigger problem. If I'm not mistaken the default maker tries to avoid co-spending my own inputs at all depths. If I send coins to your proposed service there's probably a higher a chance my coins could be spent together as early as the next CoinJoin after the initial one.

I have had a think about what you said some more, over a long walk. I still think there is merit to this and that I wouldn't be cutting into the branch I'm sitting on, the key point here is that UTXOs are not only circulated by continual CoinJoining but also through conventional mixing, which is what I am already doing. Essentially your deposits are switched out, later, after being CoinJoined, so this hypothetical branch we speak of 20 CoinJoins down the line - I don't think would actually be a likely scenario.

* Exact details of the implementation, precisely, exactly how this would work, including ensuring that I didn't co-spend (or even present to the network) more than one of your deposit inputs in a CoinJoin that you had deposited in a trade, is a detail and a problem that I would solve, which is part of actually doing it and takes time - the kind of detail that needs to be solved later - if I decided to actually go ahead and do that.

For the moment I am only trying to gauge people's feelings on this. You have a JoinMarket node running permanently, but others do not.

I am specifically trying to gauge how people feel about receiving a Coin that has been "CoinJoined" VS a Coin that may or may not have a directly "questionable" lineage.

Just to point out the absolutely obvious, in-case anyone was wondering. A Coin that is Deposited in a Trade would never be CoinJoined then sent back out to the user ---- that would be fantastically rubbish.

I am going to continue to think and sleep on it. Stuff appears to happen in sleep and sleep-like states, for me at least anyway.

[suchmoon]

For the moment I am only trying to gauge people's feelings on this. You have a JoinMarket node running permanently, but others do not.

I am specifically trying to gauge how people feel about receiving a Coin that has been "CoinJoined" VS a Coin that may or may not have a directly "questionable" lineage.

FWIW I probably wouldn't be running my own node if there was a better (quicker, more convenient, not horribly expensive, etc) way to use CoinJoin so you might be onto something here. Wasabi doesn't quite cut it. But I'm not certain that a centralized option is the answer either.

[anonymixer]

I've boiled this down further, I think -- a more concise explanation, for reference:

• Alice wants to Pay Bob 0.5 BTC
• Alice sends 0.2 BTC to Deposit Address A, followed later by 0.3 BTC to Deposit Address B
• Coin Z (0.5 BTC), somewhere else, is sent to Bob and is entirely unconnected to Alice's deposits

More, and most importantly:

• Coin Z went through 200+ separate CoinJoins over a period of 6 months
• The Coin Alice Deposited at Address A, later on that day participates in a CoinJoin
• The Coin Alice Deposited at Address B, participates in a separate CoinJoin 2 days later
• Alice's Coins are CoinJoined 20 or even 200 times before they even make their way back out of the mixer

[PrimeNumber7]

I've boiled this down further, I think -- a more concise explanation, for reference:

• Alice wants to Pay Bob 0.5 BTC
• Alice sends 0.2 BTC to Deposit Address A, followed later by 0.3 BTC to Deposit Address B
• Coin Z (0.5 BTC), somewhere else, is sent to Bob and is entirely unconnected to Alice's deposits

More, and most importantly:

• Coin Z went through 200+ separate CoinJoins over a period of 6 months
• The Coin Alice Deposited at Address A, later on that day participates in a CoinJoin
• The Coin Alice Deposited at Address B, participates in a separate CoinJoin 2 days later
• Alice's Coins are CoinJoined 20 or even 200 times before they even make their way back out of the mixer

In this scenario, it is very obvious that coin Z is from a mixer, and analysis can be done accordingly. It is also obvious that Alice's two deposits are going into the mixer.

The delaying of starting CJ transactions does nothing because there is a pattern of going directly from the deposit address into CJ transactions, and it would be obvious that both deposit address A and deposit address B received coin that went into the mixer on the same day.

Most mixers have known addresses and clusters to blockchain analysts, but someone studying a mixer may not know about all of the addresses belonging to a mixing service.