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.
Topic: [ANN] Joinmarket - Coinjoin that people will actually use - page 17. (Read 84864 times)
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. 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?
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.
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. 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?
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?
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?
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.
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.
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.
Can it use coinshuffle for the mix?
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. 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.
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
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.
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.
Just a heads up for anyone trying it out - don't expect it be stable atm.
Update bots from github regularly
Update bots from github regularly
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.
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.
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
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
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?
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 nowYou could also do it via a Bitmessage channel...
Got a pastebin of the terminal in that case 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.
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.
I noticed tonight there were four yield-generators in the pit. So I went ahead and did a five-party coinjoin.
The command was
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
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
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
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.
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
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
Interesting!
Jump to: