[ANN] Joinmarket - Coinjoin that people will actually use

[theymos]

Good to see that some progress is being made on usable CoinJoin. This seems like the best CoinJoin project around currently.

Some possible ideas/improvements come to mind:
- Tor should be easier to use. Probably the default configuration should be to use Tor.
- Only Tor-friendly IRC servers should be used, and only over TLS.
- To reduce centralization, multiple IRC servers could be used. Makers would idle on all of the servers, and takers would find partners using multiple randomly-selected IRC servers. If any servers are down, Joinmarket should issue a warning, as this may be a DoS attack on the IRC server designed to funnel people to attacker-controlled servers.
- Instead of requiring NickServ registration, makers could generate an identity separately (maybe just a Bitcoin address) and communicate it on the IRC channel using public-key crypto. This is more convenient and will work across multiple IRC servers.
- In exchange for a (comparatively large) extra fee, takers could require that the unspent-outputs provided by makers be x blocks deep (I'm thinking ~1500). This reduces the Sybil risk because an attacker will only have so many bitcoins, and this requirement ties up a lot of their bitcoins for a while if a lot of takers are routinely requiring that at least some of their partners provide old bitcoins.

[domob]

Market pressure seems to be rising ... I just lowered my fees a bit.  That's good, as the ultimate goal should be to have almost-zero fees due to competition.  I've still not seen many joins happen, though, and only for tiny amounts.  But this is expected since the project is quite new.

[waxwing]

- Instead of requiring NickServ registration, makers could generate an identity separately (maybe just a Bitcoin address) and communicate it on the IRC channel using public-key crypto. This is more convenient and will work across multiple IRC servers.

This is already in place, but only in one sense. We decided that the appropriate idea here is a kind of 'functional identity' - the participants identify themselves with btc signatures *of their encryption pubkey* corresponding to the utxo they use in the tx construction.
I originally coded it so that the public key crypto keypair (what I called 'encryption pubkey' in the above sentence) was persistent for that participant, however we decided that the more elegant model was to dynamically create keypairs on the fly on a per-tx basis (it keeps the model much simpler and more transparent to the user).
It does lose the persistent identity doing it that way; but there's nothing stopping us adding another layer on top for that. The whole DOS resistance angle is being discussed very actively.

[belcher]

Good to see that some progress is being made on usable CoinJoin. This seems like the best CoinJoin project around currently.

Some possible ideas/improvements come to mind:
- Tor should be easier to use. Probably the default configuration should be to use Tor.
- Only Tor-friendly IRC servers should be used, and only over TLS.
- To reduce centralization, multiple IRC servers could be used. Makers would idle on all of the servers, and takers would find partners using multiple randomly-selected IRC servers. If any servers are down, Joinmarket should issue a warning, as this may be a DoS attack on the IRC server designed to funnel people to attacker-controlled servers.
- Instead of requiring NickServ registration, makers could generate an identity separately (maybe just a Bitcoin address) and communicate it on the IRC channel using public-key crypto. This is more convenient and will work across multiple IRC servers.
- In exchange for a (comparatively large) extra fee, takers could require that the unspent-outputs provided by makers be x blocks deep (I'm thinking ~1500). This reduces the Sybil risk because an attacker will only have so many bitcoins, and this requirement ties up a lot of their bitcoins for a while if a lot of takers are routinely requiring that at least some of their partners provide old bitcoins.

Thanks for the post.

IRC was only ever intended as a starting point, eventually another messaging channel will be found because ultimately IRC will always been inferior. There are a few ideas for which p2p network to use, the most promising being https://github.com/cpacia/Subspace still in development which is explicitly designed for coinjoin. That will surely allow Tor too.

Adding the UTXOs x blocks deep as a parameter to be agreed upon in the market is a good idea. Transactions using deeper txouts as input will get higher priority and potentially confirm faster as well.

[laurentmt]

Just a question regarding the fees. Relative fees announced by the maker are paid by the taker to the maker. On which amount is the ratio applied: the coinjoined output ? All inputs from the taker ? ...

Thanks in advance !

[belcher]

Just a question regarding the fees. Relative fees announced by the maker are paid by the taker to the maker. On which amount is the ratio applied: the coinjoined output ? All inputs from the taker ? ...

Thanks in advance !

Relative fees are a percentage of the coinjoin amount

[justusranvier]

IRC was only ever intended as a starting point, eventually another messaging channel will be found because ultimately IRC will always been inferior. There are a few ideas for which p2p network to use, the most promising being https://github.com/cpacia/Subspace still in development which is explicitly designed for coinjoin. That will surely allow Tor too.

It would be great to have an open standard messaging protocol and get it implemented in many wallets.

Until all wallets that use mixing are accessing the same pool of participants, it's never going to work very well.

See Darkwallet for an example. They have an excellent GUI for mixing, but since they can only mix with other Darkwallet users, in practise their mixing capability is useless.

[domob]

It seems that the maximum order size my yield-generator provides is limited by the maximum balance in any one mix depth level.  Is this correct?  I. e., if I have 1 BTC in the wallet and use the default mix levels setting of 5, it may happen (in the worst case) that only 0.2 BTC are available for any one order.  Is there a way to get around that restriction?  If I do not care too much about my own privacy (as a market maker) and want to increase the provided liquidity of my bot, can I somehow specify that I want certain mix levels to be used together in orders?  I tried lowering the mix depth setting in yield-generator.py, but it only had the effect that coins in lower levels of my wallet were not seen at all.

Also, what happens if coins on level 4 (the lowest configured level) are used in an order?  Will they drop to level 5 and be completely useless for the bot, or will they stay at the minimum level forever?

[belcher]

It seems that the maximum order size my yield-generator provides is limited by the maximum balance in any one mix depth level.  Is this correct?  I. e., if I have 1 BTC in the wallet and use the default mix levels setting of 5, it may happen (in the worst case) that only 0.2 BTC are available for any one order.  Is there a way to get around that restriction?  If I do not care too much about my own privacy (as a market maker) and want to increase the provided liquidity of my bot, can I somehow specify that I want certain mix levels to be used together in orders?  I tried lowering the mix depth setting in yield-generator.py, but it only had the effect that coins in lower levels of my wallet were not seen at all.

Also, what happens if coins on level 4 (the lowest configured level) are used in an order?  Will they drop to level 5 and be completely useless for the bot, or will they stay at the minimum level forever?

Perhaps a reminder of the point of mixing depths. Merged transaction inputs are damaging to privacy because they provide evidence of common ownership. Each mixing depth is a different identity, coins are never merged in the same transaction across mixing depths, but may be merged within mixing depths. Coins move between mixing depths through coinjoins. A change output stays in the same mixing depth. This prevents the situation where a change output is merged with a coinjoin output in a later transaction, which would render the coinjoin easily unmixable.

If you wanted to make maximum profit above all else, you could recode the bot to not bother with mixing depths. However when you come to do deals with taker bots, they look back in the blockchain to see if there's evidence of you ruining privacy like that. You may find they are unwilling to trade with you, after all they're paying money to you to improve their privacy and there's no point if you'll just undo the mixing.
I haven't yet coded this feature of the taker looking backwards in the blockchain, but it shouldn't be too difficult. If somebody recoded their bot it would motivate me to move that feature up my to-do list.

If your coins are coinjoined from the lowest level, they will wrap around and end up in the highest level. So they will always be available.

If you want to increase your max amount you could move all your coins back to level zero (use sendpayment.py with amount=0 to sweep) and set the max mixing depth to 2 or 3 instead of 5.

Another thing you could do is recode the algorithm. A market maker can announce many orders (thats what the order ID parameter is for), you could write it to make mixing levels with smaller amounts still be announced, possibly with slightly smaller fees to incentivize takers to coinjoin them and move the coins into the larger mixing depth to make it even larger. In other words, make taker's incentivized to keep your coins clumped together in one mixing depth.

Lastly, to increase liquidity you could simply buy more bitcoins and deposit them into the bot. After all, they're quite useful now, you can earn an income with them with very low risk.

In the future there will be coinjoins with many output sizes, for making the sendmany command with coinjoin. In those transactions a market maker could spend from many mixing depths at once as long as the amounts do not lead to trivial unmixing.

[domob]

Thanks for the detailed reply!  I'm of course aware that merging outputs is damaging to privacy.  My main concern is not to make the most profit, but to fully understand how the system works - in particular what the worst case is.  If coins are wrapped around from lowest to highest level, this makes it clear that always at least 1/5 of the deposited coins are available for an order - which is good to know.  After all, these orders provide liquidity to the market (and not just opportunity to make profit for me).

Regarding your other ideas:  Improving the taker algorithm to analyse how well the makers handle privacy seems like a very interesting project!  And it proves you are really serious about the future of JoinMarket.  (Although I think it will be a challenge to implement an algorithm that is really intelligent about estimating the privacy afforded by specific behaviour.)  This makes me very positive (more than already ) about this project!

[dserrano5]

Sharing domob's concern and trying to consolidate one of my lesser mixing depths into a wealthier one, I'm in a situation where ironically you @domob (well, your yieldgen), are preventing me from doing it .

I'm sweeping mixing depth 4 onto 0. According to sendpayment.py's usage, when sweeping, I can't choose my partners. sendpayment.py consistently offers me the chance with domob-foo, probably due to the low fees. However, reproducibly, domob-foo QUITs in the middle of the transaction, only to JOIN a few seconds after. I suspect it crashes for some reason.

[belcher]

Sharing domob's concern and trying to consolidate one of my lesser mixing depths into a wealthier one, I'm in a situation where ironically you @domob (well, your yieldgen), are preventing me from doing it .

I'm sweeping mixing depth 4 onto 0. According to sendpayment.py's usage, when sweeping, I can't choose my partners. sendpayment.py consistently offers me the chance with domob-foo, probably due to the low fees. However, reproducibly, domob-foo QUITs in the middle of the transaction, only to JOIN a few seconds after. I suspect it crashes for some reason.

You can pick the makers yourself using the -P flag in sendpayment.py, eventually I'll change the format of those command line flags because they're a bit rubbish.

Eventually they'll be a reviewing system which will end up with market makers who have flaky slow internet connections like domob being avoided for coinjoins. For now you just have to work around known dodgy makers.

It's odd that domob has named his market maker in a way everyone know's its associated with him.

[domob]

Eventually they'll be a reviewing system which will end up with market makers who have flaky slow internet connections like domob being avoided for coinjoins. For now you just have to work around known dodgy makers.

The joins worked fine before, it seems that the IRC server was changed to require SASL authentication.  The SASL authentication did not work before, however, for some bug in the code - it has nothing to do with the internet connection.  I've updated to latest HEAD and now it apparently works.

It's odd that domob has named his market maker in a way everyone know's its associated with him.

For now I do not really need privacy myself.  Is there any other reason why I wouldn't want to do that?

EDIT: At least that's how I interpret the situation.  The log shows this:

[2015/05/29 07:18:18] sendraw PRIVMSG XYZ :!relorder 0 3000000 61404193 500 0.0002 ~
[2015/05/29 07:18:18] << :cgan.onion.garlic 477 domob-foo XYZ :You need to be identified to a registered account to message this user

[dserrano5]

I'm sweeping mixing depth 4 onto 0. According to sendpayment.py's usage, when sweeping, I can't choose my partners.

You can pick the makers yourself using the -P flag in sendpayment.py

Code:

$ python sendpayment.py --help

Setting amount to zero will do a sweep, where the entire mix depth is emptied

  -P, --pick-orders     manually pick which orders to take. doesn't work while sweeping.

So no, I can't -P. Well I must admit I didn't try… I'm a well behaved citizen

[domob]

It seems the IRC server went down a few minutes ago - or is it just for me?  Note, though, that I can neither connect from JoinMarket with nor without Tor, and also not from my ordinary IRC client (with Tor) anymore.

[K1773R]

It seems the IRC server went down a few minutes ago - or is it just for me?  Note, though, that I can neither connect from JoinMarket with nor without Tor, and also not from my ordinary IRC client (with Tor) anymore.

Its down, clearnet + I2P unreachable.

[inaltoasinistra]

It seems the IRC server went down a few minutes ago - or is it just for me?  Note, though, that I can neither connect from JoinMarket with nor without Tor, and also not from my ordinary IRC client (with Tor) anymore.

Is cyberguerrilla IRC network composed by only one IRC server?

[K1773R]

It seems the IRC server went down a few minutes ago - or is it just for me?  Note, though, that I can neither connect from JoinMarket with nor without Tor, and also not from my ordinary IRC client (with Tor) anymore.

Is cyberguerrilla IRC network composed by only one IRC server?

Code:

:irc.cgan 251 foo :There are 2 users and 116 invisible on 4 servers
:irc.cgan 252 foo 28 :operator(s) online
:irc.cgan 254 foo 61 :channels formed
:irc.cgan 255 foo :I have 65 clients and 2 servers
:irc.cgan 265 foo :Current Local Users: 65  Max: 202
:irc.cgan 266 foo :Current Global Users: 118  Max: 253

[BitDreams]

One piece of the puzzle towards individual transactional data ownership.

[coinchip]

I installed this and looked at the order book.

Code:

Type            Counterparty    Order ID        Fee     Miner Fee Contribution  Minimum Size    Maximum Size
...
Relative Fee    prodigiosbot    0               0.06%   0.00001                 0.01833333      5.67423214
Relative Fee    Engystomo       0               0.067%  0.00001                 0.01791044      3.53394155
...
Relative Fee    Constanti       0               0.3%    0.00001                 0.1             5.7824916
...

I guess these are all makers? The takers don't show up in the order book or maybe there were no takers when I looked?

So if I made 100 BTC available and set a fee of 0.3%, then I would make:

Taker uses 1 BTC: 1 * 0.3% = I make 0.003 BTC
Taker uses 10 BTC: 10 * 0.3% = I make 0.03 BTC
Taker uses 100 BTC: 100 * 0.3% = I make 0.3 BTC

?

But if I put 100 BTC in the wallet the maximum size would actually be 20 BTC after a while due to the different mix levels?

Just trying to gauge the practical potential earnings.