Topic: CoinJoin: Bitcoin privacy for the real world - page 26. (Read 294672 times)

https://github.com/etotheipi/BitcoinArmory/issues/127

Someone should create a site where you enter a P2SH address, it gives back a traditional address, and when it receives money at the traditional address, it immediately forwards the unconfirmed BTC to the P2SH address. (Unmodified Bitcoin-Qt can do this sort of thing, I think.) Not terribly secure, but better than giving up on advanced features entirely.

Electrum does as well.

Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature. It's not the only thing, some websites will, electrum will, the SX tools will. But armory, nothing bitcoinj based, or blockchain.info will.

It's a real bummer because I think that using a multi-signature escrow is the right and proper thing to do here. I don't think I should personally be holding money set aside for this— my computer security is good, but I think no single person should be entrusted with holding non-trivial amounts of other folks money.  How many bitcoins have been stolen that could have been avoided if the norm was to use in blockchain escrows for things, but people didn't because of silly wallet compatibility?    (And perhaps people will understand that I'm really not being a rabid bitcoin-qt advocate when I say that I'm not super eager to see lots of alternative implementations, they really do complicate the ecosystem and make new features harder for people to use)  [/OT]

Send from the Bitcoin Qt client, I think it's the only client that supports these P2SH address types. (beginning with a 3)

It's a perfectly valid address. You just need to use Bitcoin-Qt or another sane wallet application.

Would like to donate 1BTC and possibly more.  blockchain.info says invalid address though.   

This thread is so big. Could anyone, who managed to read it, tell me what prevents CIA/FBI/MI6 from taking part in most of such transactions? This would let them to "break" privacy, coz they know which inputs and outputs r their own. Bitcoin network is already flooded with a lot of "spying" nodes, the same approach can be used against CoinJoin.

Supposing you did nothing to obfuscate your ip, would the peers you are talking to have any means by which to link your ip address to the outputs of the transactions that belonged to you? or would they simply be recording the fact that your ip address participated in that particular coinJoin session?

Figuring out how to construct CoinJoin transactions is just the first step in having a usable system.

The rest of the work is the nuts and bolts of how users actually find suitable mixing partners.

Based on how users are likely going to want to employ CoinJoin, there are going to be two general classes of clients:

• Opportunistic clients which are configured to wait for suitable conditions and perform mixing in the background. These will necessarily be clients where the private keys are stored on a online machine. Mixing is not time sensitive at all for them.
• Immediate clients who want to use a CoinJoin transaction to send bitcoins. They need to be able to complete the protocol quickly, within a few seconds, because they using an Armory-style offline wallet where they need to save an unsigned transaction to a suitable medium, cross the air gap, sign the transaction, and broadcast it all before the BitPay timer runs out.

In order for the immediate clients to be able to operate, you need a lot of opportunistic clients. Also, some of the opportunistic clients will be FBI honeypots, so there's that too.

Right off the bat, a CoinJoin negotiation protocol should be work over Tor. The TorChat system is a good model for this - they actually bundle a Tor binary directly into their application so that a TorChat user doesn't need to download, install, and configure Tor separately. They also use the hidden service URL as a user name, which means you don't need some additional name mapping system.

It's too bad the Tor project hasn't separated their core functionality library into a library that could be used by third-party applications, despite repeated calls to do so.

Perhaps CoinJoin clients could just work through the libpurple plugin for TorChat.

Once the clients all meet up, they need a way to negotiate parameters like output sizes. If an immediate client wants to use CoinJoin for a purchase, it's not likely that any other immediate clients are going to have the exact same output size needs, so they'll have to rely on opportunistic clients who have specified a compatible range of acceptable output sizes.

tl;dr: Clients need a protocol by which they can register their willingness to participate in a CoinJoin, and any relevant constraints which determine who is and is not a suitable partner, over a secure channel (because even though you might theoretically do it in the clear, people who want CoinJoin are also going to want to have IP address-level privacy too).

If you don't use tor (or another similar network) then the peers you're talking to could record your IP, which you presumably want to keep private too. I mostly pointed it out to head off comments like "OMG YOUR PEERS CAN RECORD YOUR IP!" ... yes, they can, other things fix that. This is intended to address privacy in the blockchain.

I dont understand the advantage of using tor. unless of course you wanted to, in addition to hiding information about your transaction, actually hide the fact that you are participating in the bitcoin system entirely. Wouldn't the coinjoin facilitator just publish a public key that all other participants could use to encrypt their transaction?

Guys, this is one immensely valuable undertaking.  Spread the word and let's secure fungibility like Satoshi intended.

Privacy is the lifeline, otherwise there is no competition with traditional banking system. Thanks a lot for your contributions.

In light of the recent strange discussions/opinions by leading bitcoin foundation members this is even more important. Just added 0.5 BTC to the bounty. Wish I had more time to work on this myself...

Exactly. Redlisting will turn into blacklisting and it will turn into whitelisting if not stopped.

But if you mix all of the coins, how can I blacklist them and allow governments to intervene? - Mike Hearn

If you are a Bitcoin investor, then you really should give a damn about Coinjoin. Destroying its fungibility would allow Wall Street's money masters to separate Bitcoin into assets of different sorts, like "good bitcoins" and "bad bitcoins", and manipulate their values while giving themselves unfair advantages like they have always been doing(e.g., with gold). The bitcoins they control will obviously be A+ grade, and yours may become entirely worthless someday even if you just hoard them and do nothing, to ensure your asset doesn't get depreciated is a pretty big incentive I guess.

Because the whole concept of "red" to begin with is a human imposed concept which is senseless in a world where people are widely and casually using coinjoin. This is why its important that it be made as easy and as cheap as possible, because its not really useful to anyone unless its usable by everyone.

I'd like it if someone could address a concern I raised in another thread, but is relevant to mention here:

The outputs of a CoinJoin transaction will have an amount of red taint equal to the amount of red taint on the inputs.  So basically half of the participants will get cleaner coins and half will get dirtier coins.  There is no net reduction in red taint.

Unless you are assuming that number-of-hops somehow makes your redcoins less red, but I don't believe this to be the case.  The redness factor is really about the source transactions that lead into your transaction, and if a high % of those are red then your coins are tainted.

What incentive is there for clean coins to participate in CoinJoin?  Wouldn't it tend to be the case that CoinJoin inputs are all quite red?