Joinmarket used to make this: https://blockchain.info/tx/dc5b6d3f1fe45cd944fe30e2c28554267d7fb4c1d1a5ea199933be30205b5611
Not very easy job to unmix...
Topic: [ANN] Joinmarket - Coinjoin that people will actually use - page 16. (Read 85001 times)
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).
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.
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).
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?
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).
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.
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.
Quote
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.
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.
They're trickling through. Just saw another join; 7 party: e38e45d004ef913ee4e952d1f185dbea91cc8cc56e22aa7f767a3edec952a4a9
Amounts small so far, which is to be expected. But all the same.
Amounts small so far, which is to be expected. But all the same.
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.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?
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. 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?
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?
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?
This is a great project, thanks!
Do you/we need more testnet3 or/and mainnet yield bots?
Mainnet would be set as following?
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
Looking into this project for journalistic purposes
Very cool project, I'll be setting up my own yield generator soon to provide some liquidity.
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
This is the new mining
This is a great project, thanks!
Do you/we need more testnet3 or/and mainnet yield bots?
Mainnet would be set as following?
Do you/we need more testnet3 or/and mainnet yield bots?
Mainnet would be set as following?
Code:
network = mainnet
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.
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.
Looking forward to this being pulled into all major clients.
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
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
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
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
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.
Any updates?
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.
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.
Jump to: