Can Bitcoin Mixer services be trusted?

[LoyceV]

I can't see a way to safely escrow

Bob can send a voucher to a third party acting as escrow. Escrow checks it, creates a new voucher, and gives it to Alice.

Now this risk is with the escrow:

The risk is that the other party redeems the voucher and then claims that it didn't work, or sends you a fake or already redeemed voucher.

Unless of course ChipMixer implemented blinded bearer certificates.

As far as I understand BBC, that would really be the next large step for privacy.
And it would allow them to advertise on this forum again, right?

[o_e_l_e_o]

Bob can send a voucher to a third party acting as escrow. Escrow checks it, creates a new voucher, and gives it to Alice.

I was thinking more of a trustless escrow, such as Bisq's 2-of-2 multi-sig escrow between buyer and seller, rather than just shifting the trust from one party to another. I can't see a way to do this in the current system.

And it would allow them to advertise on this forum again, right?

It should do. The whole point of the blinding is that even ChipMixer would not know which certificate is which. They would be unable to log any activity as all they can tell is if a certificate is valid and unspent, but not when it was signed or who has owned it.

[Cookdata]

Can we just put aside the other worries and address the main problem? I want to believe Sending bitcoin (either Utxo that has been KYC or not) to a mixer is risky because even if you know a little about their protocols,  you don't have the associated private keys to your deposit and you risk losing your money but no one is discussing that which I'm having interest on.
If not for the fact that some Mixers claimed that they usually purge their logs, why trust a mixer that can be threatened just like an exchange? why not go through Coinjoin where you have access to your keys than a mixer that you have to trust about your privacy and custody of funds.

@o_e_l_e_o

[o_e_l_e_o]

you don't have the associated private keys to your deposit and you risk losing your money but no one is discussing that which I'm having interest on.

Yes, this is a risk. When you deposit coins to any exchange, casino, mixer, etc., then you are giving up custody of them. This is a risk I am willing to accept with ChipMixer due to a number of reasons: Firstly, I am mixing small amounts of coins at a time and not leaving amounts I can't afford to lose in the custody of a mixer, and secondly, they have mixed hundreds of thousands of bitcoin over the years without a single incident of loss or theft.

why not go through Coinjoin where you have access to your keys than a mixer that you have to trust about your privacy and custody of funds.

Coinjoin is another useful tool, but it is neither perfect nor infallible:

Still, it seems that Wasabi has never been as safe as we all think:

Using a capability that is being disclosed here for the first time, Chainalysis de-mixed the Wasabi transactions and tracked their output to four exchanges.

[n0nce]

you don't have the associated private keys to your deposit and you risk losing your money but no one is discussing that which I'm having interest on.

Yes, this is a risk. When you deposit coins to any exchange, casino, mixer, etc., then you are giving up custody of them. This is a risk I am willing to accept with ChipMixer due to a number of reasons: Firstly, I am mixing small amounts of coins at a time and not leaving amounts I can't afford to lose in the custody of a mixer, and secondly, they have mixed hundreds of thousands of bitcoin over the years without a single incident of loss or theft.

why not go through Coinjoin where you have access to your keys than a mixer that you have to trust about your privacy and custody of funds.

Coinjoin is another useful tool, but it is neither perfect nor infallible:

Still, it seems that Wasabi has never been as safe as we all think:

Using a capability that is being disclosed here for the first time, Chainalysis de-mixed the Wasabi transactions and tracked their output to four exchanges.

I believe there's a market for a LN-based mixing service. Not sure if it might require an extension of LN and / or Bitcoin, but it should be possible without. Basically a way to submarine-swap on-chain funds into different LN channels, maybe even splitting it and having it arrive in multiple different LN wallets / nodes using https://bolt12.org/ invoices for instance. Then, similarly to ChipMixer chips, you can submarine-swap them all at once or over time as you need them, back into an on-chain wallet.
This is possible today already, but it's a manual effort - creating various invoices, initiating multiple swaps, and reversing the process.

Basically, when using a submarine-swap based swap provider, you're not trusting anyone, however by associating similar amounts and running lots of surveillance nodes, your payment might be tracked.
However, if there was a way to specify multiple invoices when using such a provider, it could be possible to e.g. receive part of the payment on your mobile node, one on your main LN node and even maybe part on a friend's node (with pinky promise to send it to yourself afterwards) for instance. This splitting action would be similar to ChipMixer chips that are spent at different points in time.

[dkbit98]

Yes, this is a risk. When you deposit coins to any exchange, casino, mixer, etc., then you are giving up custody of them. This is a risk I am willing to accept with ChipMixer due to a number of reasons: Firstly, I am mixing small amounts of coins at a time and not leaving amounts I can't afford to lose in the custody of a mixer, and secondly, they have mixed hundreds of thousands of bitcoin over the years without a single incident of loss or theft.

I am sure someone will create a way to reduce the risk soon, maybe something similar like Bisq is doing but used for mixing of coins, like you mentioned before.
Maybe we should all start thinking out of the box for solving this problem.

I believe there's a market for a LN-based mixing service. Not sure if it might require an extension of LN and / or Bitcoin, but it should be possible without. Basically a way to submarine-swap on-chain funds into different LN channels, maybe even splitting it and having it arrive in multiple different LN wallets / nodes using https://bolt12.org/ invoices for instance. Then, similarly to ChipMixer chips, you can submarine-swap them all at once or over time as you need them, back into an on-chain wallet.

I believe Lightning Network will be much more popular in near future, especially after I saw then news that USDT recently got it's first transaction on LN using OMNI Layer and Bitcoin-powered service provider Synonym.
This will bring more liquidity to Lightning Network, and even if I am not a fan of any stable coins that are not really stable if we know that inflation is growing every day, but it will bring more attention for sure.
I think that Chipmixer or some other mixing service can improve in future and bring some version two that would make it much safer for everyday users.
Chainalysi and other tracking companies are working non-stop with new ways to track mixers and LN, but don't think for a second that good developers are not thinking of new ways for improving their service.

[m2017]

Yes, this is a risk. When you deposit coins to any exchange, casino, mixer, etc., then you are giving up custody of them. This is a risk I am willing to accept with ChipMixer due to a number of reasons: Firstly, I am mixing small amounts of coins at a time and not leaving amounts I can't afford to lose in the custody of a mixer, and secondly, they have mixed hundreds of thousands of bitcoin over the years without a single incident of loss or theft.

I am sure someone will create a way to reduce the risk soon, maybe something similar like Bisq is doing but used for mixing of coins, like you mentioned before.
Maybe we should all start thinking out of the box for solving this problem.

Is it possible to use something similar to a smart-contract for this? I understand that this is not ETH and there is no such feature on the BTC network.

But what if something similar is applied?

User sends BTC from address 1 to mixer. At this point, a smart-contract is created on the ETH network (or any other, on the basis of which it can be implemented), equivalent amount (in ETH) sent by user BTC is frozen.

The conditions will be as follows:
1 - if user receives BTC at the address 2, then the deposit from the smart-contract is returned to mixer.
2- if user didn't receives BTC at the address 2 after the allotted time, then the user receives a deposit from the smart-contract in ETH.

In the worst case scenario, the user lost BTC, but gained ETH, the equivalent of $. If desired, user will be able to exchange ETH for BTC in some exchanger. Yes, there will be partial losses, but this is not a loss of 100% of the amount sent from address 1.

Also, all this will create additional costs (for example, the same commissions for transactions), which will ultimately affect the end user.

I don't pretend to be a genius idea (quite the contrary), but there is such a cool thing as smart-contracts that can possibly solve the trust problem, including with mixers. If it is impossible to implement a mechanism to protect the user from losing he's BTC when interacting with mixers, on its basis, then why not take advantage of the possibilities of other technologies?

Firstly, I am mixing small amounts of coins at a time and not leaving amounts I can't afford to lose in the custody of a mixer,

The issue of trust (reliability) to mixers would also save users from such unnecessary actions. Why send in parts of 10 transactions when you can send the entire amount you need in a "couple of clicks".

This can also reduce the unnecessary operational burden from mixers (they will still receive the same commission as from one large transaction or many small ones, but for the same amount), therefore, the issue of trust for them also remains relevant.

[n0nce]

~

I don't think that smart contracts work between chains. Depositing currency into a smart contract is literally done by sending it to the contract's address. Since you can't send BTC to an ETH address, that won't work.

[m2017]

~

I don't think that smart contracts work between chains. Depositing currency into a smart contract is literally done by sending it to the contract's address. Since you can't send BTC to an ETH address, that won't work.

You misunderstood my point. I'm not suggesting sending BTC to ETH address.
It is enough to automate the following:
- BTC arrived at the account of mixer.
- In parallel, a smart-contract with ETH is created for the user.
- This frozen ETH acts as a guarantee for the user. If he doesn't receive BTC from the mixer exit, he will be able to pick up ETH.

BTC and ETH chains are independent of each other, but an intermediary program appears between them, which performs all actions. For example, it analyzes BTC receipt to the mixer's address, creates a smart-contract with ETH, etc.

[n0nce]

~

I don't think that smart contracts work between chains. Depositing currency into a smart contract is literally done by sending it to the contract's address. Since you can't send BTC to an ETH address, that won't work.

You misunderstood my point. I'm not suggesting sending BTC to ETH address.
It is enough to automate the following:
- BTC arrived at the account of mixer.
- In parallel, a smart-contract with ETH is created for the user.
- This frozen ETH acts as a guarantee for the user. If he doesn't receive BTC from the mixer exit, he will be able to pick up ETH.

BTC and ETH chains are independent of each other, but an intermediary program appears between them, which performs all actions. For example, it analyzes BTC receipt to the mixer's address, creates a smart-contract with ETH, etc.

You need a trustless way to do this though; if you give access to ETH before receiving the BTC, the user can scam you, if you only hand out the ETH after receiving, you can scam the user.
The ETH smart contract cannot observe the BTC blockchain.

You would need something like a preimage / commitment that is opened by the receiver, thus giving access to the sender; just like it is done in Lightning Network and submarine swaps.

I think your mixer idea just boils down to doing a submarine swap.

Maybe have a look into those.
There's also a video presentation by Alex Bosworth. Not sure if it's good, though.

[HCP]

Perhaps there could be some way to implement this as a Layer 2 solution that would enable some sort of "trustless" mechanism to enforce the transfers etc?

[m2017]

~

I don't think that smart contracts work between chains. Depositing currency into a smart contract is literally done by sending it to the contract's address. Since you can't send BTC to an ETH address, that won't work.

You misunderstood my point. I'm not suggesting sending BTC to ETH address.
It is enough to automate the following:
- BTC arrived at the account of mixer.
- In parallel, a smart-contract with ETH is created for the user.
- This frozen ETH acts as a guarantee for the user. If he doesn't receive BTC from the mixer exit, he will be able to pick up ETH.

BTC and ETH chains are independent of each other, but an intermediary program appears between them, which performs all actions. For example, it analyzes BTC receipt to the mixer's address, creates a smart-contract with ETH, etc.

You need a trustless way to do this though;

Undoubtedly, you are right and the method must be extremely reliable so that neither side can deceive the other. Without this, the whole idea becomes meaningless.

if you give access to ETH before receiving the BTC, the user can scam you,

To avoid this, an intermediary program is needed, which will unfreeze access to ETH only after BTC is received.

if you only hand out the ETH after receiving, you can scam the user.

This is what a smart contract is for. The intermediary program, when sending BTC to the desired address (but not yet fully confirmed by the network), creates a smart contract with the conditions "freeze the equivalent of the amount ETH sent by the user to BTC for the period of waiting for confirmation." After BTC arrives at the address, the intermediary program will unfreeze ETH account. Or, the program will not be able to influence the smart contract after it is created (which should be more reliable), and the account will unfreeze after a certain time, sufficient to confirm transaction BTC.

This is only a draft version, completely devoid of grace for solving the desired problem.

The ETH smart contract cannot observe the BTC blockchain.

I understand. Thank you for reminding me of this.   In my idea, networks BTC and ETH do not intersect in any way. Iintermediary program, which, just does not allow one of the parties (mixer and user) to scam, connects ETH and BTC networks (conditionally), checks the receipt of the required amount to the addresses, controls the fulfillment of the conditions.

You would need something like a preimage / commitment that is opened by the receiver, thus giving access to the sender; just like it is done in Lightning Network and submarine swaps.

Yes, commitment sounds the closest.

I think your mixer idea just boils down to doing a submarine swap.

Maybe have a look into those.
There's also a video presentation by Alex Bosworth. Not sure if it's good, though.

It is possible and if so, then I apologize that I wasted your time with "inventing the wheel". I don't know anything about submarine swap or and first saw the term in your post, but I'll look through your links and try to learn more about it. 

[BlackHatCoiner]

To avoid this, an intermediary program is needed, which will unfreeze access to ETH only after BTC is received.

What he's telling you is that there's still trust from either the user or the service the way you say it. There are ways to trade trustlessly, such as with submarine swaps, but there's no way I know to give a mixer access to your money and get them back, mixed, without having to trust they won't rip you off.

Remember: They need to create outputs with your money and therefore, you need to hand them out. Afterwards, it's part of their service.

[n0nce]

if you give access to ETH before receiving the BTC, the user can scam you,

To avoid this, an intermediary program is needed, which will unfreeze access to ETH only after BTC is received.

This program would need to be a smart contract though. I do count Bitcoin scripts as smart contracts.
The issue is that neither chain's contracts can access the other chain's contracts. So any system that requires 'monitoring the other chain' won't work. Hence the commitment-style implementation that Submarine Swaps use is so far the best idea that I came across for swaps across chains.

The ETH smart contract cannot observe the BTC blockchain.

I understand. Thank you for reminding me of this.   In my idea, networks BTC and ETH do not intersect in any way. Iintermediary program, which, just does not allow one of the parties (mixer and user) to scam, connects ETH and BTC networks (conditionally), checks the receipt of the required amount to the addresses, controls the fulfillment of the conditions. 

This program would need to be a smart contract though, right? Otherwise who is running that program? How could one of the parties trust that the other party is running it correctly?

I think your mixer idea just boils down to doing a submarine swap.
Maybe have a look into those.
There's also a video presentation by Alex Bosworth. Not sure if it's good, though.

It is possible and if so, then I apologize that I wasted your time with "inventing the wheel". I don't know anything about submarine swap or and first saw the term in your post, but I'll look through your links and try to learn more about it. 

No need to apologize! I'm really interested in this topic and glad to discuss. If you've got more thoughts on submarine swaps or other, maybe better ideas for these cross-chain swaps and using them for mixing, keep the discussion going!

To avoid this, an intermediary program is needed, which will unfreeze access to ETH only after BTC is received.

What he's telling you is that there's still trust from either the user or the service the way you say it.

Yeah, well, except if you construct a mixer that is indeed based on commitments and / or smart contracts that run on the blockchain.

[BlackHatCoiner]

Yeah, well, except if you construct a mixer that is indeed based on commitments and / or smart contracts that run on the blockchain.

I don't think there's a way to do that and gain the same privacy you would (without any on-chain connection). There are solutions which improve your privacy non-centrally, such as JoinMarket, but the inputs and the outputs have an on-chain connection.

I'd be appreciated if you explained how could this work, but as far as I can tell it's impossible unless we entangled it with the Lightning Network which would then create other kind of problems (such as liquidity).

[n0nce]

Yeah, well, except if you construct a mixer that is indeed based on commitments and / or smart contracts that run on the blockchain.

I don't think there's a way to do that and gain the same privacy you would (without any on-chain connection). There are solutions which improve your privacy non-centrally, such as JoinMarket, but the inputs and the outputs have an on-chain connection.

I'd be appreciated if you explained how could this work, but as far as I can tell it's impossible unless we entangled it with the Lightning Network which would then create other kind of problems (such as liquidity).

You could also argue that building something that leverages the LN for mixing would increase its usage and motivate more liquidity!
The idea would be something like:

Code:

         payments usually  ┌────────────────────────┐
         split into        │                        │
         multiple routes   │                        │
        ┌─────────────────►│  Lightning             ├─────────────────┐
        │                  │  Network               │                 │
        │                  │                        │                 │
        │                  │                        │                 │
        │submarine swap    └────────────┬───────────┘   submarine swap│
        │                               │   ▲                         │
        │                               ▼   │                         ▼
┌───────┴──────────┐       ┌────────────────┴───────┐       ┌──────────────────┐
│ On-Chain input   │       │ Intermediary LN wallet │       │Destination       │
│ address          │       │                        │       │On-chain address  │
└──────────────────┘       └────────────────────────┘       └──────────────────┘

The idea about the intermediary LN wallet is that you could 'swap in' different amounts than the ones you 'swap out' and spread them over time by adding time checks (locktime) to the output scripts of the submarine swaps.

There wouldn't be a direct connection between outputs and inputs in this scenario, since it is all obfuscated through the LN's off-chain transactions. The outputs could also arrive at different unrelated on-chain addresses so that it will super hard to correlate input amounts and output amounts. The whole thing will also blend in super well with regular LN usage and regular LN submarine swaps, compared to potentially suspicious '0.007888BTC' transactions that are obviously ChipMixer chips for instance.
The only attack would be something involving controlling lots of LN nodes and tracking LN payments; so an attack on LN itself. At least the way I see it.

[BlackHatCoiner]

[...]

Doesn't that require you to already have a channel with the amount you want to mix, so that you can immediately exchange LN-BTC for BTC? Also, what about the time? It plays a big role when it comes to privacy. If a chain analysis company routed a 0.16 BTC payment it could be far nearer to the new address. (That received money few seconds/minutes later)

[n0nce]

[...]

Doesn't that require you to already have a channel with the amount you want to mix, so that you can immediately exchange LN-BTC for BTC? Also, what about the time? It plays a big role when it comes to privacy. If a chain analysis company routed a 0.16 BTC payment it could be far nearer to the new address. (That received money few seconds/minutes later)

You don't need a single channel; in fact it would even better if your channels are smaller than the mixed amount, because then it's guaranteed that the payment has to be split in multiple smaller ones.
But in general anything a little bit larger usually takes multiple different paths to its destination.

As I said, when it comes to correlating input / output sizes, you can break that by choosing random amounts that are sent to the LN wallet in different time intervals (network topology also changes over time) and sent back out at different time intervals and in different sizes than what 'comes into' the LN wallet as well.

[m2017]

The ETH smart contract cannot observe the BTC blockchain.

I understand. Thank you for reminding me of this.  In my idea, networks BTC and ETH do not intersect in any way. Iintermediary program, which, just does not allow one of the parties (mixer and user) to scam, connects ETH and BTC networks (conditionally), checks the receipt of the required amount to the addresses, controls the fulfillment of the conditions.  

This program would need to be a smart contract though, right?

Probably yes.

Otherwise who is running that program? How could one of the parties trust that the other party is running it correctly?

I would gladly answer if I knew the answers to your questions and had the technical experience to do so. I proposed the idea in general terms without having any idea how it could be implemented. Perhaps experts in the field could answer or have already answered, as in the case of submarine swap.
 

No need to apologize! I'm really interested in this topic and glad to discuss. If you've got more thoughts on submarine swaps or other, maybe better ideas for these cross-chain swaps and using them for mixing, keep the discussion going!

The discussion really turned out to be interesting and I learned about such curious things as submarine swap. I am also increasingly inclined to think that mixing services will need to change, become more complex and evolve over time in order to be able to provide their customers with the best possible privacy. I think after a while we will be able to see and try mixing services v.2.0.

[OgNasty]

I believe that when it comes to privacy and anonymity, you can't trust anyone at all. So what kind of information can a bitcoin mixer service get?

This is a very good point with relation to mixing services.  A lot of people talk about how they use the services for privacy reasons.  I think that's a lot of bullshit.  I would guess that a large majority of the users who utilize these services are petty criminals who are laundering small amounts of stolen funds.  That's why you see those wearing mixing service signatures constantly harassing attempted scammers who are not covering their tracks by paying a % of their stolen funds to mixing services.  That point aside, you have to assume that government agencies such as the IRS have likely already setup their own mixing services as honeypots or are monitoring mixing services to go after any large transactions they are able to trace (which is easier than you think).  I imagine at some point in the future there will be a massive sting and a lot of people are going to get caught up using these services.  That or they will shut down and run once they realize they've been compromised and take any funds they're mixing with them.