[ANN] Joinmarket - Coinjoin that people will actually use

[belcher]

JoinMarket is built for those who:
1. Want to use coinjoin to improve the privacy of their bitcoin transactions or reduce the miner fees they pay.
2. Want to earn an income from their investment bitcoins

Coinjoin is a kind of bitcoin transaction which combines multiple people's transactions together in an effort to improve privacy, especially as a way to regain privacy after it's been degraded by bad practices. It can also reduce the size of transactions and so require less miner fees. The concept has enormous potential, but it has not seen widespread usage so far despite the multiple projects that implement it. I believe this is because the incentive structure was not right.

A coinjoin transaction requires other people to take part. The right resources (coins) have to be in the right place, at the right time, in the right quantity. This isn't a software or tech problem, its an economic problem. I propose a new kind of market is created that would allocate these resources in the best way.

In practice this would work by allowing coinjoin transactions to be paid-for. On one side there will be time-rich coinjoiners who will wait around and be willing to coinjoin at any time. On the other side will be time-stressed coinjoiners who can coinjoin instantly for a price.

This will naturally attract investors, holders of bitcoin who don't want to transact but just want to earn the coinjoin fee. They would be taking on only a very small amount of risk; Their private keys would never leave their computer, the software would only sign transactions that are valid and pay the correct amount of coins. So it's safe to say that investors would pour in, resulting in the coinjoin fees being very low.

Elevator Pitch for Coinjoin Users / People who desire privacy.

With Joinmarket nobody can steal your coins, you would mix them on your own computer. The software will never sign a transaction unless your coins are going to exactly the right address in the right amount.

Other mixing services mix your coins with other users, resulting in you getting back coins possibly related to drugs, stolen money or other illegal or immoral practices. This is highly undesirable if you just don't want your employer knowing which non-profits you support from your salary. Because of the incentives of JoinMarket, you have access to a huge amount of clean, untainted bitcoins to mix with at a very low price. Many of the bitcoins you're mixing with will be bought from regulated exchanges, owned by legitimate holders of bitcoin.

Not to mention you'd likely be paying lower fees for mixing than other services, because of the competition between willing-to-wait coinjoiners. Indeed if you don't mind waiting, you can wait around with a low offer fee and maybe another impatient coinjoiner will join with you.

Elevator Pitch for Investors

Firstly I'd like to clarify what I mean by investing. I don't want you to give your bitcoins to me. I dont want you to give your bitcoins to anybody. The private keys would be safely held on your own computer, known only by you and your wallet.

Features:
1. Earn an income from your investment bitcoins.
2. Very low risk. Your coins have to be on an online computer, but the software would only sign transactions that are valid and pay you the correct amount.
3. No commitment, withdraw your bitcoins at any time.
4. Improves the privacy of the bitcoin transactions, which makes bitcoin as a currency more useful and thus increases its value.
5. Improves the fungibility of bitcoin, since the distinction between 'clean' and 'dirty' bitcoins will be meaningless. Eliminates this particular systemic risk to bitcoin.

Downside:
1. Your return is likely to be quite low. Low risk = low reward.
2. You don't get paid unless people who desire privacy actually use this. If you're an investor you have an incentive to tell people about JoinMarket and contribute to it.

The Software

I've been writing an implementation of the idea. Right now the coinjoiner bots meet in an IRC channel. The bots announce their orders in an open-outcry trading pit style. Transaction data is sent between users as IRC private messages. Authenticated encryption is used to stop the IRC server eavesdropping. I have plans one day to move away from IRC entirely and have the users meet in some kind of peer to peer network.

How to try
Download the repository from https://github.com/JoinMarket-Org/joinmarket-clientserver and read the README file
There is an internal HD wallet. It is generated from a wallet encrypted on your hard drive.

There's also plenty of information on the github docs: https://github.com/JoinMarket-Org/joinmarket-clientserver/tree/master/docs

Code:

$python wallet-tool.py generate
   Generates a new wallet. Asks for your encryption passphrase and gives you a 12-word recover seed to write down on paper, a la Electrum or Mycelium.

$ python wallet-tool.py [wallet file name]
  This will print out addresses from the HD wallet, send some coins to the first receive address

$ python yield-generator.py [wallet file]
  Becomes an investor bot, being online indefinitely and doing coinjoin for the purpose of profit

$ python sendpayment.py -N 4 [wallet file] [amount-in-satoshi] [destination address]
  Chooses the cheapest offer to do a 5-party coinjoin to send money to a destination address

If you're a frugal user and don't feel like paying to coinjoin if you dont have to, use this command
$ python patientsendpayments.py -N 1 -w 2 [wallet file] [amount in satoshi] [destination address]
  Announces orders and waits to coinjoin for a maximum of 2 hours. Once that time it up cancels the
  orders and pays to do a 2-party coinjoin.

$ python ob-watcher.py
  Starts a local http server which you can connect to and will display the orderbook as well as some graphs

$ python wallet-tool.py recover
  Will prompt for the 12 word recover seed and create a new encrypted wallet file

$ python wallet-tool.py -p [wallet file]
  Will print out addresses along with private keys which can be used to sweep the coins away

Example coinjoins transactions made with JoinMarket:
14 parties, amount 0.01btc https://blockchain.info/tx/55eac9d4a4159d4ba355122c6c18f85293c19ae358306a3773ec3a5d053e2f1b
11 parties, amount 0.57960945btc https://blockchain.info/tx/402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a
8 parties, amount 2.6btc https://blockchain.info/tx/722bb2662cb2ef9b4a2693e52ba82c44cea1042349f1aa6e71e28a3947aa4144
7 parties, amount 0.02btc https://blockchain.info/tx/e38e45d004ef913ee4e952d1f185dbea91cc8cc56e22aa7f767a3edec952a4a9
3 parties, amount 25btc https://blockchain.info/tx/da1a2259be752dd6b5162221989181b7334bd0acbbc1bca31596e5bc32375770
4 parties, amount 40btc https://blockchain.info/tx/3b97544488cac0271a80b20822597342648d19ed02ac25041bd8d35e624d8e6b
3 parties, amount 12btc https://blockchain.info/tx/d91278e125673f5b9201456b0c36efac3b2b6700fdd04fc2227352a63f941170
4 parties, amount 0.84btc (~$200 at contemporary exchange rate) https://blockchain.info/tx/7d588d52d1cece7a18d663c977d6143016b5b326404bbf286bc024d5d54fcecb
4 parties, amount 0.1btc https://blockchain.info/tx/b85a3b563474ca98ba1809460e61a50053899c21f9869afb6a3a6d4b4cb00b7c
3 parties, amount 0.19btc https://blockchain.info/tx/2e2cd9204f97a2260ba5b1fd446f394eeff79daa973e37dd29794a9ee667bf64

Further Development
Github: https://github.com/chris-belcher/joinmarket
IRC: irc.freenode.net #joinmarket
Twitter: https://www.twitter.com/joinmarket
Reddit: http://www.reddit.com/r/joinmarket

If you can program, contribute code. The project needs development works more than anything else right now. A list of suggested projects are here https://github.com/chris-belcher/joinmarket/wiki/What-can-I-do-for-JoinMarket%3F

If you require privacy, JoinMarket can be used right now on the mainnet, albeit with a command-line interface. Many people are already using it.

Bitcoin Core wallet could be integrated by using the -walletbroadcast=0. Integration on the command line using json-rpc calls is already done, use the --rpcwallet flag on sendpayment.py

I have plans to create an Electrum plugin which does this, it would be a simple checkbox and thereafter all transactions would be coinjoined.

If you run your own yield generator bot, you can earn an income from your bitcoin savings and increase the privacy and anonymous set of others.

People trust systems more if they think they know how it works. If you're good with graphics, you can help the project by creating an infographic for how it all works. For example how coinjoin transactions in the joinmarket software are communicated, created, checked and signed.

Snazzy websites are better for getting the word out than big walls of text on a forum.

Further Reading
gmaxwell's original coinjoin post. https://bitcointalk.org/index.php?topic=279249.0
my original Joinmarket suggestion / writeup. https://bitcointalk.org/index.php?topic=279249.msg9384411#msg9384411
Mike Hearn's blog post about privacy and coinjoin https://medium.com/@octskyward/merge-avoidance-7f95a386692f

[1695648977]

1695648977

[1695648977]

1695648977

[1695648977]

1695648977

[1695648977]

1695648977

[belcher]

Reserved

[onemorebtc]

aradesh@aradesh:~/src/joinmarket$ python yield-generator.py blahhh
downloading wallet history
no tx used
Traceback (most recent call last):
  File "yield-generator.py", line 95, in <module>
    main()
  File "yield-generator.py", line 90, in main
    maker = YieldGenerator(wallet)
  File "yield-generator.py", line 26, in __init__
    Maker.__init__(self, wallet)
  File "/home/aradesh/src/joinmarket/maker.py", line 129, in __init__
    self.orderlist = self.create_my_orders()
  File "yield-generator.py", line 42, in create_my_orders
    max_mix = max(mix_balance, key=mix_balance.get)
ValueError: max() arg is an empty sequence

i guess i should start mining

[belcher]

aradesh@aradesh:~/src/joinmarket$ python yield-generator.py blahhh
downloading wallet history
no tx used
Traceback (most recent call last):
  File "yield-generator.py", line 95, in <module>
    main()
  File "yield-generator.py", line 90, in main
    maker = YieldGenerator(wallet)
  File "yield-generator.py", line 26, in __init__
    Maker.__init__(self, wallet)
  File "/home/aradesh/src/joinmarket/maker.py", line 129, in __init__
    self.orderlist = self.create_my_orders()
  File "yield-generator.py", line 42, in create_my_orders
    max_mix = max(mix_balance, key=mix_balance.get)
ValueError: max() arg is an empty sequence

i guess i should start mining

yield-generator's way of telling you you've got no money.

You can also get testnet coins from various faucets. Look at the links at the bottom of this. https://en.bitcoin.it/wiki/Testnet

[onemorebtc]

You can also get testnet coins from various faucets. Look at the links at the bottom of this. https://en.bitcoin.it/wiki/Testnet

already searching, but the only testnet-ewallet which gives me a seed instead of an address does not work currently.

[belcher]

You can also get testnet coins from various faucets. Look at the links at the bottom of this. https://en.bitcoin.it/wiki/Testnet

already searching, but the only testnet-ewallet which gives me a seed instead of an address does not work currently.

You're misunderstanding.
The seed that you pass to scripts like wallet-tool.py and yield-generator.py are like brainwallets, they can be anything. For real bitcoins you would generate them from a 12-word mnemonic like Electrum does.

Come up with any seed and store it somewhere safe. Pass it as a command line argument to wallet-tool.py, which will print out a bunch of addresses. Copypaste the first of those addresses into a testnet faucet.

Aside: Because I'm a newbie the forum is rate limiting my posts to 5 minutes apart. It's quite annoying, any chance a mod can bump me up? given I've already demonstrated I'm not a spammer.

[onemorebtc]

thanks.

i've contacted mods through the report link... maybe they'll change it.

[jt byte]

good luck with your project

[molecular]

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?

"!orderbook" doesn't return anything.

EDIT: ah, got it: it's sent via pm

[belcher]

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

[molecular]

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.

I see.

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

That was me .

[melwinder]

This sounds like a good idea, I am not much of a techy to be able to put together this kind of project, but I will be looking forward to see what other people will do with it

[marcus_of_augustus]

promising

[dserrano5]

I just set up a maker with 0.0999 btc. Let's see if someone bites!

[belcher]

Merged waxwing's encryption pull request.
Now a taker and maker(s) will send their output addresses through an encrypted channel so an eavesdropping IRC server cannot unmix the coinjoin.

Though that means the pre- and post-encryption bots cannot understand each other. Please pull the latest commits if you're trying it out. You also need to install libsodium cryptographic library.

Read about the protocol here: https://github.com/chris-belcher/joinmarket/blob/master/encryption_protocol.txt

[dserrano5]

Though that means the pre- and post-encryption bots cannot understand each other. Please pull the latest commits if you're trying it out. You also need to install libsodium cryptographic library.

Done. My maker process disappeared somehow at some point, no clues about that. I just brought it up again using the new updates.

[phelix]

Interesting!

[goregrind]

If you're trying to run this on debian systems you might run into problems regarding nacl and libsodium
Since theres no pre-packaged libsodium you will have to install this manually as per:
http://askubuntu.com/questions/330589/how-to-compile-and-install-dnscrypt
and then run: pip install libnacl

[waxwing]

If you're trying to run this on debian systems you might run into problems regarding nacl and libsodium
Since theres no pre-packaged libsodium you will have to install this manually as per:
http://askubuntu.com/questions/330589/how-to-compile-and-install-dnscrypt
and then run: pip install libnacl

Thanks for this. Indeed, you have to install it manually; the latest version is 1.02 as at https://download.libsodium.org/libsodium/releases/. And follow the simple instructions at http://doc.libsodium.org/installation/README.html

Sorry that things are not at all well documented yet. Things are still very much in flux

As for packaging, it seems likely that binaries will be packaged with signatures at some point.

[belcher]

I noticed tonight there were four yield-generators in the pit. So I went ahead and did a five-party coinjoin.

The command was

Code:

python sendpayment.py -N 4 [seed] 50000000 [dest addr]

Four times the bot sent out the fill command, four times it did the encryption handshake, four times it received a list of UTXOs and destination addresses. It made those into a transaction along with its own inputs and outputs. Then it sent the transaction out four times and waited for four signatures to return. Each of the signatures was valid so the bot added them to the transaction and pushed it to the network. All without crashing, I was amazed. The whole thing took barely any longer than a two-party coinjoin since it all runs in parallel.

https://tbtc.blockr.io/tx/info/095a75f189cb7bd95fc57fb309d5010e09771971243847b5d3ea232ac2518333

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

[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

[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

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

 

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

[inaltoasinistra]

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?

20 BTC for account is the minimum, but JM tries to increase the maximum balance at every transaction, so the average should be quite over 20BTC.
In future may be possible to charge less if a transaction increase the maximum balance [feature request?]

[waxwing]

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?

The idea is that the "makers" are "offering liquidity" with their orders (offers is probably a better word than orders here). They are publishing these offers. The takers then come along and ... take these offers They do that by private messaging to the makers to request the initiation of a coinjoin transaction. After an initial "handshake", this communication is E2E encrypted. The intended result is that the taker (who's paying the fee) is getting maximal privacy. No one else (including the makers) knows which output corresponds to the taker's input, assuming more than one maker is involved (notice: in a 2 party coinjoin, there is *no* cryptographic magic trick that can prevent your counterparty from knowing your output - it's the one that isn't his!).

[inaltoasinistra]

Proposal:

JM uses the Electrum seed management (seeds are compatible to Electrum wallet) but a different addresses derivation (the same seed generates different addresses into Electrum and into JM).
Since JM is multiaccount and Electrum not this behaviour is normal.

An interesting alternative could be mapping the first JM identity (included change addresses) to the Electrum one. In this manner would be possible to receive and send coins from Electrum, and automatically share on JM received coins, without move them manually between wallets.

This would require a little modification to the JM tx creation policy: when it is possible a coinjoin tx will move coins to the Electrum identity.

[ThePiGuy]

Has anyone created a definitive guide on setting up to make money with this system by using Bitcoin Core?  I'm really interested in becoming an investor, but need more information!

[belcher]

ThePiGuy https://github.com/chris-belcher/joinmarket/wiki/Running-a-Yield-Generator

inaltoasinistra Yeah that could be done I guess.
Bare in mind JoinMarket uses the old mnemonic seeds but Electrum bip32 wallets use the new seeds. Anyone updating it would have to keep the code for old seeds in the codebase forever.

[coinchip]

Has anyone created a definitive guide on setting up to make money with this system by using Bitcoin Core?  I'm really interested in becoming an investor, but need more information!

You read my mind. I've been keeping an eye on this project for a month waiting for the literature to improve to a place where I feel comfortable investing. It's not just a simpler setup or clearer instructions, it's providing information on the benefits and risks to an investor.

ThePiGuy https://github.com/chris-belcher/joinmarket/wiki/Running-a-Yield-Generator

I know you're a tech guy but take a step back and look at the title of that page: Running-a-Yield-Generator. The page you need is "Guide for Investors". It should have:

• What is Joinmarket?
  
  A short (1-2 sentence) overview of what Joinmarket is and what it does.
  
  
• What is the role of investors in Joinmarket?
  
  A short (1-2 sentence) overview of the role of investors.
  
  
• What benefits can I expect as an investor?
  
  This section should be very specific and as long as it needs to be. Sure you can talk about market rates etc, but give concrete examples with reasonable rates. If I invest 100 BTC and set a rate of 0.03%, what will my profit be? At 0.1%? At 0.5%? A table listing various amounts and rates and transactions per day would work well here. You also need to talk about the volume of transactions, both currently and in the future. I know privacy is a part of the system so maybe you don't know precisely how much volume there is now but the bid/ask type messages are sent through IRC so you must have an estimate. 2 transactions a day? 20? 50? 1 BTC a day? 10? 100? And you can talk a little about the future potential to entice investors.
  
  
• What risks are there to investors?
  
  You said something about risks from bugs in the software. That and any other risks need to be detailed here in very specific form. Which software having bugs will cause a loss? Just Joinmarket's local python app or other parts of the system? How could malicious participants affect the system? And what would the loss be: all of the BTC in Bitcoin Core, or just those in the Joinmarket wallet, or full system compromise? What can investors do to mitigate the risks?
  
  
• What is the yield generator and how does it work?
  
  Explain the role of the yield generator and very specifically how it works. How is it funded? [not command lines just an overview of the process] What funds does it have access to? How and why does it communicate with Bitcoin Core? How does it communicate with other participants? What kind of "offers" does it put out to the marketplace? How does that relate to the total BTC the investor makes available? What exactly happens when an "offer" is "accepted"? [what are the actual steps involved in the coinjoin, from the perspective of the investor and their yield generator. Not technical details like pubscripts or anything, just the high level steps.] What happens when the coinjoin is done? What is the state of the wallet? Explain how the investor receives their profit. What about when the next offer is accepted? Is that different from the first one? How are coins moved through the different wallet levels? How does that affect the max amount the investor can offer? In essence an explanation of the life cycle of the yield generator through time. Also an explanation of how the investor monitors what the yield generator is doing. What offers is it making? Which did it accept? How can I see what my volume and profit have been so far? [not command lines just explain what information can be seen]
  
  
• What options can I configure for the yield generator?
  
  Talk about whatever the options are: rate, min/max amounts, transaction fees. What if I want to make multiple offers with different amounts and rates? [not command lines or names of variables just a high level explanation]
  
  
• How do I become an investor?
  
  This has two parts. First an overview of the process: requirements, an explanation of how the yield generator will communicate with Bitcoin Core, any other high level explanations. Second the steps to get it up and running. This is the first place command lines or variable names should be used. This should include step by step every action needed to become an investor. It's not ok to say "You also have to understand and follow all the steps on these two other pages" like the yield generator page does now. All the necessary steps should be right here. Obviously you don't need to explain how to install Bitcoin Core or anything super basic that any investor would know but it's better to be on the side of listing too much instead of too little. For example if Bitcoin Core needs to be set up for RPC, the steps for that should be explained. If I follow all of the steps here I should be able to go from an empty user account to being an investor in Joinmarket and (hopefully) making a profit.
  
  
• How do I monitor my activity and profits?
  
  Command lines of everything an investor needs to know to view and understand their activity over time. What offers is the yield generator making? Which did it accept? How can I see what my volume and profit have been so far? How can I see other offers in the market? How can I see what "counteroffers" takers made? How can I see which were accepted? This type of transparency is necessary not only for the investor but for the network too. How can an investor adjust their offers if they don't know what the other side has been "counteroffering" and which offers have been accepted? Also include instructions for how to update to the latest version of the software on a regular basis.
  
  

[coinchip]

On other topics

• The rates in the orderbook are really low now. Maybe this is where the market will end up but I also suspect some people are offering really low rates because they believe in Joinmarket and want to provide early-on liquidity. This is counterproductive though because it discourages investors from joining. When a prospective investor sees that there is 140 BTC at 0.03% there is no reason for them to offer 100 BTC at a higher (normal?) rate.
  
  
• In order to have a functioning marketplace there needs to be more transparency in the offers from makers and takers. This includes a list of accepted/processed offers. If it isn't possible now to tell which offers were accepted then the software should be changed to broadcast whenever it is involved in a transaction. To prevent fake reports maybe all of the participants can sign a "receipt" that verifies that the transaction took place and what the amount and rate were. If privacy is a concern the amount could be rounded off or put into a range. And if all of the participants signing creates privacy issues then only have a few randomly selected ones do the signing. Whatever the details are there needs to be some type of reporting of transactions or otherwise the market participants are just guessing at what the rates should be.
  
  
• TOR support needs to be completely built in. The target audience of takers are using Joinmarket for privacy after all.

[CohibAA]

Anybody can edit the wiki. 

I see lots of documentation improvement opportunities, and eventually I will probably help update some of it, but currently I feel like the focus needs to be on getting more takers, and improving code.  The fees are probably so low because there are not a lot of requests for orders, yet, and makers want their coins to be doing some work.  I'm personally spending my time related to JoinMarket on educating potential takers on use cases and process.

When dev is able to release an electrum plugin and other application uses that bring more takers, we can focus more on adding liquidity and maker ease-of-use, imho.

For privacy reasons, I do not agree with forcing a list of accepted/processed orders history to be kept anywhere, as this may make it easier for someone to monitor coin flow.  It a maker wants to keep and somehow publish their logs in a raw or formatted version, I don't know if that can be stopped (other than to remove logging of transaction info for makers, but that is a dangerous step at this time), but I think to include it with JoinMarket would violate it's privacy intents.  If I paid for a coinjoin action and saw that the transaction IDs, amounts, or any other specific information about my action was published from a log, I would probably not use that order maker ever again.

I agree TOR needs to be a priority, for many reasons.  If I knew of a solution, I would put in a request, but I am not knowledgeable about those protocols, unfortunately.  I know the relevant lines of coding have been pointed on on the git repo, but it's beyond my ability to fix... maybe someone reading this will have the skills and time.

[belcher]

Thank you for the very detailed post coinchip.

Eventually there will be a document like that.

This project has run away from me somewhat, become more popular more quickly than the code justifies. The project probably needs software development more than anything else right now.

[belcher]

For eager joinmarketeers, read this list for ways to contribute.

https://github.com/chris-belcher/joinmarket/wiki/What-can-I-do-for-JoinMarket%3F

[noel57]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

[CohibAA]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

You can send a deposit to your joinmarket wallet from a multi-sig, or you can send from your joinmarket wallet to a multi-sig (afaik), but there is no mechanism for using a multi-sig account for running the yield generator.  You don't need escrow, as your transactions interact and verify from bitcoin core (or a block explorer if you don't run core, but that is not recommended) at time of signing.  No trust required for sending with coinjoins or running yield generation.

[noel57]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

You can send a deposit to your joinmarket wallet from a multi-sig, or you can send from your joinmarket wallet to a multi-sig (afaik), but there is no mechanism for using a multi-sig account for running the yield generator.  You don't need escrow, as your transactions interact and verify from bitcoin core (or a block explorer if you don't run core, but that is not recommended) at time of signing.  No trust required for sending with coinjoins or running yield generation.

If I understand you clearly, you are saying it can not serve as a PGP or Multi signature wallet but it have their features and can receive transactions or deposits from them but operates differently.

[waxwing]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

Coinjoin does not require you to trust anyone when it comes to the monetary aspect; you are not putting money at risk.

It works like this: one person creates the transaction and then sends it out to everyone else, including you, let's say. Then you look at the transaction and check that it pays you the correct amount. If it doesn't,  you don't sign it. There is no possibility of a transaction happening if you didn't agree to it.

Note - this is *not* multisignature, it's intrinsic to any Bitcoin transaction. Every input to a transaction must be signed by the private key corresponding to the public key referred to in that input. In other words, Coinjoin is just how Bitcoin works, it's just that usually we don't pay attention to it because all the inputs are from the same person.

[noel57]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

Coinjoin does not require you to trust anyone when it comes to the monetary aspect; you are not putting money at risk.

It works like this: one person creates the transaction and then sends it out to everyone else, including you, let's say. Then you look at the transaction and check that it pays you the correct amount. If it doesn't,  you don't sign it. There is no possibility of a transaction happening if you didn't agree to it.

Note - this is *not* multisignature, it's intrinsic to any Bitcoin transaction. Every input to a transaction must be signed by the private key corresponding to the public key referred to in that input. In other words, Coinjoin is just how Bitcoin works, it's just that usually we don't pay attention to it because all the inputs are from the same person.

I understand it better now, that means for example if I order for a product and offer to pay the person via bitcoin I might not sign it if the person does not provide proof of shipment or DHL tracking number and if I fail to sign it the money will not be credited into the person account.

[waxwing]

This concept seems great especially the investment part of it  , can this also serve as multi signature for safe escrow dealing when transacting with people you yet to be trusted?

Coinjoin does not require you to trust anyone when it comes to the monetary aspect; you are not putting money at risk.

It works like this: one person creates the transaction and then sends it out to everyone else, including you, let's say. Then you look at the transaction and check that it pays you the correct amount. If it doesn't,  you don't sign it. There is no possibility of a transaction happening if you didn't agree to it.

Note - this is *not* multisignature, it's intrinsic to any Bitcoin transaction. Every input to a transaction must be signed by the private key corresponding to the public key referred to in that input. In other words, Coinjoin is just how Bitcoin works, it's just that usually we don't pay attention to it because all the inputs are from the same person.

I understand it better now, that means for example if I order for a product and offer to pay the person via bitcoin I might not sign it if the person does not provide proof of shipment or DHL tracking number and if I fail to sign it the money will not be credited into the person account.

Well, not *literally* - coinjoin has nothing to do with buying products for bitcoin. But as an analogy, yes, you're in a position just like that - you don't have to sign off on a transaction until you know exactly what you'll be getting back.

[inaltoasinistra]

From: https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node

You will need:

• Bitcoin Core version 0.10 or above. The import watch-only address feature is required.
• Fully downloaded and verified blockchain

Is/will be possible use a pruned blockchain?

[belcher]

From: https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node

You will need:

• Bitcoin Core version 0.10 or above. The import watch-only address feature is required.
• Fully downloaded and verified blockchain

Is/will be possible use a pruned blockchain?

Yes, although right now the wallet code is disabled for pruning so itcan't be used for JoinMarket.

[domob]

From: https://github.com/chris-belcher/joinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node

You will need:

• Bitcoin Core version 0.10 or above. The import watch-only address feature is required.
• Fully downloaded and verified blockchain

Is/will be possible use a pruned blockchain?

Yes, although right now the wallet code is disabled for pruning so itcan't be used for JoinMarket.

I should add that the current development code enables the wallet in pruned mode.  I've already tried out using such a node with JoinMarket, and it seemed to work fine.  So you can already do it if you feel risky to run the development code, or else after the next version is released.

[Adlai]

On other topics

• The rates in the orderbook are really low now. Maybe this is where the market will end up but I also suspect some people are offering really low rates because they believe in Joinmarket and want to provide early-on liquidity. This is counterproductive though because it discourages investors from joining. When a prospective investor sees that there is 140 BTC at 0.03% there is no reason for them to offer 100 BTC at a higher (normal?) rate.
  
  

Bear in mind that the advertised rates are per transaction. If you average one transaction per day at 0.03%, that's a monthly return closer to 1%. It's not yet clear what frequency individual investors can expect, but we've started working on a tool for detecting likely Joinmarket activity in the blockchain, and guessing the earned fees.

[inaltoasinistra]

On other topics

• The rates in the orderbook are really low now. Maybe this is where the market will end up but I also suspect some people are offering really low rates because they believe in Joinmarket and want to provide early-on liquidity. This is counterproductive though because it discourages investors from joining. When a prospective investor sees that there is 140 BTC at 0.03% there is no reason for them to offer 100 BTC at a higher (normal?) rate.
  
  

Bear in mind that the advertised rates are per transaction. If you average one transaction per day at 0.03%, that's a monthly return closer to 1%. It's not yet clear what frequency individual investors can expect, but we've started working on a tool for detecting likely Joinmarket activity in the blockchain, and guessing the earned fees.

After 2 days without transactions the makers lower the fees, thats it. A good integration to some client could increase the bid

[domob]

Which license is the code actually under?  I assume it is a "free" one, but it seems to be not specified (unless I miss it).  I think it would be good to have it in the README or to have a COPYING file in the repository.  Also a short header notice for the source files.

[waxwing]

On other topics

• The rates in the orderbook are really low now. Maybe this is where the market will end up but I also suspect some people are offering really low rates because they believe in Joinmarket and want to provide early-on liquidity. This is counterproductive though because it discourages investors from joining. When a prospective investor sees that there is 140 BTC at 0.03% there is no reason for them to offer 100 BTC at a higher (normal?) rate.
  
  

Bear in mind that the advertised rates are per transaction. If you average one transaction per day at 0.03%, that's a monthly return closer to 1%. It's not yet clear what frequency individual investors can expect, but we've started working on a tool for detecting likely Joinmarket activity in the blockchain, and guessing the earned fees.

After 2 days without transactions the makers lower the fees, thats it. A good integration to some client could increase the bid

I agree; after the first few weeks, it was clear that this was the dynamic. A significant steady flow of 'users' (liquidity takers) is almost certainly going to require some kind of wallet integration, and that's a big project. Meanwhile, tech savvy people try it out by setting up yieldgenerator bots and are surprised when there isn't a constant flow of free money And they reduce fees presumably out of impatience.

There are users, even today; but the number is small (and to be honest I may not have a realistic picture, since I am not constantly reducing my fees like it seems others are, so I am probably not seeing almost any of the activity. This is one of the curious things about thinking of JoinMarket as a "service" - it is difficult to see it happening (although with some effort you can get a good idea)).

What "should" the fees be? It has been discussed but I'm of the opinion it's impossible to come up with a model that isn't dominated by its assumptions, so it's probably not worth bothering with.

[domob]

On other topics

• The rates in the orderbook are really low now. Maybe this is where the market will end up but I also suspect some people are offering really low rates because they believe in Joinmarket and want to provide early-on liquidity. This is counterproductive though because it discourages investors from joining. When a prospective investor sees that there is 140 BTC at 0.03% there is no reason for them to offer 100 BTC at a higher (normal?) rate.
  
  

Bear in mind that the advertised rates are per transaction. If you average one transaction per day at 0.03%, that's a monthly return closer to 1%. It's not yet clear what frequency individual investors can expect, but we've started working on a tool for detecting likely Joinmarket activity in the blockchain, and guessing the earned fees.

After 2 days without transactions the makers lower the fees, thats it. A good integration to some client could increase the bid

I agree; after the first few weeks, it was clear that this was the dynamic. A significant steady flow of 'users' (liquidity takers) is almost certainly going to require some kind of wallet integration, and that's a big project. Meanwhile, tech savvy people try it out by setting up yieldgenerator bots and are surprised when there isn't a constant flow of free money And they reduce fees presumably out of impatience.

There are users, even today; but the number is small (and to be honest I may not have a realistic picture, since I am not constantly reducing my fees like it seems others are, so I am probably not seeing almost any of the activity. This is one of the curious things about thinking of JoinMarket as a "service" - it is difficult to see it happening (although with some effort you can get a good idea)).

What "should" the fees be? It has been discussed but I'm of the opinion it's impossible to come up with a model that isn't dominated by its assumptions, so it's probably not worth bothering with.

I think almost zero fees are unavoidable.  Since this project is, by definition, a market, there will be competition.  And since the cost involved for makers is not very high (a little risk for putting your coins on a server, but not too much since you don't have to trust anyone), I believe that the eventual fee you can earn as investor is tiny.  (Even an inflow of more takers when the project is more mature won't help here, since there will also be an inflow of makers.)  But I don't think this is a problem.  It will help make coinjoins more used in the ecosystem, which is a good thing.  And if too small fees turn out to be a problem (i. e., not enough makers willing to provide liquidity), the fees will increase themselves due to market pressure until an equilibrium is reached again.

[waxwing]

I believe that the eventual fee you can earn as investor is tiny.  (Even an inflow of more takers when the project is more mature won't help here, since there will also be an inflow of makers.) 

This is exactly what we hypothesized at the initiation of the project - tiny, close to zero fees. But in a way that dodges the question - how tiny is tiny?

It's a market, so it's not as if we're trying to "fix" the price. But we're all curious where it will settle. My statement above was that I don't think any economic modelling is worthwhile for now, the unknowns are too big.

[LDA]

I found it by accident and it's super cool. I would be thankful if you could answer a few questions.

1) I saw a chart with name of wallets of investors and values. Where is it available?

2) Is there a way to see how many coins are happening per day or hour and average value?

3) The script generates a "HD wallet". However on the commands there is no output. What is the output? How many address it generate? For both send and receive or they should be exclusive?

4) Really idiot question, but I see the transactions are with internal wallet, what is the benefit? I mean, internal transactions are not public, right?

5) If we could recover the whole wallet and money with the key, it means that my coins are not with me, instead they are on a third-party server, right? What means if someone hack this system? I mean, what security do we have?

6) In practice, have someone tried to track the coins joined? How hard was it? Was possible?

Thanks.

[belcher]

I found it by accident and it's super cool. I would be thankful if you could answer a few questions.

1) I saw a chart with name of wallets of investors and values. Where is it available?

2) Is there a way to see how many coins are happening per day or hour and average value?

3) The script generates a "HD wallet". However on the commands there is no output. What is the output? How many address it generate? For both send and receive or they should be exclusive?

4) Really idiot question, but I see the transactions are with internal wallet, what is the benefit? I mean, internal transactions are not public, right?

5) If we could recover the whole wallet and money with the key, it means that my coins are not with me, instead they are on a third-party server, right? What means if someone hack this system? I mean, what security do we have?

6) In practice, have someone tried to track the coins joined? How hard was it? Was possible?

Thanks.

1) It can be seen by ob-watcher.py script, the same thing can be seen on pages run by volunteers. e.g. http://joinmarket.io/

2) Not right now, this will probably be written in the future. See https://github.com/chris-belcher/joinmarket/issues/19

3) Read this https://github.com/chris-belcher/joinmarket/wiki/Using-the-JoinMarket-internal-wallet

4)
I think you're talking about tumbler.py
Those are coinjoin transactions back to your internal wallet. They increase the anonymity set.

5) No they are not on a third party server. Your security is your ability to keep your seed secret and computer free from malware.

6) The CoinJoin transactions used by JoinMarket would make that difficult.

7) Is there a way to sign message with JoinMarket?

No, that's not what its for.

8) What about the spv mining fork?

If you use JoinMarket with Bitcoin Core you are not vulnerable, because it only works with 0.10 or above which will follow the correct fork if it happens.
If you don't use Bitcoin Core then JoinMarket will use blockr.io and you'll have to ask them if they run 0.10 nodes or above as recommended.

[LDA]

Hi belcher,

Thanks for answer and congrats for nice project.

1) Weird, my ob-watcher.py crash under python. Is the reason that my wallet is without any BTC?

Very cool this site, good to have an idea, I would love to see more people adopting it.

2) If someone is allowed to search blockchain and find tx id of transactions with JoinMarket he/she could follow all transactions and break the anonymity, not?

3) As you see I'm new on this. I looked at your example:

$ python wallet-tool.py wallet.json
Enter wallet decryption passphrase:
[2015/04/23 02:04:13] downloading wallet history
[2015/04/23 02:04:26] blockr sync_unspent took 2.70895719528sec
mixing depth 0 m/0/0/
 receive addresses m/0/0/0/
  m/0/0/0/000 1JPFmg1RSa2gtzcsow9fBjwdvWPsxcP3eX  new 0.00000000 btc
  m/0/0/0/001 1AaCpeMit59ExfSvP3M3bTnMkhXgecSPeY  new 0.00000000 btc
  m/0/0/0/002 1NmDrVbtk6kfAYbBVo7Miv8eCYHHefZkjs  new 0.00000000 btc
  m/0/0/0/003 1NKitLXm7FdgbHuENvFXRCxVH32N5XXMQ5  new 0.00000000 btc
  m/0/0/0/004 1EwkvF8SrHLh17LKCNQ9w4u4HY2akuzhx3  new 0.00000000 btc
  m/0/0/0/005 1HkHyB8DbZBNvZYwyAutgedaBSsrNUDt7G  new 0.00000000 btc
 change addresses m/0/0/1/
for mixdepth=0 balance=0.00000000btc
mixing depth 1 m/0/1/
 receive addresses m/0/1/0/
  m/0/1/0/000 1LQw8K7V2KQePFVscLKiiH1NU2v6KzwdhW  new 0.00000000 btc
  m/0/1/0/001 1EcZ7w1EEb1UK1qWYT6FMLsbRoizFCfAZ7  new 0.00000000 btc
  m/0/1/0/002 1CV7L2b23sEYNhnu35MP9gbzPAD3j3ofgc  new 0.00000000 btc
  m/0/1/0/003 1DMYRugQNJZRQPcAPAYBcE1p9u15VFTkD9  new 0.00000000 btc
  m/0/1/0/004 1CCnPgGhecXmFz8DrB3Wew9kHT1En53Lq   new 0.00000000 btc
  m/0/1/0/005 1LuwwyEv86BV4miaKVScsFxE4rrKngVt8F  new 0.00000000 btc
 change addresses m/0/1/1/
for mixdepth=1 balance=0.00000000btc
$

My output is a bit different, I have mixing depth 1 to 4 and each has 5 address if I remember well. Is mine wrong?

My understanding is that I should use each of these addresses for both send and receive BTC, right? So, why so many addresses? Use as random as possible increase my anonymity?

Recover a wallet from a bitcoin is a feature that exist on all BTC wallet programs? I'm asking because it's strange to me, if BTC is not centralized and there is no server, suppose that I delete my wallet.json, how can I recover everything again from the 12 words seed? And how do they know that my password mismatch (it should not be stored just locally on my computer)?

4) You are correct. Sorry for dumb question, but what is difference of a internal and real wallet? A wallet is composed of several addresses, right? And an internal wallet? Exist transactions for internal wallets?

5) Got it, thanks. This is the point that I don't understand, to be hones it's the reason of my question of how anyone could recover my wallet with 12 seed words since all is decentralized.

6) Please, don't take me wrong, but difficult is relative. For example, you master the process and understand a lot of BTC. If you are determined, are you able to track someone transactions?

7) I understand. So can I (or should I) use JoinMarket with an wallet software such as Electrum? On my mind it was supposed to be a wallet too. If I need to use both, how do I know when use each?

When I send money to someone via JoinMarket does it display the TX id on the command output?

8 ) Understood. I assume that Bitcoin core is the default, correct? However, if I remember well there is a part of the software that says that use one of them affect privacy / anonymity, right?

On the worst case, suppose that someone was using blockr.io and they are not running 0.10, what happens? Can this person loose his money? Or it will just take more time?

Again, thanks so much and sorry for too much big and dumb questions. I hope they could help other users.

[belcher]

Hi belcher,

Thanks for answer and congrats for nice project.

1) Weird, my ob-watcher.py crash under python. Is the reason that my wallet is without any BTC?

Very cool this site, good to have an idea, I would love to see more people adopting it.

2) If someone is allowed to search blockchain and find tx id of transactions with JoinMarket he/she could follow all transactions and break the anonymity, not?

3) As you see I'm new on this. I looked at your example:

$ python wallet-tool.py wallet.json
Enter wallet decryption passphrase:
[2015/04/23 02:04:13] downloading wallet history
[2015/04/23 02:04:26] blockr sync_unspent took 2.70895719528sec
mixing depth 0 m/0/0/
 receive addresses m/0/0/0/
  m/0/0/0/000 1JPFmg1RSa2gtzcsow9fBjwdvWPsxcP3eX  new 0.00000000 btc
  m/0/0/0/001 1AaCpeMit59ExfSvP3M3bTnMkhXgecSPeY  new 0.00000000 btc
  m/0/0/0/002 1NmDrVbtk6kfAYbBVo7Miv8eCYHHefZkjs  new 0.00000000 btc
  m/0/0/0/003 1NKitLXm7FdgbHuENvFXRCxVH32N5XXMQ5  new 0.00000000 btc
  m/0/0/0/004 1EwkvF8SrHLh17LKCNQ9w4u4HY2akuzhx3  new 0.00000000 btc
  m/0/0/0/005 1HkHyB8DbZBNvZYwyAutgedaBSsrNUDt7G  new 0.00000000 btc
 change addresses m/0/0/1/
for mixdepth=0 balance=0.00000000btc
mixing depth 1 m/0/1/
 receive addresses m/0/1/0/
  m/0/1/0/000 1LQw8K7V2KQePFVscLKiiH1NU2v6KzwdhW  new 0.00000000 btc
  m/0/1/0/001 1EcZ7w1EEb1UK1qWYT6FMLsbRoizFCfAZ7  new 0.00000000 btc
  m/0/1/0/002 1CV7L2b23sEYNhnu35MP9gbzPAD3j3ofgc  new 0.00000000 btc
  m/0/1/0/003 1DMYRugQNJZRQPcAPAYBcE1p9u15VFTkD9  new 0.00000000 btc
  m/0/1/0/004 1CCnPgGhecXmFz8DrB3Wew9kHT1En53Lq   new 0.00000000 btc
  m/0/1/0/005 1LuwwyEv86BV4miaKVScsFxE4rrKngVt8F  new 0.00000000 btc
 change addresses m/0/1/1/
for mixdepth=1 balance=0.00000000btc
$

My output is a bit different, I have mixing depth 1 to 4 and each has 5 address if I remember well. Is mine wrong?

My understanding is that I should use each of these addresses for both send and receive BTC, right? So, why so many addresses? Use as random as possible increase my anonymity?

Recover a wallet from a bitcoin is a feature that exist on all BTC wallet programs? I'm asking because it's strange to me, if BTC is not centralized and there is no server, suppose that I delete my wallet.json, how can I recover everything again from the 12 words seed? And how do they know that my password mismatch (it should not be stored just locally on my computer)?

4) You are correct. Sorry for dumb question, but what is difference of a internal and real wallet? A wallet is composed of several addresses, right? And an internal wallet? Exist transactions for internal wallets?

5) Got it, thanks. This is the point that I don't understand, to be hones it's the reason of my question of how anyone could recover my wallet with 12 seed words since all is decentralized.

6) Please, don't take me wrong, but difficult is relative. For example, you master the process and understand a lot of BTC. If you are determined, are you able to track someone transactions?

7) I understand. So can I (or should I) use JoinMarket with an wallet software such as Electrum? On my mind it was supposed to be a wallet too. If I need to use both, how do I know when use each?

When I send money to someone via JoinMarket does it display the TX id on the command output?

8 ) Understood. I assume that Bitcoin core is the default, correct? However, if I remember well there is a part of the software that says that use one of them affect privacy / anonymity, right?

On the worst case, suppose that someone was using blockr.io and they are not running 0.10, what happens? Can this person loose his money? Or it will just take more time?

Again, thanks so much and sorry for too much big and dumb questions. I hope they could help other users.

1) No, ob-watcher.py does not require you to have btc in your wallet. In fact it doesnt even require a wallet at all.

2) No, CoinJoins discard unnecessary information which is what improves the privacy. Read this: https://en.bitcoin.it/wiki/CoinJoin

3)

My output is a bit different, I have mixing depth 1 to 4 and each has 5 address if I remember well. Is mine wrong?

No, thats right.

My understanding is that I should use each of these addresses for both send and receive BTC, right? So, why so many addresses? Use as random as possible increase my anonymity?

Read this to understand why there are different so-called "mixing levels" https://github.com/chris-belcher/joinmarket/wiki/Using-the-JoinMarket-internal-wallet#structure

By default the script outputs 5 addresses, although it can output more. It means you could receive 5 different payments at once. Alternatively you could give several addresses to a single person so that your payment cant be tracked by correlating amounts.

Recover a wallet from a bitcoin is a feature that exist on all BTC wallet programs? I'm asking because it's strange to me, if BTC is not centralized and there is no server, suppose that I delete my wallet.json, how can I recover everything again from the 12 words seed? And how do they know that my password mismatch (it should not be stored just locally on my computer)?

Yes, recovery from mnemonic seed exists in most wallets.
In practice you recover it with the instructions here https://github.com/chris-belcher/joinmarket/wiki/Using-the-JoinMarket-internal-wallet#recover
The password is only used for encrypting the wallet file on your hard disk. You don't need it to recover (this also implies somebody with only your seed can steal your coins)

4) A JoinMarket internal wallet is a kind of real wallet. There is no such thing as fake wallets.

5) It does not rely on a central server, the conversion from mnemonic seed to addresses is a mathematical algorithm. To massively simplify, each word is converted into a number and all the numbers are put together to give a master seed. From that you can generated an unlimited number of private key/address pairs that are always the same if you used the same master seed.

6) Mastery and understanding of bitcoin is not enough to deanonymize JoinMarket transactions. Privacy in bitcoin is a complex topic which I won't go into here, try reading this article to understand more why CoinJoin transactions used by JoinMarket improve privacy https://en.bitcoin.it/wiki/CoinJoin

7) JoinMarket is not really meant to be a bitcoin wallet used for receiving and spending like Electrum, Bitcoin Core or Armory. It can be used that way and many people do but it's not optimized for easy usage. In the future there should be an Electrum plugin and Bitcoin Core script which allows you to create private JoinMarket transactions from the GUI of those wallets.

When I send money to someone via JoinMarket does it display the TX id on the command output?

Yes it does.

8) If someone uses blockr.io then that website will know their IP address as well as which addresses belong to them. Obviously this is harmful to privacy, especially as blockr.io is owned by the coinbase.com company which is legally required to collect financial information.

[Cryptoman]

I'm having a little trouble getting joinmarket working with bitcoind (to be honest, I haven't tried it yet with blockr.io).  Here's a dump of what happens:

Code:

$ python wallet-tool.py wallet.json
Enter wallet decryption passphrase:
[2015/07/13 13:35:20] requesting wallet history
[2015/07/13 13:35:34] rpc: ['~/bitcoin-cli', '-datadir=~/.bitcoin', 'getaddressesbyaccount', 'joinmarket-wallet-85993a']
Traceback (most recent call last):
  File "wallet-tool.py", line 54, in <module>
    common.bc_interface.sync_wallet(wallet)
  File "/home/cryptoman/joinmarket/lib/blockchaininterface.py", line 31, in sync_wallet
    self.sync_addresses(wallet)
  File "/home/cryptoman/joinmarket/lib/blockchaininterface.py", line 388, in sync_addresses
    imported_addr_list = json.loads(self.rpc(['getaddressesbyaccount', wallet_name]))
  File "/home/cryptoman/joinmarket/lib/blockchaininterface.py", line 365, in rpc
    res = subprocess.check_output(self.command_params + args)
  File "/usr/lib/python2.7/subprocess.py", line 566, in check_output
    process = Popen(stdout=PIPE, *popenargs, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
$

What file is it looking for?  It's obviously finding and decrypting the wallet file OK.  I tried creating an account with the name "joinmarket-wallet-85993a" in bitcoind, but that didn't help.  RPC is set up properly as far as I can tell.

Thanks.

EDIT: Found the problem.  It didn't like the "~/" path.  Used the full path "/home/cryptoman/" and it worked fine.

[Cryptoman]

How long should it take to send a payment? I tried sending a payment of about 1 BTC, and it just sat there for an hour.  Nothing changed in the wallet; all amounts at m/0/0/0/ are unchanged. I did get one interesting message shortly after initiating the payment: nonrespondants = [u'SiegeOfJa'].  Did it hang because one of the participants dropped out?

[CohibAA]

Did it hang because one of the participants dropped out?

Exactly.  Their bot may have hung, or their bitcoind hung if they are using rpc, but it means the transaction won't be happening.  You can use the -P option with sendpayment.py to pick your maker, allowing you to avoid non-responding makers.

[windpath]

Great project!

Got JoinMarket up and running last night using bitcoin 0.11.0 on ubuntu 14.04, couple snags with dependencies (libsodium needs to be manually installed) but other then that it went smoothly.

Ran the Tumbler with defaults, total fees ended up at BTC0.00196169 or ~$0.54 to tumble 1BTC, not to shabby.

Ran a taint analysis on the final addresses I provided, 1 was totally severed from the original sending address, 2 had some minor taint, but nothing that jumped out.

There was still a connection to the innitial JoinMarket wallet deposit address on all of them.

I ran with the defaults:

Code:

python tumbler.py wallet.json [btc_address]

Id like to run another test and try to sever both the original sending address, and the JoinMarket wallet deposit address completely, found this in the source:

Code:

#a couple of modes
#im-running-from-the-nsa, takes about 80 hours, costs a lot
#python tumbler.py -a 10 -N 10 5 -c 10 5 -l 50 -M 10 seed 1xxx
#
#quick and cheap, takes about 90 minutes
#python tumbler.py -N 2 1 -c 3 0.001 -l 10 -M 3 -a 1 seed 1xxx
#
#default, good enough for most, takes about 5 hours
#python tumbler.py seed 1xxx
#
#for quick testing
#python tumbler.py -N 2 1 -c 3 0.001 -l 0.1 -M 3 -a 0 seed 1xxx 1yyy

What is "seed"?

I was thinking of trying:

Code:

python tumbler.py -a 4 -N 5 3 -C 5 -M 5 wallet.json [btc_address]

Thoughts?

Also would be awesome to be able to provide all the addresses on the command line at once. Edit: looks like you can, I just provided to many on first run.

Again great and important project, excited to follow and contribute if I can...

[Adlai]

What is "seed"?

Judging by your previous snippet, you'll want to put wallet.json as the "seed". The name is a leftover from the testnet days when you could directly give a wallet seed on the command line, which doesn't work on mainnet anymore.

[belcher]

Great project!

Got JoinMarket up and running last night using bitcoin 0.11.0 on ubuntu 14.04, couple snags with dependencies (libsodium needs to be manually installed) but other then that it went smoothly.

Ran the Tumbler with defaults, total fees ended up at BTC0.00196169 or ~$0.54 to tumble 1BTC, not to shabby.

Ran a taint analysis on the final addresses I provided, 1 was totally severed from the original sending address, 2 had some minor taint, but nothing that jumped out.

There was still a connection to the innitial JoinMarket wallet deposit address on all of them.

I ran with the defaults:

Code:

python tumbler.py wallet.json [btc_address]

Sounds good. Glad it worked.

Id like to run another test and try to sever both the original sending address, and the JoinMarket wallet deposit address completely, found this in the source:

Code:

#a couple of modes
#im-running-from-the-nsa, takes about 80 hours, costs a lot
#python tumbler.py -a 10 -N 10 5 -c 10 5 -l 50 -M 10 seed 1xxx
#
#quick and cheap, takes about 90 minutes
#python tumbler.py -N 2 1 -c 3 0.001 -l 10 -M 3 -a 1 seed 1xxx
#
#default, good enough for most, takes about 5 hours
#python tumbler.py seed 1xxx
#
#for quick testing
#python tumbler.py -N 2 1 -c 3 0.001 -l 0.1 -M 3 -a 0 seed 1xxx 1yyy

What is "seed"?[

Those comments are possibly out of date.

Seed is a kind of brainwallet that was used before wallet files were made. They don't work anymore for mainnet.

I was thinking of trying:

Code:

python tumbler.py -a 4 -N 5 3 -C 5 -M 5 [btc_address]

Thoughts?

Also would be awesome to be able to provide all the addresses on the command line at once. Edit: looks like you can, I just provided to many on first run.

Again great and important project, excited to follow and contribute if I can...

It will probably work. It's likely that tumbling with coinjoin works but nobody really knows.
I assume you've run

Code:

python tumbler.py --help

so you know what the options mean

For contributions, this page has some useful small projects
https://github.com/chris-belcher/joinmarket/wiki/What-can-I-do-for-JoinMarket%3F

There is also a donation address found on the readme of the github
https://github.com/chris-belcher/joinmarket

[mktx]

I think this project is amazing as well, and I really enjoy using it as my preferred method for coinjoin txs. However I do have one complaint. The other day I was using the sendpayment.py script. The command was exactly:

Code:

python sendpayment.py -C -N 4 <wallet> 0 <address>

The script put the transaction together, and presented me with the options and a "y/n" prompt. I pressed "y" without paying too much attention and ended up paying some asshole 2.8 BTC to send a little over 5. Which is more than half of the bitcoin controlled by my privkeys.

A couple suggestions:

1. Kick those people from the IRC with 50%+ fees.

2. Present the cjfee in something other than satoshis or have an alert that says you're about to pay an insane amount.

[marcus_of_augustus]

I think this project is amazing as well, and I really enjoy using it as my preferred method for coinjoin txs. However I do have one complaint. The other day I was using the sendpayment.py script. The command was exactly:

Code:

python sendpayment.py -C -N 4 <wallet> 0 <address>

The script put the transaction together, and presented me with the options and a "y/n" prompt. I pressed "y" without paying too much attention and ended up paying some asshole 2.8 BTC to send a little over 5. Which is more than half of the bitcoin controlled by my privkeys.

A couple suggestions:

1. Kick those people from the IRC with 50%+ fees.

2. Present the cjfee in something other than satoshis or have an alert that says you're about to pay an insane amount.

Ouch, that sounds like you got the rawhide treatment.

[belcher]

I think this project is amazing as well, and I really enjoy using it as my preferred method for coinjoin txs. However I do have one complaint. The other day I was using the sendpayment.py script. The command was exactly:

Code:

python sendpayment.py -C -N 4 <wallet> 0 <address>

The script put the transaction together, and presented me with the options and a "y/n" prompt. I pressed "y" without paying too much attention and ended up paying some asshole 2.8 BTC to send a little over 5. Which is more than half of the bitcoin controlled by my privkeys.

A couple suggestions:

1. Kick those people from the IRC with 50%+ fees.

2. Present the cjfee in something other than satoshis or have an alert that says you're about to pay an insane amount.

Thanks for the feedback. Sorry for you loss.

I made this commit https://github.com/chris-belcher/joinmarket/commit/be8b63fa332d18a4ba71d68e3894d29d4c9db7c8
It displays the coinjoin fee as a percentage and prints out a huge warning banner if its above 2%

Code:

[2015/07/20 02:45:10] total coinjoin fee = 2.1%
============================================================
============================================================
============================================================
WARNING   WARNING   WARNING   WARNING   WARNING   WARNING  
============================================================
OFFERED FEE IS INSANELY LARGE.OFFERED FEE IS INSANELY LARGE.
============================================================
WARNING   WARNING   WARNING   WARNING   WARNING   WARNING  
============================================================
============================================================
============================================================
send with these orders? (y/n):

[Sukrim]

2% is not "insane"...

[ThePiGuy]

2% is not "insane"...

In the current system, it kind of is.  The average is significantly lower, and as such is pretty crazy compared to best options.

[btcspry]

I'm a little curious as to how the program picks the person to do the CoinJoin with.  Shouldn't it be the percent with the lowest percentage that can handle the join?  Or am I missing something?  It seems like these 2.8 BTC mistakes shouldn't happen.

[inaltoasinistra]

I'm a little curious as to how the program picks the person to do the CoinJoin with.  Shouldn't it be the percent with the lowest percentage that can handle the join?  Or am I missing something?  It seems like these 2.8 BTC mistakes shouldn't happen.

The order book is not so big now, so a cj tx with 10 parties and 5btc could consume all the order book and reach the 200% fee.

[belcher]

2% is not "insane"...

It's two orders of magnitude above most of the market right now.

The highest obviously-not-in-bad-faith offer is 0.5% per transaction and that guy offers up to 124.01382647 BTC(!)

There's an open issue to display fees in basis points and parts-per-million because the percent unit is too large.

[Sukrim]

The market is still tiny and while early adopters might be happy to offer their coin for nearly free for mixing, this might not be the case in the future. A 2% fee for achieving anonymity is still quite low, adding built in magic default values is not a very sustainable or helpful thing if you want to establish a free market.

Maybe display fee in relative and absolute values, optionally also with fiat prices?

Anyways, please put this warning value in a configuration file and maybe write your 2% as a default in there... but don't hide this deep in the code.

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

[justusranvier]

The market is still tiny and while early adopters might be happy to offer their coin for nearly free for mixing, this might not be the case in the future. A 2% fee for achieving anonymity is still quite low, adding built in magic default values is not a very sustainable or helpful thing if you want to establish a free market.

Maybe display fee in relative and absolute values, optionally also with fiat prices?

Anyways, please put this warning value in a configuration file and maybe write your 2% as a default in there... but don't hide this deep in the code.

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

Two standard deviations above the average is probably a better sanity check

[btcspry]

Someone seriously needs to make stats on volume and estimated amounts earned.

[dserrano5]

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

My fee is around 0.01% and I'm involved in some 3 or 4 joins a week. FWIW.

[Sukrim]

Two standard deviations above the average is probably a better sanity check

I agree, something that is a bit more dynamic towards current market situations would be better.

Oh, and:

2% is not "insane"...

It's two orders of magnitude above most of the market right now.

No, it is not - only if you count individual offers (which could easily be a sybil/collusion attack by a single actor operating several instances with a few BTC each).

By the way, how high is traffic and volume actually? If I offer coins at relatively competitive rates, how often do these actually get taken? Daily? Once per hour? Are there historic stats to analyze?

My fee is around 0.01% and I'm involved in some 3 or 4 joins a week. FWIW.

Ok, so definitely not worth the risk then.

To earn just one single USD per day(!) you'd need to keep about 7 BTC at that rate on a hot wallet while announcing your IP to an IRC server.

Also I am wondering if it is a better strategy to put up several instances with similar configuration and effectively sybil attack the market, hoping you get more volume from people that try to "fan out" to get more counterparties involved or to pool all your funds in one large account, hoping for a "big fish" that wants to launder a lot of money at once.

[belcher]

This message is merely a warning to make people more aware of what they're getting into. Clear information is good for market outcomes. People can still go ahead with the deal by typing 'y' same as before. Though maybe the wording should be changed, removing prescriptive words like "insane".

In the event that prices rise above 2% and many people get bored by constantly reading the same warning, the threshold can be easily changed.

Remember that ultimately the point of JoinMarket isn't to give free money to market makers but to provide privacy at a cheap price.
If we look at the interests of coinjoiners not accidentally paying too much vs investors being faced with a warning for high fees, the interests of the customers wanting privacy should come first.

There was already a shill trying to use this incident to ruin the reputation of JoinMarket on reddit with an editorialized headline, which I reposted sans headline. Opposing that warning won't you more money, it's likely to make you less in the long run.

By the way, almost any investment can look bad if you work out the per-day return. Find the per-annum income and compare, and think about the low risk you take, how little time and effort it takes to run and the fact you're getting paid in a deflationary currency. If you want to raise your earnings the best way is to have more takers as customers. Either contribute to the code or promote the use of JoinMarket to bitcoin users who might be interested.

Someone seriously needs to make stats on volume and estimated amounts earned.

Be the change you wish to see in the world!
https://github.com/adlai/cjhunt
https://github.com/chris-belcher/joinmarket/issues/19

To earn just one single USD per day(!) you'd need to keep about 7 BTC at that rate on a hot wallet while announcing your IP to an IRC server.

Also I am wondering if it is a better strategy to put up several instances with similar configuration and effectively sybil attack the market, hoping you get more volume from people that try to "fan out" to get more counterparties involved or to pool all your funds in one large account, hoping for a "big fish" that wants to launder a lot of money at once.

The IRC server accepts tor.

Higher amounts of bitcoin in one offer command a higher fee (like the high 0.5% fee for the guy who has 124btc) so there is a strong incentive to keep your coins on one bot rather than fanning out.

[belcher]

Edited message phrasing

https://github.com/chris-belcher/joinmarket/commit/00eb9cab006897b3f34a5f858600fdc1a0b548d8


sendpayment.py can still be dangerous if people use --yes which skips the yes/no question.
There needs to be an option for a maximum total coinjoin fee, which will have a default value. Such a flag already exists in tumbler.py

BTW, gmaxwell also chose a fixed fee when fixing the equivalent problem for bitcoin raw transactions.

Code:

commit 9d14e689c86a395c11a530767db4ddf895446ba8
Author: Gregory Maxwell <greg@xiph.org>
Date:   Wed Aug 28 15:41:46 2013 -0700

[raw] reject insanely high fees by default in sendrawtransaction

There have been several incidents where mainnet experimentation with
raw transactions  resulted in insane fees.  This is hard to prevent
in the raw transaction api because the inputs may not be known.
Since sending doesn't work if the inputs aren't known, we can catch
it there.

This rejects fees > than 10000 * nMinRelayTxFee or 1 BTC with the
defaults and can be overridden with a bool at the rpc.

[Blawpaw]

I guess the ecosystem demands this kind of developments but wonder if this will still work against the new Elliptic tracking software!
This is becoming like the old mouse and cat game... While some companies develop new and improved privacy software, others will keep on cracking it!

We need projects like your to be running!
Good Luck for your project!

[domob]

Just brainstorming a bit.  Let us assume that I'm getting paid in Bitcoin by someone I know (and who knows me).  I would like to spend the bitcoins on something this person should not know about.  Such situations can arise a lot; I could be a government worker for some regime spending the money on "foreign" news sites; it could be a friend or relative splitting a restaurant bill and me buying porn; it could be a face-to-face purchase of bitcoins and me not wanting the seller to find out my net worth via blockchain analysis; and so on.

Furthermore, note that it seems fairly easy to make a good guess about whether or not a particular tx is a JoinMarket coinjoin or not.  (Look for multiple outputs of the exact same size for a start, although such transactions can be "faked" easily, of course.  You could also try to keep track of outputs offered by market makers semi-publicly.)

Couldn't the adversary now follow all outputs from all JoinMarket coinjoins starting with the coin they sent me initially, and try to find the one that first stops to take part in JoinMarket transactions?  Assume that I do a few joins with the coins before spending them, possibly including splitting to various outputs and so on (as the tumbler does).  The market makers, however, will probably continue to do more and more joins with their coins (as that's simply what they do).  It seems plausible that this quite simple strategy could, indeed, be efficient in linking inputs and outputs together even through a series of joins.

What do you think?

[belcher]

Just brainstorming a bit.  Let us assume that I'm getting paid in Bitcoin by someone I know (and who knows me).  I would like to spend the bitcoins on something this person should not know about.  Such situations can arise a lot; I could be a government worker for some regime spending the money on "foreign" news sites; it could be a friend or relative splitting a restaurant bill and me buying porn; it could be a face-to-face purchase of bitcoins and me not wanting the seller to find out my net worth via blockchain analysis; and so on.

Furthermore, note that it seems fairly easy to make a good guess about whether or not a particular tx is a JoinMarket coinjoin or not.  (Look for multiple outputs of the exact same size for a start, although such transactions can be "faked" easily, of course.  You could also try to keep track of outputs offered by market makers semi-publicly.)

Couldn't the adversary now follow all outputs from all JoinMarket coinjoins starting with the coin they sent me initially, and try to find the one that first stops to take part in JoinMarket transactions?  Assume that I do a few joins with the coins before spending them, possibly including splitting to various outputs and so on (as the tumbler does).  The market makers, however, will probably continue to do more and more joins with their coins (as that's simply what they do).  It seems plausible that this quite simple strategy could, indeed, be efficient in linking inputs and outputs together even through a series of joins.

What do you think?

Yes probably.

Privacy would be improved if the person you're trading with also uses CoinJoin, so then the transaction graph will continue with coinjoins after your transaction.

Privacy has the element of hiding among the crowd. The more people use JoinMarket the better. I'm hoping the incentives will work out to make this happen. Yield generators have an incentive to tell everyone about JoinMarket so their own income will rise.

[btc4ever]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

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.

[Adlai]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

To use git terminology, the plumbing exists, but you've either got to get out a pipe wrench or wait for porcelain to arrive.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

Code:

python tumbler.py --help

[CohibAA]

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

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.

I may not be fully understanding your suggestion, but I believe the tumbler.py already does something like this.  Here is the (current) info from the help file, as pointed out by Adlai:

Usage: tumbler.py [options] [wallet file] [destaddr(s)...]

Sends bitcoins to many different addresses using coinjoin in an attempt to
break the link between them. Sending to multiple  addresses is highly
recommended for privacy. This tumbler can be configured to ask for more
address mid-run, giving the user a chance to click `Generate New Deposit
Address` on whatever service they are using.

I didn't post all the parameters the help covers, but multiple receive addresses, and random timing of transactions are some of the options available.

[CohibAA]

Has everyone updated for BIP66?

JoinMarket Alert Message: Please update from the latest github to fix the bip66 bug

What, if any, repurcussions would takers and makers see if trying to create a coinjoin with someone that has not yet upgraded?  More frequent signature errors?

[belcher]

Has everyone updated for BIP66?

JoinMarket Alert Message: Please update from the latest github to fix the bip66 bug

What, if any, repurcussions would takers and makers see if trying to create a coinjoin with someone that has not yet upgraded?  More frequent signature errors?

Yep, just more frequent signature errors. Then the transaction fails to broadcast.
Nobody loses any money, at worst they fail to gain money.
That was the situation we had up until now and there were not even that many bug reports about it. I'm guessing most people used sendpayment.py and just tried it again then it would work.

It would be a mild inconvenience to people using sendpayment.py but would stall a tumbler.py process. Also anyone who doesn't understand the details of the error message might be very put off, especially if they're using some eventual GUI like an Electrum plugin or Bitcoin Core integration.

[tailsjoin]

Hidden service orderbook viewer: http://ruc47yiosooolrzw.onion:62601/

[superresistant]

 
This project is really interesting but without a light and very simple wallet it is hard to imagine a lot of transactions going on.

With a lot of transactions, whales would come.

Idiot-proof softwares are the ones that work the best.

[spartacusrex]

JoinMarket - love it.

If the joinmarket buy/sell data is completely public, is it not possible by looking at the txn's, which inputs came from the market ? And by reduction what the original inputs are ?

If you wanted to implement this 'on-chain' somehow, for instance.

[CohibAA]

JoinMarket - love it.

If the joinmarket buy/sell data is completely public, is it not possible by looking at the txn's, which inputs came from the market ? And by reduction what the original inputs are ?

If you wanted to implement this 'on-chain' somehow, for instance.

Every JoinMarket transaction is done on the blockchain.  The project is live and working, but needs quite a bit more development for widespread adoption and use.  Sorry if you already knew this.

Some work has been done to create tools to hunt coinjoins on the blockchain (issue 19).  edit: Also this one

When a transaction is created from JoinMarket, the utxo sources are only known to the taker (sender).  It is currently assumed that takers will want to maintain their privacy and won't share that information.  Something, something, assumptions... The idea of someone creating "fake" coinjoins to farm information about market maker utxos is discussed in issue 156 a bit, and maybe elsewhere on the repo.

I believe there are some posts in this thread about how the tumbler.py script affects taint analysis as well.

[CohibAA]

 

Alert: Someone sent coins to, and has been using, a null bip32 seed wallet. I have swept 1.59 btc.

Issue #190

edit: resolved

[waxwing]

When a transaction is created from JoinMarket, the utxo sources are only known to the taker (sender).  It is currently assumed that takers will want to maintain their privacy and won't share that information.  Something, something, assumptions...

There are assumptions, but I think that doesn't state it very well.

The taker pays for the service, and gets the assurance that *as long as not all the makers are colluding together*, then no one else knows the mapping of his outputs. The "as long as not all the makers are colluding" is the assumption. There is no assumption that, as a yield generator, you get the privacy feature that no one apart from you knows your output; the taker *definitely* knows. So your position acting as a maker/yield generator is that you offer a service and get paid; if you also get extra privacy (which in practice you certainly do), that's extra. But not assumed.

The idea of someone creating "fake" coinjoins to farm information about market maker utxos is discussed in issue 156 a bit, and maybe elsewhere on the repo.

Yes, true, it's at least related if not exactly the same thing. What we want to avoid is to break the fundamental promise - that as a taker, someone else (any anonymous IRC bot, or any individual maker) is not able to identify your outputs just by "pinging" the makers and finding their utxos. That's (at least to my mind) what the #156 discussion is about.

[CohibAA]

There are assumptions, but I think that doesn't state it very well.
...

Fair enough.  Not the same thing, but certainly related, I believe.

I think #156 could be a serious privacy issue, if an entity were properly motivated.  The cost to find all the utxos on the market would be next to nothing using the method described.  I don't think it would be terribly difficult to follow the coin trails, again with sufficient resources and motivation.

It would be trivial for most state agencies to be currently doing this (although it doesn't seem it's happening based on current activity).  Depending on the situation, a maker could potentially be dragged into being a test case for joinmarket relations to illicit bitcoin sources used in coinjoins.  At least I don't think this has been tested legally.  Maybe maker privacy should also be looked at further, as they go hand-in-hand from what I see.  Maybe I'm just paranoid. Whatever the outcome, this whole bitcoin project is still incredibly interesting to me for lots of reasons, and coinjoins should to be a standardized part of it, imho.

 

[windpath]

New issue in Bitcoin Github this morning from Greg Maxwell:

Improve transaction privacy / fungibility in Bitcoin Core and the Bitcoin system [meta tracking issues] #6568

https://github.com/bitcoin/bitcoin/issues/6568

[go1111111]

I made this commit https://github.com/chris-belcher/joinmarket/commit/be8b63fa332d18a4ba71d68e3894d29d4c9db7c8
It displays the coinjoin fee as a percentage and prints out a huge warning banner if its above 2%

It might be good to have a second layer of confirmation in this case too, just in case someone accidentally hits 'y' once. Like "The fee is extremely high. Are you sure? (y/n)".

[Patel]

Do you have to create your own joinmarket.cfg file? Or is there one that comes included?

[CohibAA]

Do you have to create your own joinmarket.cfg file? Or is there one that comes included?

You need to create one with a text editor.  There is a sample joinmarket.cfg on the wiki.

[belcher]

Also a default one is created if one doesn't exist yet.

[CohibAA]

The most interesting JoinMarket coinjoin to date.  Very cryptic.

3e1572ca351d743d7bf627bc844da8f3bdc84eab4a9d27934a8dba30a2e05fe1

[windpath]

The most interesting JoinMarket coinjoin to date.  Very cryptic.

3e1572ca351d743d7bf627bc844da8f3bdc84eab4a9d27934a8dba30a2e05fe1

Silly, the odds of anyone having a private key for that address are so remote I'd have a better chance of throwing a baseball to the moon...

I researched some of these a while ago (most created by Luke Jr. with bible references): https://www.reddit.com/r/Bitcoin/comments/2mkmoq/til_where_the_bitcoins_at_mysteries_of_the/

[CohibAA]

Silly, the odds of anyone having a private key for that address are so remote I'd have a better chance of throwing a baseball to the moon...

Indeed, it seems to be a burn, for whatever reason(s).

[belcher]

Notes from the Privacy and Fungibility roundtable from the ScalingBitcoin workshop in Montreal.

http://diyhpl.us/wiki/transcripts/scalingbitcoin/privacy-and-fungibility/


I had a few thoughts on fungibility and how JoinMarket could help.

CoinJoin only improves fungibility if it's actually used. I was worried that there might be tragedy-of-the-commons type situation where everyone benefits from fungibility but nobody wants to take the time and money to set up JoinMarket?

The answer is no. Here's why. If fungibility becomes degraded, it would first show up that large bitcoin institutions will reject your coins with the message "Your money is no good here. Those coins were used for illegal or immoral uses 3 transactions ago". When this happens the owner of those coins is going to google the problem. He'll notice that if he uses JoinMarket, he can thwart the analysis of the coins. So I think the fungibility problem solves itself once you have easy access to privacy. Any attempt to enforce non-fungibility of bitcoin will push people to seek out privacy solutions.

This means in all our literature we have to add as a feature unlinking coins from previous owners to our reasons for privacy. Also we should explicitly write a few words about how JoinMarket could help you if you've coins have been rejected. Companies intending to deploy anti-fungibility services might then think twice if they see people can un-taint their coins so easily and cheaply.

Maybe this insight was obvious to others but I just realized now.

[marcus_of_augustus]

Notes from the Privacy and Fungibility roundtable from the ScalingBitcoin workshop in Montreal.

http://diyhpl.us/wiki/transcripts/scalingbitcoin/privacy-and-fungibility/


I had a few thoughts on fungibility and how JoinMarket could help.

CoinJoin only improves fungibility if it's actually used. I was worried that there might be tragedy-of-the-commons type situation where everyone benefits from fungibility but nobody wants to take the time and money to set up JoinMarket?

The answer is no. Here's why. If fungibility becomes degraded, it would first show up that large bitcoin institutions will reject your coins with the message "Your money is no good here. Those coins were used for illegal or immoral uses 3 transactions ago". When this happens the owner of those coins is going to google the problem. He'll notice that if he uses JoinMarket, he can thwart the analysis of the coins. So I think the fungibility problem solves itself once you have easy access to privacy. Any attempt to enforce non-fungibility of bitcoin will push people to seek out privacy solutions.

This means in all our literature we have to add as a feature unlinking coins from previous owners to our reasons for privacy. Also we should explicitly write a few words about how JoinMarket could help you if you've coins have been rejected. Companies intending to deploy anti-fungibility services might then think twice if they see people can un-taint their coins so easily and cheaply.

Maybe this insight was obvious to others but I just realized now.

It is a good point and well worth highlighting. There are many valid and legitimate cases why a person might come to possess coins that need to be de-linked from their past, for reasons that have nothing to do with the current holder, coins that have become tainted through no fault of theirs. There are also many valid and legitimate cases in business where there is a legal or contractual requirement for confidentiality of transactions.

It goes against the vast history of monetary markets selecting fungible goods as the best money, and just basic common experience, to expect all money transfers to be completely public knowledge, that's just a simplistic utopian fantasy trap fallen into recently by some poor reasoning. Good money needs to have strong privacy properties.

[killerjoegreece]

Joinmarket is an awesome project. thanks for your hard work.

[box0214]

i wonder if this concept can be combined into the Multigateway project?

[Financisto]

This is a nice project.

So interesting that IMO It should even be suggested as a Bitcoin Improvement Proposal - BIP.

[belcher]

That's not really what BIPs are for. JoinMarket doesn't need any new consensus.
For advice and ideas I'd already talked to many people before I started coding.

[belcher]

I've merged the code which implements a timeout for takers. If a maker doesn't respond for some time (default 30 seconds) the taker will connect to a new maker and try to finish the coinjoin. This means a tumbler.py run will not be stopped by one nonresponding maker. In fact in testing me and others ran very long tumbler.py runs and fixed several other bugs.

JoinMarket can now very robustly improve your privacy.

[windpath]

I've merged the code which implements a timeout for takers. If a maker doesn't respond for some time (default 30 seconds) the taker will connect to a new maker and try to finish the coinjoin. This means a tumbler.py run will not be stopped by one nonresponding maker. In fact in testing me and others ran very long tumbler.py runs and fixed several other bugs.

JoinMarket can now very robustly improve your privacy.

This is an important update, great job!

[CohibAA]

Awesome job, this is a great update!

[Financisto]

How about publishing some (weekly/monthly) "traded" volume statistics at Joinmarket in the (near) future?

That would be good to spread the word and to get more attention (and liquidity) to this project too.

[belcher]

How about publishing some (weekly/monthly) "traded" volume statistics at Joinmarket in the (near) future?

That would be good to spread the word and to get more attention (and liquidity) to this project too.

There's a project for eventually doing that https://github.com/adlai/cjhunt
Alternatively me and others who run market makers could say how many CoinJoins they participated in last week.

Edit: I'll start, in the past 7 days my bot participated in 23 transactions with 1.94btc in total passing through my coinjoin outputs.

[CohibAA]

I usually only keep my logs for 72 hours, and rarely do I even look at them unless there was an issue, or I am bored.  That said, over the past 3 days, my bot has done approximately 25 joins for a total of about 13 BTC transacted.  My bot has earned exactly zero satoshi during that time, which may explain it's higher transaction volume, relative to belcher's stats.   

[belcher]

Don't you keep the yigen-statement.csv file?

I assume your zero-fee market maker is a slower cheaper way of mixing coins than running tumbler.py

[CohibAA]

Don't you keep the yigen-statement.csv file?

I assume your zero-fee market maker is a slower cheaper way of mixing coins than running tumbler.py

I truncate the csv and logs of anything older than 72 hours.  I do it manually each day, though, as I want to make sure to be able to save anything needed for troubleshooting.  The data I gave was from the current csv file.

Honestly, the small returns don't mean as much to me as seeing this project become commonly used, so I don't charge a maker fee to encourage more taker participation.  I buy coins pretty often, if I have extra cash, and I have daily mining income, so those are the coins being used by my bot, for the most part.  Of course, I don't keep my whole stash on the network, even though I feel like it would be relatively safe if I did.  I don't really have a need to tumble them, but I believe strongly in privacy.  Essentially though, yes, it's a slow and low cost way for my coins to be mixed, while also providing additional liquidity to the market.

My hope is that I won't be replacing another maker when my bot is used, but will just be one additional maker available for free to increase the maker count for each transaction.  That, of course, depends on the mindset of the takers however.  If they want to only mix with me as a sole maker due to having no coinjoin cost, I can't prevent that obviously.  Anecdotally, it seems most people are using above the default maker count when my bot is included.  I think most people realize that mixing with only one maker is not very private.

I wonder when and if we will start to see maker bots that pay takers.  I could imagine at entity (think DNM vendors, admins, etc.) with a "dirty" large stash of coins that constantly require tumbling would be willing to pay a fee to takers to encourage people to use their unclean coins in a join.  It's not my game, but I think it's only a matter of time before someone integrates joinmarket into their wallet structure for this purpose.  While I am sure that some people don't desire this (some joinmarket users, gubermints, etc.) , the beauty of an open-source, decentralized project like this is the freedom to do so.  This possibilities of this project are very intriguing and I am quite thankful for the people putting their time into it.

When I get cash, I often wonder how much cocaine and stripper ass the bill has seen, but I am glad I can use it still regardless, and virtually nobody that I pay it to will care about it's past history.  Bitcoin should also be like this, imho.

[Sukrim]

If there are people that do this stuff for free, you're disincentivizing makers.

I wouldn't want to be a taker in a market that consists of a handful known enthusiasts instead of a huge amount of anonymous people fighting to find a fair price.

[belcher]

I would also suggest that you look out for your own self interest.

Having said that, taker's use a significant amount of randomness in choosing offers to coinjoin with, so somebody offering zero fee in no way means they'll coinjoin with everyone. Of course there's also an upper-limit to how many transaction you can do per time, because of the requirement to wait for a confirm (or even many confirms when that feature is implemented)

[Janitor]

If there are people that do this stuff for free, you're disincentivizing makers.

I wouldn't want to be a taker in a market that consists of a handful known enthusiasts instead of a huge amount of anonymous people fighting to find a fair price.

What you're saying is you'd be happy to see fewer market makers and higher costs, so that you can feel good about it, as opposed to actual users being able to get proper service at a lower price.

[Sukrim]

No, I doubt that you'd get takers if a few makers destroy the market with their "charity" and a price race to the bottom early on.

[dooglus]

The most interesting JoinMarket coinjoin to date.  Very cryptic.

3e1572ca351d743d7bf627bc844da8f3bdc84eab4a9d27934a8dba30a2e05fe1

The address which the burned coins were sent to is mentioned in this deed bundle:

    http://deeds.bitcoin-assets.com/bundle-371897.txt

The first deed says:

Code:

In the Kamigata area, they have a sort of tiered lunchbox they
use for a single day when flower viewing. Upon returning, they
          throw them away, trampling them underfoot.

              The end is important in all things

and the second says:

Code:

            CONVICTED OF ACTIONS:
        - BOUNDLESS DISTRACTION
        - TROLLING SOME FACTION
 CE VERGE P'UN LEGAL INFRACTION!!

Time to leave this network.

My brief apology is dwarfed by massive gratitude
towards you, and you, and most of all... YOU TOO

If you have cared far to read this, you've earnd
the trinity (the best things in life... so phree

To reach me again, you doubtless know how
   some email on keyservers, github, and cetrums

The road   to help
           is 1PavedWithGodAndSomeTeensionXudq5X

Both deeds are signed with PGP key ID 7CDA03F9. When I verify the signature, I see:

    gpg: Signature made Fri 28 Aug 2015 05:50:16 AM PDT using RSA key ID 7CDA03F9
    gpg: Good signature from "Adlai Chandrasekhar <adlai.chandrasekhar@gmail.com>"

This was shortly after adlai had a falling-out with MP:

    http://log.bitcoin-assets.com/?date=25-08-2015#1252200, in which adlai dares agree that assbot is too spammy

    http://log.bitcoin-assets.com/?date=26-08-2015#1252289, in which MP asks him why he thinks he belongs in the channel

    http://log.bitcoin-assets.com/?date=27-08-2015#1253642, in which MP unpersons him

So it looks like the 'odd' coinjoin was adlai's parting message to #bitcoin-assets?

How about publishing some (weekly/monthly) "traded" volume statistics at Joinmarket in the (near) future?

That would be good to spread the word and to get more attention (and liquidity) to this project too.

There's a project for eventually doing that https://github.com/adlai/cjhunt
Alternatively me and others who run market makers could say how many CoinJoins they participated in last week.

Edit: I'll start, in the past 7 days my bot participated in 23 transactions with 1.94btc in total passing through my coinjoin outputs.

In the past 7 days my bot participated in 77 transactions for a total of 48.66 BTC.

[dansmith]

Is it sensible to require JM makers to do some proof-of-work to disincentivize the destruction of the market by the volunteers?

[belcher]

It's not clear volunteers do much harm. They're giving up an opportunity cost to earn money. Their hardware, electricity and internet costs them too. And eventually they run out of UTXOs and can't coinjoin anymore until they get confirmed.

There's also this idea to quantize the market prices to protect against front running. https://github.com/chris-belcher/joinmarket/issues/14#issuecomment-143509788 It's similar to what happens in stock and futures exchanges to stop someone placing an order one cent below everyone else so they can extract information from the market.

[dooglus]

Is it sensible to require JM makers to do some proof-of-work to disincentivize the destruction of the market by the volunteers?

No, I don't think so.

If there is more supply than demand, the price drops. That's normal, healthy, and to be expected.

You seem to be suggesting manipulating the market to force the prices to be higher than the market supports on its own. If we're currently short of "takers" then low prices is what we need to attract more of them, wouldn't you agree?

[Financisto]

There goes the immutable Law of Supply and Demand: https://en.wikipedia.org/wiki/Supply_and_demand

...as strong as the Theory of relativity.

Talking about Joinmarket (and also privacy), is it fully compatible with TOR?

[dooglus]

https://blockchain.info/tx/7e6fe504cc3030997e40655af53f06be04ef5fe2ee7df3430d41d571a75af285 is a messy one - one of the parties cleaned up a whole bunch of small outputs to fund it.

[PesiHUN]

How much can i earn with this? i have 0.01 btc

[belcher]

Talking about Joinmarket (and also privacy), is it fully compatible with TOR?

Yes

How much can i earn with this? i have 0.01 btc

Not very much probably.



In development news, you can now use JoinMarket to send to p2sh addresses too. This was a simple but overlooked fix.

The ob-watcher.py script web page now has the page /orderbook.json which returns all the current offers by makers.


There is a new script which allows you to create unsigned coinjoin transactions. This can be useful if you want to spend from cold storage without the private key touching an internet-connected computer. It can also be used to spend from a p2sh multisig address where many different people must sign the transaction.

https://github.com/chris-belcher/joinmarket/wiki/Spending-from-cold-storage,-P2SH-or-other-exotic-inputs-with-CoinJoin

On the downside, it requires you to manipulate raw transactions and private keys and is thus quite dangerous. Always carefully check your transactions before signing and broadcasting them. Preferably do it a few times on testnet first.

[PesiHUN]

how can i change "nickname = random_nick()" to my nickname? if i simply change it its wont work.

[spiccioli]

how can i change "nickname = random_nick()" to my nickname? if i simply change it its wont work.

nickname = 'your-nick'

then restart yield-generator.

regards.

spiccioli

[belcher]

You don't need to do that. It increases privacy if your IRC bot's nickname is generated randomly.

[phelix]

Idea: Joinmarket Autonomous Agent

A Joinmarket program living on a server making money all by itself via serving customers. Once it has made enough profit it can replicate by renting another server at a (pre programmed) hosting company and installing a copy of itself. It might even send some share home.

Given the somewhat critical nature of joinmarket/coinjoin regarding money laundering this might be a good match. Please consider whether this is legal first, I have no idea.

[tailsjoin]

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I'm looking for someone to take over the maintenance of my Github:
https://github.com/tailsjoin/tailsjoin.
I no longer wish to participate in the development of this project because of this:
https://github.com/chris-belcher/joinmarket/pull/272.

If it's not clear to Chris Belcher that EVERYONE deserves to know where their funds
are going, and how much, then I don't want to have anything to do with it.
Regardless of how this PR goes or what happens with the donation bullshit, I am no
longer working on this.

If you would like to take ownership of the tailsjoin project, please email me at:
tailsjoin@ruggedinbox.com using my GPG key: 44C5398EA821BB41A0C070521B9184DF9E117718.
Unencrypted email will be deleted directly.

- -- tailsjoin Sat Oct 24 17:05:01 UTC 2015 --

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJWK7x4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0NEM1Mzk4RUE4MjFCQjQxQTBDMDcwNTIx
QjkxODRERjlFMTE3NzE4AAoJEBuRhN+eEXcYdawQAIMK+gexSXRMT0r0YRJGf/h0
CDzdMBa+ML7haDYNCutwlXW+4LTI/gjMwdw/IsWD3GtRUrrtlHQyf/lVMuxPYupz
1yYlxg+8HniqDkW02aT/JXJfeqh8nEtLl0MOyH9/mnFfkQfJX070wUkvc+/E2a8q
GQiJdX2YPOSndt21SoXaf4XeBUuqtk8TRh1FPQ0I4Lvc+UP7/O2VoT57VkNbw2KV
Goopy9Rj0bBPsc3hWGyzrmWLsamN7bf+LY1XXwMIpz78LSltdap7hccF4iFEmjoB
0Z17/7DGte7UFy44KViuUFgCTNSEBOR7QB23imMRqWEfM3FQole7Jge3DaR6LtQc
76EYpuSqw8ULrDShx/Jk/R+3iCTFXbmeeA7pQnuE7Qgm+8AIFRtDKllsVsjlfVMw
BCkgpaDXeOkLH2mclAEavl8aoei3enWic7fx7YfwKDj4raiSssiHaqWgzZThIDKd
7oOPWeqRvtrthyzT4gU0yy5QOj26WFzJUSg9vqXQDN8h9Les9hWfXGX28ixm2X4P
Fj9T0UrPC0DQZRazgLSo2XXv4UwcBI2uHWlLmMsKRXtYmitYMnLJR5jsoVKgSGd3
jWVoQSDgKHRpo/I/lpmi5WWEcB/7KwARAR+v7lDPBkdzIv5r+2r1mEyjHmVy2k21
pLWRshn+yalFgDPPxYm8
=JxVw
-----END PGP SIGNATURE-----

[waxwing]

tailsjoin:

I understand your perspective and hope you'll reconsider. I think it was a mistake not to make more effort to publicise the optional donation feature (specifically because there was a default opt-in rather than opt-out). I only started paying attention to it this week.

[belcher]

My view on this matter https://www.reddit.com/r/joinmarket/comments/3q27ys/funding_development_of_joinmarket/

JoinMarket will not exist long term unless development is funded. Chainalysis and Elliptic have dozens of full time developers working to destroy bitcoin's fungibility because they have no problem getting VC funding.

[waxwing]

My view on this matter https://www.reddit.com/r/joinmarket/comments/3q27ys/funding_development_of_joinmarket/

JoinMarket will not exist long term unless development is funded. Chainalysis and Elliptic have dozens of full time developers working to destroy bitcoin's fungibility because they have no problem getting VC funding.

That's understood, but what does 'funding' really mean here? There is no possibility of small donations paying meaningful salaries as VC could do. If funding of that sort is an issue (and sure, it is) then I'm not sure there's any good solution, but skewing the interface so that donations become more likely is not going to solve it (and can result in substantial loss of goodwill).

(I want to repeat to anyone reading, we're talking about *optional* donations here. The only discussion was about how it's presented to the user.)

[Sukrim]

Just FYI: P2Pool has a very similar "revenue" model of default donations and people just switch it off there.

What should this money be used for anyways? Bounties? Salary? Infrastructure? Building a pool of project coins to earn money from?

[tailsjoin]

My view on this matter https://www.reddit.com/r/joinmarket/comments/3q27ys/funding_development_of_joinmarket/

JoinMarket will not exist long term unless development is funded. Chainalysis and Elliptic have dozens of full time developers working to destroy bitcoin's fungibility because they have no problem getting VC funding.

My reply: https://www.reddit.com/r/joinmarket/comments/3q27ys/funding_development_of_joinmarket/cwcfpf9

[Financisto]

Hey guys, why don't you set a vote system (with all developers - and maybe investors too) in order to choose where the money is gonna be invested?

[tailsjoin]

Hey guys, why don't you set a vote system (with all developers - and maybe investors too) in order to choose where the money is gonna be invested?

This has nothing to do with where the funds go. My gripe is with the fact that a hidden "idiot/ignorance" tax was added to the tumbler with a default amount of 1.5%. If users weren't paying daily attention to code changes, they knew nothing about this "donation" amount being automatically deducted from their funds and sent to Chris Belcher. This is how things sat for two weeks until I started to make shit about it. Now Chris wants to act superior to everyone (including waxwing who is the only reason JoinMarket is even worth using) by only answering easy questions and intentionally manipulating the conversation.

Even the supposed announcement made to quell us into shutting up was manipulative. It is titled "Funding development of JoinMarket" and it's not even stickied. It should be an announcement that clearly states there has been a forced opt-out policy and it should be stickied at the very least. This just feels like disrespect piled on top of more disrespect and contempt for us, the not Chris Belchers.

For posterity, here's the thread in question: https://www.reddit.com/r/joinmarket/comments/3q27ys/funding_development_of_joinmarket/

Take a look at how to not address a topic head on. This is a wonderful example of an attempt to beat around a bush until everyone forgets it a bush. It's truly infuriating, as a problem solving human being, to have to deal with someone that acts like a religious fanatic, politician, or a used car salesman.

[Financisto]

That's a shame. I hope you will overcome that misunderstanding as a team and keep improving this unique project.

BTW Tails + Joinmarket would be very powerful.

Hope to see more development on that...

[CohibAA]

 

JM will be losing users because of this.

Why isn't this merged yet?  This is ridiculous to not document properly.  WTF, belcher?

[dooglus]

Why isn't this merged yet?

I asked him that on the reddit post:

dooglus: I see you still didn't merge pull request #272[1] that does nothing but adds the default to the documentation.

belcher_: What is the actual practical alternative? I don't think the US military has an interest in JoinMarket like they have with tor.

I guess he's avoiding the question.

[belcher]

Default donation amount now set to zero.

https://github.com/chris-belcher/joinmarket/commit/0243b7014c1fc0b05451998f9cde476810879dfe

[uwichii]

aradesh@aradesh:~/src/joinmarket$ python yield-generator.py blahhh
downloading wallet history
no tx used
Traceback (most recent call last):
  File "yield-generator.py", line 95, in <module>
    main()
  File "yield-generator.py", line 90, in main
    maker = YieldGenerator(wallet)
  File "yield-generator.py", line 26, in __init__
    Maker.__init__(self, wallet)
  File "/home/aradesh/src/joinmarket/maker.py", line 129, in __init__
    self.orderlist = self.create_my_orders()
  File "yield-generator.py", line 42, in create_my_orders
    max_mix = max(mix_balance, key=mix_balance.get)
ValueError: max() arg is an empty sequence

i guess i should start mining Wink

[tailsjoin]

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I will continue work on tailsjoin, and I will offer pull requests when
possible for JoinMarket. Although this whole thing was a litte much,
I'll be the first to admit that I flew off the handle directly. That
is my way, and I would argue that society needs people that act a bit
irrational in order to draw in the rational.

Thank you to everyone that participated in the conversation regarding
this issue. Thank you Chris for making the appropriate change. Times
like these will only make the project stronger in the long run, and
all of us as people as well.

My site is fixed, my github is fixed. Lets all have a good day.

tailsjoin Fri Oct 30 19:45:48 UTC 2015


-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJWM8kKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0NEM1Mzk4RUE4MjFCQjQxQTBDMDcwNTIx
QjkxODRERjlFMTE3NzE4AAoJEBuRhN+eEXcYzV4P/1JEJdGLiFlbp/aOZhgBsdTI
AQHkL3YTTGSbVYW2wK/mig11wf6tTMQwfHg+WDr6nUBoqFGDzUELMHJ6InttZUFC
vM2vxX8n+E/ZyH3GqU6blVnMlVmsYQvcFZfxcOM3XSfmtLJbaXNwKB8tpUqA3KP1
fY6gFPWlReNC5LuLJNDSDr0a0j3CeEwdruPEbgjKcaYiC6eSZtIxb0e+HIt1P/uR
ufyQmsMPU2qCNHkYJXJS1T0U+GD/1gEjCK8fzpTR4gTGQPWi+HPQNVr66KEfZPTv
SKLczkT7SiAgoNdnW7/QnJ18dZeuLqeGtB3BgCHK0Uhpt/OWJIL2YOo2Q+7/KJSd
qZKBqN8JjGtw56LfZNsfeK66IQDQOK2U2Dt+DZhjZ/irYlvR1I4o7OTd0mjE84Jc
nS+toTjPHecs/KQdv9Dq4AVbdKrdv/Cj6lD3N8O01OdRwnf3I0mqwyZXHuz0/6UE
4pmYAT79vkk5vfzlY37viEObPpDuDkN1mwIqDGt94shTVJU1LsbcnvlJbpmM7uCd
J9TmbHO/iJmwkpuBGdtDMTysnJI1NPaopCoL2qbdsmO0Hz/OZoxwVyDY40qj5cZc
cKf9Ju8FqpJb0Mf7mDof21FJG4sneD6JRLqocxldnERJgvhmqKQWxa1XuUm4HyJy
KdBBwZ2ch2Bcj+ha222R
=DtBR
-----END PGP SIGNATURE-----

[dooglus]

I will continue work on tailsjoin, and I will offer pull requests when
possible for JoinMarket.

Code:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Nice one!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJWM881AAoJEEvmoBBJKjWOvPkH/RmNgjY5Z+SMHHcP4Z3Oat1r
AEdVAuGkhtRftCbbBaOP71Uly5CbajjbkWyhIDf+t6Bxpzf4T92MxIQWWQAO1OuJ
hp8J4yD/oLKwxh394norKsqUV029GIawgLziYVrLJCv1PZosJ0l10ZJ3IvpjqLM0
B2DHYS5vnW0sUZdgvUzsKJYS/6b5DeKSwUpsUo+TkbSnI2+YVoVCfcHVSZevhrcq
yPBwUl+UL2jmk/McYseuzDO0SXBOMUNuBTQZxofSEsQC6XfEUg3CgZvGJrHQ6Pz5
7iF9RtqSpvxlDGPY8N2L4Vzwu9ed98toXmd/Pn7NLaeCJzjoQPS5dGOh0+WCKss=
=YpJB
-----END PGP SIGNATURE-----

[waxwing]

aradesh@aradesh:~/src/joinmarket$ python yield-generator.py blahhh
downloading wallet history
no tx used
Traceback (most recent call last):
  File "yield-generator.py", line 95, in <module>
    main()
  File "yield-generator.py", line 90, in main
    maker = YieldGenerator(wallet)
  File "yield-generator.py", line 26, in __init__
    Maker.__init__(self, wallet)
  File "/home/aradesh/src/joinmarket/maker.py", line 129, in __init__
    self.orderlist = self.create_my_orders()
  File "yield-generator.py", line 42, in create_my_orders
    max_mix = max(mix_balance, key=mix_balance.get)
ValueError: max() arg is an empty sequence

i guess i should start mining Wink

You need to fund the wallet. Follow the instructions here: https://github.com/chris-belcher/joinmarket/wiki/Using-the-JoinMarket-internal-wallet#funding-wallet-and-displaying-balance

[cysive]

Does the bitoind rpc option work with an encrypted wallet?