Implement coinjoin in wallet #3226
Comments
|
+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). |
|
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. |
|
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. |
|
.... 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. |
|
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. |
|
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. |
|
This needs to be moved up to high priority. http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/ |
|
"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. |
|
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. |
|
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. |
|
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. |
|
Note that step one will be to fix the wallet code's handling of double-spends. |
|
@petertodd Isn't there some double-spend detecion pull lingering around here? |
|
@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 |
|
Why does it depend on double spend handling? |
|
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? Just some thoughts. |
|
@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. |
|
Yeah that makes sense. |
|
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. |
|
@idiotsabound if you're not helping development, please don't distract us here |
|
@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. |
|
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? |
|
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. |
|
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. |
|
@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. |
|
Then provide an example of functional CoinJoin, being as there are examples out there and the bounty on it was long ago claimed. |
|
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. |
|
@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. |
Do you have any data to support your claim? |
|
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. |
|
No-one has yet answered @Giszmo's question at #3226 (comment) |
|
If no one answers a question that likely means that no one knows an answer. |
|
@laanwj @Giszmo Please see the following resources which may answer the question: and possibly some of the discussion here also, tangentially: bitcoin-dot-org/Bitcoin.org#1129 Note also Stealth addresses, CoinJoin available as js libraries: |
|
@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..." |
|
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:
|
|
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. |
|
@ABISprotocol https://github.com/JoinMarket-Org/joinmarket/ is functional. |
|
@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. |
|
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
@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. |
|
@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. |
|
@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: (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." |
|
Hola CoinJoin thread folk, I just noticed this, a GUI joinmarket app in progress (ty @AdamISZ). |
|
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. |
|
My current way of thinking for integrating joinmarket with Bitcoin-qt is to use the -walletbroadcast=0 flag.
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. |
|
Yep, it would be great to see this joinmarket functionality as an option in Core. |
|
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". |
…espite node restarts (bitcoin#3226) * Pass nAcceptTime via TransactionAddedToMempool and use it for ChainLocks Otherwise the "first seen" time is way off after node restart * Don't skip TransactionAddedToMempool for chainlocks while blockchain is not synced yet Otherwise txes from mempool.dat won't be processed there
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)
The text was updated successfully, but these errors were encountered: