Of course you cannot trust any service more than to provide you the entire transaction you get to sign - not only its hash.Then you make sure that at least one of its outputs satisfies your input.And then you get to know more about a possible connections between the txs inputs and output. Which inforamtion, who knows, maybe you'll be able to sell one day in a future so you may want to keep it

Its really not as cool as you think, unless you build a huge and anonymous infrastrtuctere for it.Who's going to do it? Jesus is dead for all I know. We're talking about tor at least, otherwise it dont make no sense. And what: SR style, or p2p? Is there even a p2p in tor? Who's going to pay for it to profit from it? Or it won't happen...

Anyway, understand that the weakest link here is the ip that sends your money to the network. Sharing the tx with your pals or strangers picked by some system to increase privacy - give me a break

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain. No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction. Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Google "bitcoin stealth address"

I'm an independent developer working on bitcoin-core, making my living off community donations.If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

Rather than adding more steps and layers to the system, I propose ignoring the chance of the joiner operator skimming merges.

If it bothers anyone, they can send their donation to a new address in their own wallet, then send that to the donation address in the normal way. This operation could even be scripted. (Your wallet searches google for your payment address. If there are no results, it is more or less impossible for another coin join user to be sending to that address. If there are results for it outside of the explorer sites, it automatically switches into 2-stage mode.)

maaku's solution does not seem to work as it requires communication between the participants

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain.

Are they signing a set of all outputs randomly mixed up? This wouldn't solve the problem.Or are they signing their individual outputs? There is no anonymity now.

Quote

No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction.

I can't see how this helps to solve the problem.

Quote

Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.

I'm not really sure what you're saying here. If you're talking about a blind signature protocol can you be more specific about how it can work in this case.

Quote

the example was a donation address, it would be difficult to imagine this changing for each donation

Quote

Google "bitcoin stealth address"

I didn't say that it wasn't possible to change the address for each donation. This could be done without stealth addresses. I just think that most people asking for donations will just put up an address and ask people to send coins to it.

They sign a list of their outputs, some of which are explicit, some of which are blinded. The blind signed outputs are separately checked (the server blind signed them without knowing what they were, so couldn't later skim them without detection). So each participant has a list of non-mixed outputs signed by their owners, and a list of blinded outputs signed by the server before it had a chance to do any funny business. Together these should add up to the entire transaction (modulo facilitator and miner fees).

I'm an independent developer working on bitcoin-core, making my living off community donations.If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

Its setup to use Testnet (i have not tried it on mainnet as its alpha software!). It can be easily configured to use either a local filesystem to communicate or P2P over the Internet. The filesystem communication is fairly robust while the P2P Internet mode works reasonably well, but will require a lot more testing and work to prevent bad actors.

There is a protocol specification: https://github.com/michaelgpearce/coinmux/blob/master/docs/spec.mdThe peers communicate using JSON messages. None of the connected peers can associate input with output ownership from the messages themselves, only by IP addresses. This is a pretty big privacy leak, but can be solved by integrating Tor or Freenet to communicate the messages.

I've only implemented a command line interface for now, but the CLI is event driven and built with a GUI in mind. I don't want non-developers trying it yet so a CLI seems like a good place to start.

The easiest way to try it out locally is to use "--data-store filesystem" and invoke the command from a couple of different terminal sessions on your computer. Again, its setup to use Testnet, so you need a Testnet wallet / private keys.

Hey all, i just released v0.1.0 of Coinmux (followed quickly by 0.1.1 to fix a couple of minor UI issues) which is my milestone for having things functional on Testnet. I'm ready to move on to building a GUI to sit on top of the code already there and make it easier to use.

But before I do that, I want to try it out on the Bitcoin MAINNET and with some STRANGERS on the Internet! I've never done either!

I'm hoping a couple of you are brave enough to try it with me. I want to do a small CoinJoin transaction, 0.001 BTC (a little less than 1USD) . To get a suitable wallet, I simply went to bitaddress.org, created a new wallet for the CoinJoin input, and then sent 0.0015 BTC to it from my main wallet (a little extra for miner fees). Any address with a balance > 0.0015 will work, but I would not recommend using your primary wallet. There shouldn't be any issues, but better to be safe than sorry.

If you are interested, there is a link to download the latest Java client here: https://github.com/michaelgpearce/coinmux. To use the Mainnet Bitcoin network instead of Testnet, you'll simply need to set an environment variable COINMUX_ENV=production. On a Unixy OS, you should be able to just type this command in the terminal/console where you run the Java command. On Windows, i believe you use the SET command, but its been years since i've used Windows.

Yep. It uses TomP2P. My initial implementation was going to use Freenet, but I didn't want to require needing any external applications running.

In Coinmux, I call the communication layer a Data store in the code. There is an implementation using TomP2P, the file system and one that uses only memory for testing purposes. It's straight forward to implement these and I did also consider Bitmessage. Unfortunately, the Bitmessage JSON API looked to be very heavily tied to a specific user in the UI with no way to create a new user via API or send messages as a specific user. This lead me to stop investigating it further.

Thanks! There's a bit of a trust issue with any new Bitcoin software project (especially with one that asks you to enter your private key!), so i'm having a hard time finding people to try it out. Hopefully time will be the solution to that. I'm planning on giving a presentation at the SF Bitcoin Meetup to increase CoinJoin and Coinmux awareness.