Topic: [ANN] Joinmarket - Coinjoin that people will actually use - page 15. (Read 84864 times)

Its down, clearnet + I2P unreachable.

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.

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

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.

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:

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.

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.

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!

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.

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?

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.

Relative fees are a percentage of the coinjoin amount

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 !

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.

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.

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.

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.

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.. 

 

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.

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, 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.