Implement coinjoin in wallet

laanwj commented at 12:27 pm on November 9, 2013: member

It would be useful to support coinjoin in the client and GUI. This would allow people to combine their transactions with random other people to increase privacy. (See https://bitcointalk.org/index.php?topic=279249.0 for @gmaxwell’s original proposal)

~~The simplest implementation would be ‘where the users send their input and output information to some meeting point server, and the server creates the transaction and asks people to sign it.~~ ~~The server learns the mapping but no one else does, and the server still can’t steal the coins ~~ ~~This server would be set in the configuration, and could be a TOR hidden service for extra privacy.~~

Initially this would be a simple (http/https based?) protocol that drops the transaction plus a timeout value and a way to request the current status. Later on, this could be extended with blinding, and/or a solution that does not rely on servers (or relies on P2P network changes, for example with @lukejr’s proposal https://gist.github.com/luke-jr/5409899).

in the RPC and GUI this requires a way to queue transactions with a configurable timeout. The transactions will then either be queued locally, or if one is configured, sent to the meeting point server.

(commented out my original proposal, making use of an existing system, e.g. joinmarket would be much better than reinventing the wheel)

jgarzik commented at 3:36 pm on November 9, 2013: contributor

+1

From BitPay’s perspective (vendor hat: on), this sort of feature is important for achieving privacy of routine business transactions. Big Businesses(tm) will not like their private transactions being subject to trivial graph analysis.

Talks with folks in Washington, DC have also raised the issue of consumer privacy (and bitcoin’s relative lack thereof).

mikehearn commented at 11:28 am on November 13, 2013: contributor

This is a large project, especially if you want a standardised P2P protocol. Satoshi used to be very hard-core about there being no central servers at all, not even behind Tor. It’s unclear to me how important that principle is for things like rendezvous servers.

Also, to me CoinJoin is not a no-brainer. There are a LOT of simpler privacy changes that can be made in Bitcoin-Qt before this, that would work for everyone all the time with no dependence on “just in time” rendezvous. For instance, deterministic wallet support and a more scalable wallet would make it much easier for people to avoid re-using addresses. Improving the way the payment protocol is used, to fragment coins and transfer payments in several transactions, also obfuscates the block chain probably at lower cost in terms of complexity.

laanwj commented at 12:00 pm on November 13, 2013: member

At least initially I’m fine with centralized rendezvous servers. Sure, a standardized P2P protocol would be better (and very difficult) but one step at a time. As @gmaxwell describes in the mentioned topic, the server can learn only very little. It’s never worse than the current state in terms of privacy.

Deterministic wallets and such provide no extra privacy in the block chain if you’re already keeping to the privacy guidelines and using a new address for every transaction.

mikehearn commented at 12:05 pm on November 13, 2013: contributor

…. which people either don’t do, because of the lack of deterministic wallets, or do and get burned. Using a fresh address each time as you’re supposed to with the current client is a quick way to discover your backups were silently invalidated behind your back, which is scary.

Also, regard what I said about coin fragmentation. Even with CoinJoin, if you have a very large output then disguising that requires you to fragment anyway because otherwise you’d see one big input in and one big input out rendering the work pointless. Given that the difficult part of coin fragmentation (deciding on the sizes of the fragments) would be needed anyway, it makes sense to start there.

laanwj commented at 12:14 pm on November 13, 2013: member

Yes that is scary. Personally I really don’t like the automatic keypool refill, and would prefer if it was manual (#2841) so that care can be taken to make a new backup when needed.

Indeed, doing coin fragmentation would further increase privacy. Vendors would have to cooperate with this by providing multiple addresses / amounts (which indeed is already possible with the payment protocol). Splitting the outputs into multiple transactions would provide further obfuscation, though it would also be less efficient with regard to block-chain space so it would be a trade-off.

mikehearn commented at 12:22 pm on November 13, 2013: contributor

Yeah. The nice thing about coin fragmentation is that (beyond it having fewer moving pieces), it avoids outputs ever being linked in the first place.

Consider a business that pays its employees a salary at the end of the month. To do this it builds a giant transaction that pays to the employees address. The employees wallet may well try to perform a coinjoin on this output to disguise the fact that it came from Joe’s Coffee House, but unless there happen to be a huge number of users online simultaneously waiting to do a CoinJoin with big inputs, it’s very likely to result in a failed mix (can guess the output from the input). Also, the user would still end up with a huge salary-sized output, leaking a lower bound of their balance.

If the employee submits a PaymentRequest with a few hundred requested outputs, the business can give back transactions that satisfy those outputs with the minimum linkage possible - there’s no way to know the transactions are related, especially if the employee chooses to broadcast them smeared over a period of time. The anonymity set is the entire set of Bitcoin users instead of the small number who took part in the coinjoin.

Now that said, CoinJoins have their place, but it seems to me like there’s a lot of lower hanging fruit to harvest first.

shahnah commented at 10:08 am on November 14, 2013: none

This needs to be moved up to high priority.

http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/

painlord2k commented at 0:43 am on November 15, 2013: none

“but unless there happen to be a huge number of users online simultaneously waiting to do a CoinJoin with big inputs, it’s very likely to result in a failed mix”

put a (small) fee in the transaction to pay the other(s) participants and there will not be any lack of users or any lack of big inputs. the fee could be as small as the fee paid to the miners and could use the dynamic pricing of fee(s) in the future versions of Bitcoin-QT

gmaxwell commented at 0:54 am on November 15, 2013: contributor

I suggested a possible approach to implementing which allows an incremental implementation and guides how the UI might work at https://bitcointalk.org/index.php?topic=279249.msg3443288#msg3443288

The idea is to add support for queued transactions: Instead of immediately making a payment you could add a request into a queue. The client is then free to process the queue in whatever manner you’ve configured.

This could be used to automatically pack multiple payments into a sendmany, reducing transaction size (and fragmented change), but then with coinjoin code turned on the same queue could be used to participate in coinjoins with basically no more UI changes.

mikehearn commented at 11:02 am on November 15, 2013: contributor

That makes sense. With the payment protocol you’re allowed to submit multiple independent transactions to a recipient, and the recipient can then broadcast them as and when they see fit. This is a privacy benefit because a single logical payment can be broken up and spread out over time. Of course that only works if you trust the sender not to double spend - it’d require some kind of risk analysis. Like, broadcasting your salary this way is not likely to be an issue. Broadcasting a payment from someone who just walked into a supermarket, not a great idea.

Such behaviour would already require a queue with a notion of how OK it is delay payments, but on the recipient side.

I don’t think fees would change anything. People already have an incentive to keep their private lives private, and doing a coinjoin is not expensive. The main reason I was thinking of why most people might not be online is these days a lot of people’s primary computing devices are battery powered and sync to the network only occasionally, and only for a few minutes. It’s probably possible to set things up so wallets get woken up to take part from time to time, but this is an additional pile of complexity that wouldn’t make much sense in Bitcoin-Qt anyway, given its current state.

mikehearn commented at 11:03 am on November 15, 2013: contributor

Oh, I guess there’s one case fees might help - at any given time many wallets won’t need any mixing or privacy enhancements, either because they already did a coinjoin/coinswap, or because they’ve been fragmenting requests properly and there isn’t much linkage between their outputs anyway. So left to their own devices I guess most wallets won’t want to take part in such schemes, most of the time, it’d just be a battery drain for no benefit. A fee might help to mitigate that.

petertodd commented at 5:58 pm on November 15, 2013: contributor

Note that step one will be to fix the wallet code’s handling of double-spends.

Diapolo commented at 6:18 pm on November 15, 2013: none

@petertodd Isn’t there some double-spend detecion pull lingering around here?

petertodd commented at 6:25 pm on November 15, 2013: contributor

@Diapolo There is, but unfortunately it only handles the case of a double-spend of a transaction sent to you; it doesn’t handle double-spends of transactions that you send.

Specifically: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03126.html

mikehearn commented at 2:28 pm on November 16, 2013: contributor

Why does it depend on double spend handling?

simondlr commented at 4:44 pm on November 17, 2013: contributor

I know this will probably start coming to fore after client implementation, but in terms of UX for the GUI: What’s the plan here? Should it be an advanced feature?

Thinking it would be a bit confusing for new users (using QT) to have a checkbox to make the transaction do a “coinjoin” (on the send page).

Perhaps there could be a “privacy” tab in preferences, where users can set this? Perhaps looking into using a more immediately ‘friendly’ name? ie, as a checkbox, say “Make transaction more private. [ ]” and then have a question mark explaining coinjoin in easier English?

Just some thoughts.

petertodd commented at 9:20 pm on November 17, 2013: contributor

@mikehearn You need to be able to handle a coinjoin participate maliciously double-spending their input. @simondlr CoinJoin definitely needs to be a “by default” action in the long run for all payments to get the maximum benefit; I outlined this on the -talk forum: https://bitcointalk.org/index.php?topic=334241.msg3615921#msg3615921

In the short term there are issues with services that make bad assumptions about address re-use. It’s nice that the payment protocol is so clear that txin’s aren’t return addresses; CoinJoin can easily be made the default way to send payments there provided a good implementation exists.

My thinking on that implementation is you really want to focus on making the default user experience seamless, and I think that means a simple, two-party mix protocol with a reasonably low default timeout. In the default case, it’s ok if the transaction doesn’t always wind up being joined. Equally, we may be able to take advantage of a fee UI’s - if user’s are taking advantage of time/cost trade-offs anyway integrate that configurable timeout as part of the CoinJoin process, which in turn helps the users who want a transaction sent quicker.

mikehearn commented at 10:14 pm on November 17, 2013: contributor

Yeah that makes sense.

ABISprotocol commented at 10:33 am on November 18, 2013: none

Can someone tell @mikehearn to give up with the whole “let’s give bitcoin taints and blacklists and (add on all manner of ridiculous things here)”?(?) Folks, please get on the coinjoin train. Big ups to @luke-jr (et. al.) for the P2P concept. Get er done. Moving on. Now, for those who are still attached to the state… Detach. Thank you, and goodnight.

laanwj commented at 11:53 am on November 18, 2013: member

@idiotsabound if you’re not helping development, please don’t distract us here

laanwj renamed this:
~~Implement coinjoin in client~~
Implement coinjoin in wallet
on May 22, 2014

ABISprotocol commented at 8:02 pm on October 6, 2014: none

@laanwj A very brief question… is this (currently priority medium) improvement item something that is anticipated soon within bitcoin? Is there a pull request or requests that relates to this, if so, can someone provide a direct link? I’m kind of assuming that if this were implemented, concerns about possible redlisting would not be an issue due to that the software would provide users with a way around or out of that (censorship, etc.) type of problem, and at the very least it would provide a meaningful response to state-actor ban proposals such as those out of Russian Federation. Regarding the earlier comment by @shahnah ~ why is this not a higher priority? I feel that it should be.

laanwj added the label Wallet on Oct 7, 2014

laanwj commented at 9:32 am on October 7, 2014: member

AFAIK no one is currently working on this. Takers are welcome. It looks like the bitcoin core wallet has only low interest for developers. Which isn’t too surprising given the many alternative wallets that provide a better user experience.

In the meantime, why not use some other wallet that does incorporate coinjoin, such as darkwallet?

ABISprotocol commented at 5:41 pm on October 7, 2014: none

At the moment, Darkwallet is in an alpha / preview. It is not done yet. It has yielded / spun off repositories that can be used readily by other projects such as this one.

I know that there have also been concerns about the discoverability of users under CoinJoin, and there is an extensive discussion about different ideas that go beyond the original CoinJoin proposal. These include, but are not limited to, ideas relating to ring signatures, as well as Coinshuffle which I am unfamiliar with, and @gmaxwell / Poelstra’s Output Distribution Obfuscation ideas (which interest me a lot).

Then there is the issue of funding. The fund which is specified for CoinJoin and similar or related privacy proposals is well stocked, with currently over 42 BTC available to fund such privacy tasks. This has been discussed in bitcoin-development previously some months back. It would be good to see if there are some proposals which the maintainers of that fund have identified as reasonable candidates to receive such funding, and if anyone knows of such please indicate what they are. If core developers / maintainers are working towards a technically better / easier to use proposal or proposals that could be incorporated directly into bitcoin or made available through any wallet, it would be good to hear of what that is, particularly in light of developments in the Russian Federation, UNSC, and beyond. Where there is a way to protect users in a manner that clearly addresses the issues of discoverability and linkability, it would certainly be good to see it integrated directly into bitcoin, available in Core and made easy for various wallet developers to incorporate as well. Thank you in advance for answering these concerns and questions.

ABISprotocol commented at 6:33 pm on December 1, 2014: none

Hello, for those following this discussion, some additional remarks (including developers’ discussion) about the fund specified for CoinJoin and similar or related privacy proposals, can be seen through an archive which you can view via this link. Thanks to those who have contributed to that discussion.

laanwj added the label Feature on May 18, 2015

laanwj removed the label Improvement on May 18, 2015

laanwj removed the label Priority Medium on May 18, 2015

gmaxwell added the label Privacy on Aug 18, 2015

Giszmo commented at 6:49 pm on December 2, 2015: none

A year went by, JoinMarket is struggling to get something working but runs into exactly what CoinShuffle identified as their problem. ChoinShuffle is still only a paper. DarkWallet is discontinued since almost a year …

Did I miss something? Any decentralized protocol that actually works yet, to base work on?

ABISprotocol commented at 8:10 am on December 5, 2015: none

@Giszmo Yes, there is something that works and could probably be integrated soon, though it’s unclear of what priority it would get in the grand scheme of everything else? It’s called Confidential Transactions, by @gmaxwell https://bitcointalk.org/index.php?topic=1085273.0 Includes a Borromean ringsig similar in some ways to BCN - explainer on it here https://bitcointalk.org/index.php?topic=1077994.0 It’s a feature of Elements https://github.com/ElementsProject/elements @laanwj

sipa commented at 8:14 am on December 5, 2015: member

Confidential transactions is not CoinJoin. It’s pretty much exactly the opposite: CT protects transaction amounts, CoinJoin protects address linkage. Combined they are very powerful, though.

ABISprotocol commented at 8:18 am on December 5, 2015: none

@sipa Clearly CT is not CoinJoin, no-one here has claimed that it is. Simply put, CT actually works.

sipa commented at 8:21 am on December 5, 2015: member

@Giszmo is asking about any decentralized protocol for CoinJoin that actually works. CT is a consensus rule for protecting transaction amounts, it doesn’t have anything to do with the question.

ABISprotocol commented at 8:35 am on December 5, 2015: none

Then provide an example of functional CoinJoin, being as there are examples out there and the bounty on it was long ago claimed.

sipa commented at 8:41 am on December 5, 2015: member

I fail to understand what you’re arguing for.

You’re very welcome to go suggest CT in Bitcoin or explore how it could be implemented. But this is not the place for it.

This issue is about bringing CoinJoin to Bitcoin. A commenter is asking whether there exists a working decentralized version protocol for CoinJoin to base their work on. I don’t know the answer to that. You bringing up a completely unrelated privacy improvement is not useful, and I’m pointing that out.

Note: I have nothing against CT; I’m even responsible for part of the its implementation in Elements Alpha. All I’m asking is to stick to the issue.

ABISprotocol commented at 8:49 am on December 5, 2015: none

@sipa, I’m asking you to stick to the issue and contribute. Instead of sniping, add your piece and answer @Giszmo’s question.

laanwj commented at 9:07 am on December 5, 2015: member

@Giszmo I’ve heard some positive noises that Joinmarket is actually starting to be used. It’s making progress (one indicator is issues like #7101 being opened). @ABISprotocol Realize you’re accusing one of the most important contributors to bitcoin of ‘sniping’. CT is indeed not related to coinjoin and thus off-topic here, but you started mentioning it not @sipa, so what you say applies to you: stick to the issue.

MarcoFalke commented at 2:45 pm on December 5, 2015: member

@Giszmo: A year went by, JoinMarket is struggling […]

Do you have any data to support your claim?

Giszmo commented at 3:07 pm on December 5, 2015: none

Love CT and can’t wait to see them replece current version bitcoin transactions but that’s 5 years from now.

Joinmarket has very serious privacy leak and dos problems. Fake takers learn about makers. Failed joins leak info but don’t help for future joins. Auth UTXOs complicate the protocol and leak information to the makers. All that would not be a show stopper for wallet integration as it probably can be fixed (changing the api) but my gut feeling tells me that CoinShuffle will be superior very soon and I don’t want to bet on the wrong horse here.

ABISprotocol commented at 8:09 am on December 11, 2015: none

No-one has yet answered @Giszmo’s question at #3226 (comment)

laanwj commented at 9:34 am on December 11, 2015: member

If no one answers a question that likely means that no one knows an answer.

ABISprotocol commented at 12:51 pm on December 15, 2015: none

@laanwj @Giszmo Please see the following resources which may answer the question:

#3226 (comment)

and possibly some of the discussion here also, tangentially:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/1129

Note also Stealth addresses, CoinJoin available as js libraries: http://bitcoinjs.org and $ npm install stealth.js –save $ npm install coinjoin.js –save These can be found at:
https://github.com/darkwallet/stealth.js https://github.com/darkwallet/coinjoin.js Note: these repositories were last updated Oct. 2014

AdamISZ commented at 6:03 pm on January 7, 2016: none

@Giszmo as I expressed here and in the following comment, what CoinShuffle achieves is orthogonal to the privacy leak issue, which is based on JoinMarket’s design of makers announcing utxos - which itself is central to the solution to the coordination problem that JoinMarket provides. To put it another way, one could add CoinShuffle to JoinMarket, at the cost of quite a bit of extra complexity, and there would be significant benefit, but it would not solve that problem. Solutions I believe are more along the lines of what’s here

Edit: amplification, from the Coinshuffle paper: “Overview of CoinShuffle: First, the participants announce their input addresses…”

Giszmo commented at 3:36 am on January 23, 2016: none

It’s probably not a fair, in depth answer but as @AdamISZ aka /u/waxwing reminded me of my lacking answer, here is my comment on reddit on where I stand in that matter:

/u/waxwing I owe you a reply there and I didn’t get to it all week now, after your reminder here. Your reply links to “link collections” and always when I tried to reply I got lost in the tenth link or so but I’m pretty sure there is no real big misunderstanding on my part. JoinMarket is fighting the good fight and does consider using CoinShuffle, too, and Daniel Krawisz implementing it as open source, can only help with that. And with CS implemented and not having a “market” to get transactions that are wanted, we might need JM again but I don’t think that this is the case. Paying makers to mix, is in my opinion counterproductive to get honest makers and therefore I hope to avoid makers all together.

Our current concept is to have mixing accounts, where Mycelium would on auto-pilote shuffle coins to the desired degree of mixing and warn the user if he wanted to spend insufficiently mixed coins, preferably making this a default behavior for new HD accounts (but to spend mining fees for our users by default is really a tricky thing. But CS could have its fees sponsored but that’s details for later)

ABISprotocol commented at 4:27 am on January 23, 2016: none

Oh, wait, wait. I knew this would come up. To be fair, Mycelium is doing excellent work, and I know they are now partnering (or working on partnering) with Samourai, and all that. But what they are doing isn’t CoinJoin actually… It’s CoinShuffle in java. (Note: Mycelium called what they are working on CoinJoin on twitter… but it was actually not that)

I believe the only functional CoinJoin was that developed for DW. Somebody correct me if I’m wrong and drop a link to a repository showing another example of CoinJoin in action.

raedah commented at 4:54 am on January 23, 2016: none

@ABISprotocol https://github.com/JoinMarket-Org/joinmarket/ is functional.
See http://joinmarket.io/ and #7101

AdamISZ commented at 5:54 am on January 23, 2016: none

@ABISprotocol @raedah unfortunate timing, but all the bots crashed today due to rather trivial bug(the first time such a thing has happened in 6-8 months!).

So joinmarket.io shows much less activity than usual. But anyway, yes, ABISprotocol’s statement is definitely wrong; more to the point, it’s easy to verify for oneself by simply running a joinmarket bot; you can do a coinjoin any time, usually anything up to 10 btc can easily be done with say 5-10 counterparties, immediately. (Up to 100 is also possible, but liquidity is much less). @Giszmo I’ve answered on reddit, but I think the point I was making here stands; Coinshuffle doesn’t address the fact that you need to announce input addresses. You can “solve” that problem with a central server of course.

ABISprotocol commented at 8:31 am on January 23, 2016: none

@raedah @AdamISZ It’s good to know I’m wrong on this point! TYVM!

Giszmo commented at 3:21 pm on January 23, 2016: none

I feel like I repeat myself and to put it bluntly, here is why I believe that with JoinMarket, spies win. Mixing only makes sense when

no player has an incentive to be all counter-parties in a mix (makers get paid)
no player can track the matching (taker knows the matching) @ABISprotocol so technically you might claim that my solution (mix coins in a CoinShuffle account inside the wallet, then spend as normal transaction from there) is no coinjoin because the payment isn’t coinjoin? I would see that way more nuanced: Having a shuffling account would allow us to add trickling payments, where low priority payments can be made using shuffling, paying in increments to a BIP47 address. I would love to get my salary this way. It would only be a question of the contract giving this flexibility but then, why not have a payment every other day in varying amounts?

But yes, to do a privacy enhancing coinjoin transaction for an ad-hoc payment, something like JoinMarket would still be needed. At least until CTs are implemented in Bitcoin, at which point coinshuffle could be enhanced for ad-hoc payments and joinmarket wouldn’t be needed anymore.

AdamISZ commented at 3:49 pm on January 23, 2016: none

@Giszmo and as I have just answered in that reddit thread, Coinshuffle does not remove the possibility of the kind of spying you envision. According to your bullet points, you’re making the argument that because there is a financial incentive to take part, large scale sybil-to-spy is likely, but it’s a weird argument. No large spying organisation would be motivated by small coinjoin fees anyway (and indeed would choose very small/zero/negative fees). So effectively you’re saying that the absence of a market incentive would makes sybil less likely - but that’s just sybiling to make money, and is a problem that needs to be addressed with some kind of commitments; it’s got nothing to do with Coinshuffle.

ABISprotocol commented at 1:50 am on January 25, 2016: none

@Giszmo CoinShuffle is not the same thing as CoinJoin. CoinShuffle is based on the idea of CoinJoin but is different. From the CoinShuffle original paper, “CoinShuffle is inspired by CoinJoin to ensure security against theft and by the accountable anonymous group communication protocol Dissent to ensure anonymity as well as robustness against DoS attacks.” However, CoinShuffle is not the same as CoinJoin. Joinmarket, on the other hand, is a “CoinJoin implementation with incentive structure to convince people to take part.”

The original CoinJoin was published here, bounty was claimed in same message: https://bitcointalk.org/index.php?topic=279249.msg3016952#msg3016952 What appeared to have evolved from that is https://github.com/darkwallet/coinjoin.js and https://darkwallet.github.io/coinjoin.js/

(Edit: A DW “best-practices” document was published, which included references to CoinJoin, that can be seen here: https://wiki.unsystem.net/en/index.php/DarkWallet/Best_practices#CoinJoin)

Please correct if I am wrong here, but I am thinking that CoinShuffle is not considered a CoinJoin implementation, but something that is similar to it. A final consideration to add in this comment is that the CoinShuffle developers state on their page that “The (CoinShuffle) implementation is not at all developed with security in mind. It has been written purely to evaluate the feasibility and performance of CoinShuffle and is INSECURE. DO NOT USE THIS WITH YOUR COINS.”

ABISprotocol commented at 3:10 am on January 31, 2016: none

Hola CoinJoin thread folk, I just noticed this, a GUI joinmarket app in progress (ty @AdamISZ). Making things easier is important.

laanwj commented at 7:06 am on March 31, 2016: member

I’ve played with joinmarket for a bit and I think it’s getting pretty usable.

Would be awesome if bitcoin core’s wallet was able to interface with joinmarket to send transactions.

chris-belcher commented at 0:44 am on April 19, 2016: contributor

My current way of thinking for integrating joinmarket with Bitcoin-qt is to use the -walletbroadcast=0 flag. From https://github.com/JoinMarket-Org/joinmarket/issues/103 :

Set -walletbroadcast=0 and get the tx hex, extract from it the inputs and outputs, create a coinjoin from that information and broadcast it. The GUI might show an odd double spend attempt but the coinjoin tx will win because the non-coinjoin was never broadcast.

Of course you can send coinjoins from your Bitcoin Core wallet today by using the joinmarket sendpayment.py script with the –rpcwallet flag, which gets UTXOs, a change address and private keys through json-rpc and uses them to create a coinjoin. However it’s a command line app which only developers can love.

ABISprotocol commented at 2:43 am on June 8, 2016: none

Yep, it would be great to see this joinmarket functionality as an option in Core.

Sjors commented at 7:46 pm on March 16, 2018: member

Concept ACK on some sort of mixer support. Ideally using one of the new protocols that allow for signature aggregation, since a combination of increased privacy and lower cost would likely increase the number of users and thus the size of the anonymity set. In that case I vote for calling it “compression”.

laanwj closed this on Nov 22, 2019

Bushstar referenced this in commit 91a996e325 on Apr 8, 2020

MarcoFalke locked this on Dec 16, 2021

Implement coinjoin in wallet #3226