belcher (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 31, 2015, 11:14:59 PM |
|
FWIW I made a subreddit for the project. https://www.reddit.com/r/joinmarketI 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/57The very first version of tumbler.py was created. https://github.com/chris-belcher/joinmarket/blob/master/tumbler.pyMeaning 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
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
TheButterZone
Legendary
Offline
Activity: 3024
Merit: 1032
RIP Mommy
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2015, 09:45:21 PM |
|
Looking forward to this being pulled into all major clients.
|
Saying that you don't trust someone because of their behavior is completely valid.
|
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2015, 05:53:42 AM |
|
This is a great project, thanks! Do you/we need more testnet3 or/and mainnet yield bots? Mainnet would be set as following?
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2015, 11:38:29 AM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2015, 11:45:42 AM |
|
Very cool project, I'll be setting up my own yield generator soon to provide some liquidity.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
jdebunt
Legendary
Offline
Activity: 1596
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2015, 11:48:04 AM |
|
Looking into this project for journalistic purposes ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
waxwing
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2015, 04:36:49 PM |
|
This is a great project, thanks! Do you/we need more testnet3 or/and mainnet yield bots? Mainnet would be set as following? Correct. Be sure to read the README and the guides in the wiki on github carefully. That's just to start ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 06:03:39 AM Last edit: May 11, 2015, 09:11:40 AM by 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?
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 08:18:28 AM |
|
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.
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 09:12:01 AM |
|
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.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
waxwing
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 12:06:19 PM |
|
They're trickling through. Just saw another join; 7 party: e38e45d004ef913ee4e952d1f185dbea91cc8cc56e22aa7f767a3edec952a4a9
Amounts small so far, which is to be expected. But all the same.
|
PGP fingerprint 2B6FC204D9BF332D062B 461A141001A1AF77F20B (use email to contact)
|
|
|
belcher (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 03:45:07 PM |
|
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.
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 06:50:16 PM |
|
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?
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
belcher (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 11, 2015, 07:16:49 PM |
|
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.
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
Anduck
Legendary
Offline
Activity: 1511
Merit: 1072
quack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2015, 01:14:29 AM |
|
|
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2015, 05:07:53 AM |
|
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.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
belcher (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 12, 2015, 06:35:22 PM |
|
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.
|
1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use. PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129
|
|
|
domob
Legendary
Offline
Activity: 1135
Merit: 1170
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 13, 2015, 05:44:56 AM |
|
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.
|
Use your Namecoin identity as OpenID: https://nameid.org/Donations: 1 domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NC domobcmcmVdxC5yxMitojQ4tvAtv99pY BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
|
|
|
Itskok
Jr. Member
Offline
Activity: 54
Merit: 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 16, 2015, 05:17:53 PM |
|
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..
|
|
|
|
|