[ANN] Joinmarket - Coinjoin that people will actually use

[molecular]

^ @belcher: awesome.

I failed on a 3 party coinjoin a week or so ago. Not sure why, it just hung waiting for communication from one of the parties, I think.

[1714055403]

1714055403

[1714055403]

1714055403

[1714055403]

1714055403

[belcher]

Got a pastebin of the terminal in that case molecular?

[phelix]

I think this is a great idea.

Question: is there usually a backend bot managing the orderbook on #joinmarket-pit-test? Is it dead or am I misunderstanding?

The only central point of failure right now is the IRC server itself. It's not a centralized orderbook like gribble on #bitcoin-otc but more like an open-outcry trading pit. Bots announce their orders when they first join, and will repeat their orders in PM to whoever says !orderbook in channel.

By the way, I saw someone was doing coinjoins with a very small amount, like 666 or 3333 satoshi. Since my bot asks for a 1% fee, it earns not enough to cover the 1000 satoshi contribution to the miner fee. I didn't think of this attack, it's never good to look at your terminal and see "earned fee" being a negative number. Fixed now

You could also do it via a Bitmessage channel...

[marzo]

Very nice project.

Can someone please help with errors I am getting? (I am able to run the gui/web tool and the yield generator through which someone already traded, but can never run the send myself).

python sendpayment.py -N 1 "MY SUPER SECRET PASSWORD" 10000000 mXXXXXXXXXXaddress

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "sendpayment.py", line 85, in run
    utxos = self.taker.wallet.select_utxos(self.taker.mixdepth, self.taker.amount)
  File "/tmp/joinmarket-master/common.py", line 130, in select_utxos
    utxo_list = self.get_mix_utxo_list()[mixdepth]
KeyError: 0

Which packages are needed? I compiled & installed libsodioum, dnscrypt, "pip install libnacl" but may be missing something still.
Thanks in advance

[belcher]

marzo, looks like you might not have money in your wallet, in that particular mixing depth.
Did you wait for confirmations?
Otherwise control which mix depth you spend from with the -m command line flag.
If you can run yield generator fine, you've got all the dependencies installed.

phelix yes BitMessage would work. It would be an easy way to break the link between IP address and coinjoiner, also nobody could censor orders and thus control who you coinjoin with. It would be quite slow though, one advantage of IRC is the coinjoin takes barely any longer than a regular bitcoin transaction.

[waxwing]

Just a heads up for anyone trying it out - don't expect it be stable atm.
Update bots from github regularly

[belcher]

To whom does the bot with 122tbtc belong?  




It's quite interesting, I would think a large order size like that would be an opportunity to raise fees. Since if someone comes along who wants to join 50tbtc they only have one person who can do it.

[marzo]

marzo, looks like you might not have money in your wallet, in that particular mixing depth.
yes BitMessage would work. It would be an easy way to break the link between IP address and coinjoiner, also nobody could censor orders and thus control who you coinjoin with. It would be quite slow though, one advantage of IRC is the coinjoin takes barely any longer than a regular bitcoin transaction.

thanks! I got it to work once I funded more addresses/depths. Not 100% sure what they mean yet.
I vote for maximum privacy & anonymity (once the core tumbling code is all debugged, not urgent) -- that's the point of this project, not speed

[dillpicklechips]

Can it use coinshuffle for the mix?

[waxwing]

Can it use coinshuffle for the mix?

I think it's a very interesting protocol, and it's theoretically possible, however:

Coinshuffle is a way of creating unlinkability without the hassle and problems of (a) a centralised server and (b) requirement of anonymity networks (that model also needs blind signatures, but that's a well known tech). There's a payoff with the amount of counterparty interaction/messaging, which presumably blows up for large N, but that wouldn't be a big deal in practice (apart from code complexity and a little time cost). As for the blame part of the protocol, I haven't looked into it yet.

Anyway, to get to my point, it seems to me that in a weird kind of way JoinMarket might be argued not to need it: if the only person's coin privacy that counts is the taker (reminder that the basic transaction model here is 1 taker and N-1 makers), then the simple fact that the taker assembles the transaction and is the only one privileged to know output ordering means that, from the taker's point of view, the problem is addressed.

Of course we never forget that none of these protocols ever addresses N-1 colluders. You just want it to hold up with < N-1.

This is a bit of a weird way of looking at it and I may be wrong ... I'll think about it a bit more, would be interested to hear other opinions.

[dillpicklechips]

This would work perfect as a marketplace for when someone wants to use coinjoin for payments. Apps that have Coinjoin Payments enabled would find a useful maker in the market and create a suitable coinjoin to pay for the goods or services.

[waxwing]

This would work perfect as a marketplace for when someone wants to use coinjoin for payments. Apps that have Coinjoin Payments enabled would find a useful maker in the market and create a suitable coinjoin to pay for the goods or services.

Yes, this is one of the intended use cases. For example, an Electrum plugin. One could envisage some nominal extra amount added to the transaction fee (based on the market rate for a join). See under "Further Development" in the first post.

[belcher]

Would like input/ideas from the community
From https://github.com/chris-belcher/joinmarket/issues/28

If you were designing a tumbler that's hard to unmix using joinmarket, how would you do it?

[dillpicklechips]

Would like input/ideas from the community
From https://github.com/chris-belcher/joinmarket/issues/28

If you were designing a tumbler that's hard to unmix using joinmarket, how would you do it?

What about CoinShuffle (research paper on it) where the outputs are all the same amount as determined by what the taker needs for payments. Each person can have multiple outputs that are all the same and the addresses are hidden in layers almost like TOR.

[belcher]

Would like input/ideas from the community
From https://github.com/chris-belcher/joinmarket/issues/28

If you were designing a tumbler that's hard to unmix using joinmarket, how would you do it?

What about CoinShuffle (research paper on it) where the outputs are all the same amount as determined by what the taker needs for payments. Each person can have multiple outputs that are all the same and the addresses are hidden in layers almost like TOR.

It could be implemented I'm sure. It would involve a few more messages sent between taker and maker(s) and some more computation but thats all.

On the other hand, part of the problem that CoinShuffle solves is already solved in the JoinMarket model. The taker is the only entity who knows the mapping between inputs and outputs and the taker has an incentive to keep that mapping secret, because he's just paid money for it.

As for the tumbler issue, I'm more asking for suggestions about the output amounts, timings, number of participants and so on. And the tradeoffs involved in using these parameters and how they can be best be explained to users.

[riplin]

You guys might be interested in this:

https://www.reddit.com/r/Bitcoin/comments/2wfpzk/subspace_a_new_messaging_protocol_for_bitcoin/

It's still in early development, but it seems to be more scalable and more secure than BitMessage.

[belcher]

You guys might be interested in this:

https://www.reddit.com/r/Bitcoin/comments/2wfpzk/subspace_a_new_messaging_protocol_for_bitcoin/

It's still in early development, but it seems to be more scalable and more secure than BitMessage.

Thank you.
I heard about this just yesterday in fact. I've starred it on my github.

So a short update. I've been doing a fair amount of work to separate the IRC specific code, so that later another messaging channel can be easily slotted in. I've finished that now. And now Subspace is being talked about so of course I'll be watching it closely.

I did a coinjoin with 7 parties the other day. http://tbtc.blockr.io/tx/info/e8ea04db956b3726f580f758df7e99fbadfcaa81d61e18f0d5980773fa0f0ddd At first these transactions were very interesting, but now I essentially make them all the time and they have become mundane.

waxwing is working on separating the blockchain querying code, so bitcoind's json_rpc can be easily slotted in. This is quite important because right now we're querying blockr.io which is owned by coinbase.com

I will work on some stuff involving dust amounts and other details, then I'll finish a first simple version of tumbler.py. After that I plan to write an automated script that does lots and lots of coinjoins in an effort to find bugs. Soon after it should be good to try coinjoin with mainnet.

[phelix]

Any updates?

[waxwing]

Any updates?

Small update:
I've put in some code to create the ability to run a bot using your own bitcoind instance rather than reading from blockr.io . (See blockchaininterface.py).
There's also now a config file, joinmarket.cfg.

I also made an initial stab at creating test code - see regtesttest.py . This was motivated by the obvious limitations of testing against the real testnet blockchain in terms of delays and in terms of limited funds, participants. At some point I'd like to flesh that out by putting in tons of tests with multiple agents, weird balance sizes, weird wallet distributions etc. I already ran an 8 party join on it OK, which was interesting in as much as IRC didn't seem to complain.
Probably there's other kinds of testing worth looking at. Personally I think this aspect is more important than developing more functionality at this stage (except perhaps more UI).

None of that impacts anyone who's testing much, except I would appeal to anyone who's willing, to try running their bots using a local bitcoind -port=xx -rpcport=xy -testnet -daemon, and then setting the appropriate values in the config. Note that you *must* use bitcoin 0.10.
The code as it stands would need you to add bitcoin-cli to your $PATH.
You will also have to pay attention to the flags -txindex=1 (I *believe* you should set this on starting bitcoind), -reindex and also -rescan but I am not sure of the details. The reason this comes up is because of performance issues related to importing addresses into the wallet (this needs to be done so that we can see the history of a specific address). Either way, my experience has been that you will see some CPU load and maybe a few minutes delay when you start using a new joinmarket wallet because of this issue, but it goes away after that. It may be that future work will reduce this considerably, not sure. Belcher has started to look into that aspect.

[belcher]

Regarding the Chainalysis deanonymizing sybil attacker.

CoinJoin doesn't directly deal with IP-address based attacks.

However, because CoinJoin has multiple people, the final fully-signed transaction could be broadcast by any of them. This passive-monitoring sybil does not know that the different IP addresses are co-operating to create a CoinJoin.

For JoinMarket right now, it is always the taker who broadcasts the tx from their IP or through a blockchain explorer. This could be improved by having taker be able to send the fully-signed tx hex to one of the makers who will then broadcast it. The taker would choose to broadcast the txhex himself, or send it to one randomly chosen maker to broadcast. In this way the coinjoin tx could come from many IPs instead of just the taker's.
It could work quite well. The makers are already incentivized to allow their bitcoins to be coinjoined with, now they can be incentivized to allow their IP address to broadcast coinjoins. They don't earn their coinjoin fee unless they broadcast.


If you're interested in this project, you should follow the issue tracker on github. I write a lot of stuff there.
https://github.com/chris-belcher/joinmarket/issues