Topic: Automatic Coin Mixing Idea - page 3. (Read 9986 times)

+1

Most people see no problem in said "money laundering", because most of the money to be laundered is from drug trade and lots of people here are against the war on drug.

Laundering money of drug trade is not the same as laundering money of say "human trafficking" or "mass murdering".

To be honest if this feature would be removed I'd quit Bitcoin and wouldn't give it a long time before it get shut down.

The way it currently work also add value to newly mined coins, which add incentive for miners to secure the network.

Tracking tainted coins is already very challenging,  As a coin mixer would I bother to do research on every case of stolen coins and act as a judge on every cases,,, for say 50000$ worth of BTC ? probably NO.  But say there was a major heist of 500k BTC at a major exchange and the savings of tens of thousands of peoples were lost, putting the whole economy at risk. ?
Or say someone kidnapped some very important person and the life of many depends on finding who spent the coins ?

In those later cases I would rather accept the highest fee of whether the client or the affected peoples.  People who got stolen 50 000 BTC would pay a hefty bounty for any information leading to the culprit.

Sorry but I always thought of this as a feature of Bitcoin and I will continue to see coin mixing as a non-issue for 99.99% of honest peoples and 99% of dishonest ones.

That is exactly what mixing should focus on.

I can take 73.26 and split it myself in to smaller sizes in a way that looks like a series of purchases on my own node with no cooperation needed from anyone else. What I can't do is anonymously combine all my dust addresses into an address large enough to be useful without outside assistance. A client can be very careful to use different incoming addresses for every receipt and to never link addresses but at some point the user is going to want to spend an amount larger than the balance of any single address. The only way to avoid this situation without compromizing anonyminity is to have the ability to securely combine small addresses into larger ones.

That's why I think mixing should be focused on transactions which have many more inputs than outputs. https://bitcointalksearch.org/topic/m.1036811

Bad behaviors like what?  Donating to WikiLeaks and other politically incorrect causes?

Do we want Bitcoin to be a system that tracks taint of coins, or don't most of us share the consensus that the system as a whole would be better off without the notion of tainted coins, even if that means a few thieves will have an easier time getting away with their crimes?  For everything you're asking for, there's MasterCard.

... by default ?

What's the benefits of participating in mixing someone else coins ?

Say 98% of users do not have anything to hide and would prefer all transactions be traceable for the benefits of discouraging bad behaviors ?

I would much prefer someone who stole BTCs to pay a fee to shameless mixer than to help him unknowingly.

Of course, leave it to the guy who runs a node that connects to hundreds or thousands of peers at a time to point this out =)

Yes, someone in a position to do that would be able to flag his coins as "not mixed" and his attack would work.  Of course, he could also just ignore the request to mix coins, which would be just as effective and leave the coins just as unmixed, and would also be a normal expected response from a client that may not want to / be able to / feel like it / have any coins / randomnumber
By and large though, mixing would happen everywhere, mostly for people who only passively care about mixing their coins.  Someone dead serious about mixing their coins might leave a node online and let it mix for days or weeks, and would succeed in doing so even if "NotMixed" got thrown in a few steps along the way.

The best part of this proposal is the sheer simplicity. That alone makes it 10x as likely to get into the official client as any other mixing proposal - in my mind.

Simple ubiquitous mixing gets it out of the alleyways, and into the light of day - where no-one need fear participating.

Reducing the denominations to M^n is a great idea too. I would almost suggest initially reducing denominations to M^1 alone - to simplify the initial protocol. Maybe that's going too far, and you'd find fewer participants. Or maybe it's good because it means participants would find partners that would otherwise have been holding-out for M^2, M^3, or M^4. Maybe it would be a good first step to shake things out. I've got in mind Gavin's recent Gist about lessons learned from BIP 16 (https://gist.github.com/2355445), and how he wants to apply them in BIP 34 (https://bitcointalksearch.org/topic/bip-34-block-height-in-the-coinbase-92558). Specifically: "Think about laying a solid foundation, and then rolling out changes in stages. Baby steps instead of change-it-all-at-once."


And maybe a checkbox to "support" the anonymity of others - by merely relaying these solicitations and transactions. There might be those who find mixing risky - especially while it's new. Those same people, though, might be more than happy to relay the required messages.


And then OP goes and replies to a valid concern:


I love it. As Austonst puts it:

If fairly common (if not ubiquitous), it sounds like these mixes could start to render "traditional" blockchain analysis obsolete. The heritage of coins that have never participated in such mixing might start to become less clear.


And another thing - the simplicity of this proposal widens the pool of developers willing and able to implement it.

Kudos, Casascius.

Great idea…I like the train of thought.


I think you could mitigate this risk by simply altering some rules in the client regarding connection diversity and churning connections to ensure you're never connected to a single node for an excessive amount of time.  Also, I don't think the proposal was to broadcast these mix requests (like a normal transaction is relayed)…I think the proposal suggests to announce such requests to peers and in most cases they either act on it or not, but wouldn't relay the request.  In some cases they would relay requests to improve privacy.

I could see some ways this would work - the challenge would be in trying to come up with a sustainable coordinator for those transactions.

If Alice originates a transaction, and miner Mike wants to propose to Alice that she sign transaction A+B which combines her transaction with one of Bob's... then Mike needs a way to contact Alice.  Alice pretty much needs to attach a calling card to the transaction, which gives her less anonymity rather than more.

Or, as you seem to be suggesting, Mike could start broadcasting the incomplete transaction around the network, in the hopes it will end up reaching Alice so she can sign it.

The only problem is that if the network starts permitting such incomplete transactions to be relayed, then a vandal could send out a hundred transactions, and then send out thousands of proposals to combine those 100 transactions 100+ different ways each, exponentially amplifying modest transaction spam into a full-on DoS attack.

Nice idea. But it could be fairly easy for someone with good connectivity to de-anonymoize transactions. If for example someone with the address 1NotMixed keeps broadcasting his address as suitable for mixing every transaction that involves that address you know that the other output was the real destination address. Even if it is a chain of mixed transactions every one they manage to involve themselves in increases the likelihood of predicting the final destination address.

Or not necessarily using the same address, but unique addresses and sending back to 1NotMixed after.

And the block chain grows at an accelerated pace...

I see your points.
How about this:
First step is creating a transaction as it is now.
After this the client creates a combined transaction with other unconfirmed and uncombined transaction. This combined one is almost like of a double spend on the first one, so legacy miners would ignore it.
Now other clients upon seeing this combined transaction, check if they can sign it, and will do so if necessary.
Once all inputs in the combined transaction are signed, a miner can replace all those single transaction by the combined one.

Okay, I get your point now. I guess the way this mixing would solve that issue is to make it meaningless to know that addresses are related. Sure, you can see that four 25 BTC outputs have come together to pay 100 total BTC, but since mixing occurs between each transaction, you can't trace them any further back. You can't tell who owns them or what those coins have done in the past, and if the mixing has been done properly (like in Casascius' last post), there won't be any cases of "Oh, I see from tx1 that someone owns addresses A,B,C and I see from tx2 that someone owns C,D,E. Therefore, the same person owns all 5 addresses."

Whoo, you guys type fast. 3 more replies since I started writing this up.


In the original post, it was mentioned that in the future, most people will be storing only the unspent transactions, not the entire history of everything. Many of the blockchain pruning ideas implement something similar, and I think it's pretty likely that the solution that finally gets implemented will only store unspent transactions. While casascius' method would bloat the blockchain with transactions, it would dramatically reduce the side-chain that only stores unspent transactions.

My proposal would indeed bloat the block chain, and therefore a prerequisite would be appropriate transaction pruning - something already being discussed by the devs.  It would also require deterministic wallets in the main client, otherwise a wallet backup would expire very quickly as all of the addresses are used up for this purpose.  So for now, my proposal is totally premature for implementation - it just won't be for much longer.

Your "transaction-intent" proposal would work really well, other than that it would be very easy to disrupt.  The Achilles heel is that until ALL of the signatures are provided, the entire transaction is invalid.

If every Bitcoin transaction were made by soliciting an offer to combine it with somebody else's transaction and a protocol were devised to coordinate this, transaction processing on the entire Bitcoin network could be brought to a halt just by somebody writing a bot that pretends to cooperate for as long as possible, but refuses to actually sign any transactions... and then running a few dozen instances of that bot.

A few dozen instances of such a bot would make detection and exclusion of the bot impossible, because they would cooperate and sign transactions most of the time, but each one would take turns disrupting a whole distributed transaction, letting a different bot instance do the job of disrupting each separate attempt.  Sort of like colluding in online poker.

The only problem is that the more participants in the group, the easier it is for one party to disrupt the operation OR spoil the anonymity by recording/publishing the input-to-output connections.  Everyone has to participate, and no matter how you slice it, either everyone in the group will know the mapping of addresses for everyone in the group, OR anyone in the group can easily disrupt the process for everyone by failing to play by the rules (e.g. refusing to sign, or spending their original funds while the signatures are being coordinated, thus voiding the whole transaction).

The right group size is small and casual.  The average Bitcoin node tries to connect to 8 other nodes, and if "some" of those nodes cooperate, you'll have a group size of 2 to 4 most of the time.

One more point, while casascius method would extremely bloat the block chain, mine could actually reduce the size.

Reducing the swaps to specific granular amounts helps prevent this by making the units as indistinct as possible.

If five people go to a party, and one person has a 3-dollar bill, another person has a 17-dollar bill, and the others have equally unusual amounts, then it is clear how this idea is going to be ineffective.  And these weird denominations of bills are exactly like how Bitcoin works internally.  But that is why sticking to some standard swap denominations is important (as I suggested with 1, 5, 25, etc.).

if before everyone gets to the party, they exchange their unusual denominations for one-dollar bills, and then exchange 1:1 all evening, someone who hands you 5 of them isn't going to reveal any information on the basis of which 5 one-dollar bills you got, other than that one person came to the party with at least five dollars.  For all intents and purposes they are equally anonymous.

If I am an anonymizing Bitcoin client and somebody sends me 73.26 BTC, the first thing I will do is split that into 25+25+5+5+5+5+1+1+1+.20+.04 and I will probably discard the remaining 0.02 as a transaction fee somewhere so long as it's not worth mixing.  Then, all of those chunks will be traded with others, one-for-one.  By the time each chunk has been traded six or seven times, what's a recipient going to learn to know that for example three chunks of five were combined to make fifteen?  Not much of use.

One could perform an analysis on those three chunks to see if they might happen to all share a common possible point of origin on the block chain (an intersection attack), which could identify the original origin.  But that could be easily mitigated just by the client occasionally "mixing" same-sized chunks with itself, which is indistinguishable from mixing with others, and which would make the ancestry of each chunk look very "inbred" so to speak, and therefore poorly useful for confidently identifying distinct faraway ancestors.

Not really, because once I do my 100btc transaction, I have to combine all those in my own wallet. So mine are again identifiable as mine. The "bad" operation is to actual combine. So my idea was, make the combine operation more anonymously.

I see. Thanks for that clarification. Is it true, then, that a tx message is entirely invalid if all the input sigs are not included/valid? That is, when Alice creates & signs the tx (including Bob's input), but Bob never signs it, then it would never survive on the network (supposing Bob decided to transmit).

Forgive me if this is obvious to the experts here. I have the technical background to understand and appreciate this stuff, but I'm still new to this protocol.