[ANN] Joinmarket - Coinjoin that people will actually use

[belcher]

FWIW I made a subreddit for the project. https://www.reddit.com/r/joinmarket

I came up with the idea of having the takers come up with a rating for each maker they trade with. Market makers are rated on response time, whether the maker's connection dropped halfway through or whether the maker sent a UTXO that had already been spent. This should provide market pressure that drives out flaky slow makers or those makers that DOS their counterparties. https://github.com/chris-belcher/joinmarket/issues/57

The very first version of tumbler.py was created. https://github.com/chris-belcher/joinmarket/blob/master/tumbler.py
Meaning you could get bitcoins from a very unprivate source like bitstamp, your employer or some guy off #bitcoin-otc, then use tumbler.py to almost completely break the link between addresses and regain you your privacy. This will probably be more important in the early stages when coinjoin still isn't common.
Then you could spend them on Magic: The Gathering cards, horse-imitation dildos, mental-health medicine or other embarrassing and taboo uses without worrying about anyone knowing.

Configuring JoinMarket to use the Bitcoin Core json-rpc interface now works. I've written a short guide here. https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node

[1713466580]

1713466580

[1713466580]

1713466580

[1713466580]

1713466580

[TheButterZone]

Looking forward to this being pulled into all major clients.

[belcher]

I'm pleased to announce the mainnet version of JoinMarket.

Expect glitches and a command line interface. But it works.

Here's some CoinJoins people have already done
https://blockchain.info/tx/601d9c15bc1edd2fe3e5c853ed111d11e9c0a5fb66c75571c7f10fa0d8ab23bb 5-party coinjoin
https://blockchain.info/tx/b85a3b563474ca98ba1809460e61a50053899c21f9869afb6a3a6d4b4cb00b7c 4-party coinjoin
https://blockchain.info/tx/e8b793b3464641df9404993c3101f81208b2d774f51a1ec748a608fbc9e22629 3-party coinjoin
https://blockchain.info/tx/665a9d7848cc0d28869ef866ca9a1117f20358e1e372dbbb01f1b75054584e70 3-party coinjoin

Only pocket change amounts for now, if anyone found an exploit bug they could theoretically clean out your wallet. My yield generator bot is running happily right now, I've already earned about 25000 satoshi.

I will be working on an Electrum plugin to make it easy to use. Electrum doesn't have a testnet version which is one reason we've moved to the mainnet now.

[K1773R]

This is a great project, thanks!

Do you/we need more testnet3 or/and mainnet yield bots?
Mainnet would be set as following?

Code:

network = mainnet

[HostFat]

If you have a project and you are receving donations, then this is a good place where putting them to get more income.

This is the new mining

[domob]

Very cool project, I'll be setting up my own yield generator soon to provide some liquidity.

[jdebunt]

Looking into this project for journalistic purposes

[waxwing]

This is a great project, thanks!

Do you/we need more testnet3 or/and mainnet yield bots?
Mainnet would be set as following?

Code:

network = mainnet

Correct. Be sure to read the README and the guides in the wiki on github carefully. That's just to start

[domob]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

2) If I want to run a yield generator (i. e., maker bot), do I need to accept incoming connections or is it also possible behind a firewall / NAT?

[K1773R]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

2) If I want to run a yield generator (i. e., maker bot), do I need to accept incoming transactions or is it also possible behind a firewall / NAT?

2) You mean incoming connections not transactions, right? No you dont, the communication is done with IRC, which works behind NAT/firewalled. you only need to be able to connect to snookernet IRC.

[domob]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

2) If I want to run a yield generator (i. e., maker bot), do I need to accept incoming transactions or is it also possible behind a firewall / NAT?

2) You mean incoming connections not transactions, right? No you dont, the communication is done with IRC, which works behind NAT/firewalled. you only need to be able to connect to snookernet IRC.

Yes, of course.  Fixed it, thanks for the answer!  That's great.

[waxwing]

They're trickling through. Just saw another join; 7 party: e38e45d004ef913ee4e952d1f185dbea91cc8cc56e22aa7f767a3edec952a4a9

Amounts small so far, which is to be expected. But all the same.

[belcher]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

How does knowing the maker's UTXOs become a huge privacy problem?
UTXOs are the inputs, coinjoins improve privacy because the outputs cannot be distinguished. One use of coinjoin is to regain privacy after it's been lost by bad practices, when your enemy already knows your UTXOs.

They're trickling through. Just saw another join; 7 party: e38e45d004ef913ee4e952d1f185dbea91cc8cc56e22aa7f767a3edec952a4a9

Amounts small so far, which is to be expected. But all the same.

Yes it's great. It's good people are using it despite the current command line interface.

My other coinjoin project I wrote, CoinJumble, had a nice GUI but it was probably never used more than once or twice. Incentives uber alles.

Here is an paragraph influential to me, from Mike Hearn's blog on coinjoin linked from the OP of this thread.

Perhaps the least discussed issue is user experience. A CoinJoin transaction requires other people to take part. The more people who take part, the better. But Bitcoin only peaks at about one transaction per second currently. Even if all transactions were CoinJoined, and all rendezvoused at a single point (ack, centralisation!), you would still have to wait 10-15 seconds to get a good set of participants to mix with. That’s just to start the protocol. Then those participants would all have to retrieve the candidate transaction and sign. If any time out, the whole thing has to start again. In poor conditions it could easily take a minute or more to complete this process, especially if some participants have flaky networks (i.e. phones) and are using Tor. Given that we’re trying to improve performance rather than reduce it, that seems like a big problem all by itself.

Whilst increasing traffic and usage would help reduce this issue, even if traffic doubled, splitting the single central rendezvous point would immediately put waiting times back to square one.

It's seems obvious now, but the GUI of CoinJumble provides a far worse user experience than the CLI of JoinMarket. And eventually I'll be done with the electrum plugin to allow easy point-and-click coinjoin.

Another use has been found for CoinJumble, it is excellent for debugging bitcoin raw transactions. It gives more detail than the bitcoind decoderawtransaction.

[domob]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

How does knowing the maker's UTXOs become a huge privacy problem?
UTXOs are the inputs, coinjoins improve privacy because the outputs cannot be distinguished. One use of coinjoin is to regain privacy after it's been lost by bad practices, when your enemy already knows your UTXOs.

But the outputs of previous joins might be UTXO's that makers offer again, no?  So if I query the market and find the current UTXO's of the makers, then I can "assume" that these specific outputs in the join transactions that produced them are, probably, not the mixing user's outputs.  Even further, if I determine the maker's UTXO's constantly over time, this could allow me to associate a single maker's input and output and thus (partially) deanonymise transactions.  Or is there something in JoinMarket that prevents this type of attack?

[belcher]

Two questions:

1) Is there a way for potential "takers" to find out which UTXO entries the makers are offering?  (E. g., by starting a join?)  If there is, isn't that a huge privacy problem, since you can determine which UTXO's are from makers and thus deanonymise past transactions they were part of?  If not, I must have misunderstood how the system works (since in my understanding, the taker builds the tx and thus needs a way to get maker UTXO's).

How does knowing the maker's UTXOs become a huge privacy problem?
UTXOs are the inputs, coinjoins improve privacy because the outputs cannot be distinguished. One use of coinjoin is to regain privacy after it's been lost by bad practices, when your enemy already knows your UTXOs.

But the outputs of previous joins might be UTXO's that makers offer again, no?  So if I query the market and find the current UTXO's of the makers, then I can "assume" that these specific outputs in the join transactions that produced them are, probably, not the mixing user's outputs.  Even further, if I determine the maker's UTXO's constantly over time, this could allow me to associate a single maker's input and output and thus (partially) deanonymise transactions.  Or is there something in JoinMarket that prevents this type of attack?

Eventually this attack will probably be prevented by anti-DOS code, since what you're suggesting would mean partially creating a coinjoin and then never completing it, many many times on a long-term basis.

It's not trivial to obtain all the maker's UTXOs because of the way the different identities in the internal HD wallet work.

You would not be able to deanonymize past transactions, only future transactions made with those UTXOs. i.e. you would have to get all the maker's UTXOs, wait for a coinjoin to happen, then gets all the UTXOs again and compare.

[Anduck]

Joinmarket used to make this: https://blockchain.info/tx/dc5b6d3f1fe45cd944fe30e2c28554267d7fb4c1d1a5ea199933be30205b5611
Not very easy job to unmix...

[domob]

But the outputs of previous joins might be UTXO's that makers offer again, no?  So if I query the market and find the current UTXO's of the makers, then I can "assume" that these specific outputs in the join transactions that produced them are, probably, not the mixing user's outputs.  Even further, if I determine the maker's UTXO's constantly over time, this could allow me to associate a single maker's input and output and thus (partially) deanonymise transactions.  Or is there something in JoinMarket that prevents this type of attack?

Eventually this attack will probably be prevented by anti-DOS code, since what you're suggesting would mean partially creating a coinjoin and then never completing it, many many times on a long-term basis.

It's not trivial to obtain all the maker's UTXOs because of the way the different identities in the internal HD wallet work.

You would not be able to deanonymize past transactions, only future transactions made with those UTXOs. i.e. you would have to get all the maker's UTXOs, wait for a coinjoin to happen, then gets all the UTXOs again and compare.

Yes, that's true.  I did not claim it was easy, just wanted to point this out - although I'm sure you thought about it already!  And I fully agree that it requires an attacker to be quite sophisticated and "active".  Even if this was possible easily, the joins would still prevent leakage of information through the chain alone - which is already a really great thing.

[belcher]

It's good to think about possible attacks so we can look out for them.

Privacy is a multi-faceted idea. I don't think CoinJoin or JoinMarket entirely solve the problem. A single CoinJoin does nothing to help with time-based or amount-based privacy invading, because the deals happen apparently instantly, and if you send in an amount of bitcoin you'll get back out that amount minus fees.

[domob]

It's good to think about possible attacks so we can look out for them.

Privacy is a multi-faceted idea. I don't think CoinJoin or JoinMarket entirely solve the problem. A single CoinJoin does nothing to help with time-based or amount-based privacy invading, because the deals happen apparently instantly, and if you send in an amount of bitcoin you'll get back out that amount minus fees.

Yes.  Nevertheless, I really think that JoinMarket could be "the" CoinJoin solution that actually takes off - due to the inherent profit incentives.  This would make it at least one important tool for privacy.

[Itskok]

This is really a nice idea!
I think that every attempt to promote coinjoin/mix or stealth addresses is welcome,we are just at the beginning of the study and i believe that in the future all of those "extra" security/privacy features will be default in every payment or wallet systems.
Regarding to your "market" idea,i think that it can be nice only as a feature at this point of time when bitcoin is not so popular, it cannot really be an enterprise solution,i think that mix/join solutions will be transparent for the users and embedded in their wallets,i dont think that users need to handle the question of 'who wanna mix me?",we need to find an automated way to mix transaction without dropping it on the users,same thing with the fees,systems must locate easily where is the cheapest mixers and works with them, but still the ideas just starting out and we can develop a lot of improvements for the future.
Good luck ,i am gonna follow it..