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

If outputs are in the form of Xⁿ, then you can easily implement a cutoff by specifying a minimum value for n. Leftovers just get added to the transaction fee.

I really don't care if there is a recommended standard of X=2, or X=5, or if an explicit negotiation step is added to the protocol to choose a value for X, just as long as there's some way to do it that actually gets implemented.

Hmm. It might simplify things by "approximating" powers of 2: 1, 2, 5, 10, 25, 50, 100, 250, 500, etc. Similarly, 0.5, 0.2, 0.1, 0.05, 0.02, 0.01, etc.

The downside is there's somewhat more risk of analysis matching inputs to outputs, but I would think the increased risk is very slight.

Among the benefits is that the math is simpler, allowing other ideas to be easily implemented (such as a cutoff value: everything under 0.000x BTC is lumped into one output. If a small, random transaction fee is also included, this avoids dust outputs but is still resistant to analysis.)

For example, your above outputs, after removing small transactions fees, might break down to

 A) 5.21872289 (prior output after removing a randomized 0.00002711 txn fee) =
  5 + 0.2 + 0.01 + 0.005 + 0.002 + 0.001 + 0.0005 + 0.0002 + 0.0002289 BTC

 B) 3.43742991 (prior output after removing a randomized 0.00007039 txn fee) =
  2 + 1 + 0.2 + 0.2 + .02 + 0.01 + 0.005 + 0.002 + 0.0002 + 0.0002 + 0.00002991 BTC

Almost all of the privacy, and the coins are less noticeable (as opposed to values like 0.03125 BTC) even just sitting in the wallet. And this would be a much better result too for those of us managing coins in paper wallets who need to determine how many change addresses to grab to spend X bitcoins.

Just a thought.

Have sent some BTC and would be more than happy to set up a project on CIYAM Open for this (free of charge for its lifetime of course).

I tend to think that Coinjoin pools should be like Tor flashproxies, ephemeral, ad-hoc and untrackable.

IMHO we should motivate miners to operate liquid CoinJoin pools and pass all their new block rewards through it. Then integrate CoinJoin in as many clients as possible, for automatic or semi-automatic use. When everything is tainted, nothing is, and all list operators will look pretty stupid.

It's in the best interest of miners that bitcoins remain fungible long term, but some short sighted individual miners might object to getting slightly tainted coins. This could be offset by a small fee paid by CoinJoin users, and shared between pools and miners.

theymos, gmaxwell, everyone - excellent project! My donation on the way too...

I agree so I just send ~$50 to donations https://blockchain.info/tx/37fa76c95c06c4f35ac4069a84d75a022275a80bd35a05e102c8f6ad4d02646d

Theymos, you rock! I've already donated but you've inspired me to send a little more.

CoinJoin needs to be nicely implemented in Bitcoin-Qt before any of these ridiculous blacklist proposals take off. So for the next 30 days, I will match donations to the CoinJoin bounty fund (3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk), up to a maximum of 5 BTC. Just donate to that address, and in 30 days I'll donate the difference between the current received amount (16.21420773) and the received amount at that time (max 5 BTC).

Edit: Paid 5 BTC.

A decentralised approach would provide enough variety so that the number of people who have to compromise would decrease, but I agree that this harms the effectiveness of the anonymity of inputs. It would also be less easy to convince a nosy listing agency that you were settling several hundred payments in a single transaction... especially when several hundred other CoinJoin participants could be making the same claim to the very same transaction to the same agency. It's not possible that you're all the sole originator of the same transaction.

Yea, and to that effect there should be a step prior to the CJ where outputs are made uniform.

And I believe that drastically reduces its usefulness.

It's fine as an academic exercise but how people actually use their bitcoins in the real world is considerably more messy. Unless you can handle situations where the users need to mix differing amounts of coins you'll either degrade the mixing to uselessness or else end up with a double coincidence of wants problem where nobody can find suitable partners top mix with.

The mixing application described in the OP uses same valued outputs for two reasons: (1) to avoid this sort of identification, and (2) to prevent the facilitator from learning identities through blind signatures. This requires that within a single transaction, the mixed outputs must have the same value denominations (or be divided into groups of same-valued denominations). The hypothetical given is a weaker protocol than the OP.

That said, there is no reason that the common denomination used by one transaction has to match or be a multiple of the common denomination of another - that gains you nothing as far as I can tell.

Such coins are not at rest, thus can be stolen by a determined cracker.

Oops, seems that a signature was forgotten . I'll donate half a coin to this as soon as the sig is in place!

Please everyone consider donating.

I think there are too many compliant goody goodies out there for this to work. You only have to craft a well thought through smear campaign against anonymising and most people will be too anxious to rebel against it, they will believe the nonsense is true.

There are fewer miners than users, and they are naturally determined risk takers. They are easier to convince of the drawbacks than average users, especially as they have probably got more BTC balance whose long term value and viability they wish to protect.

Yes.  Mixing must be the norm, not the exception.

If it is the exception, then even the fact that you are engaging in it is suspicious.

More difficult to popularise anonymising features than it is to find out what colour the biggest miners like their address lists. If they want the lists transparent, instead of red, black blue green or white, then they should prefer to ban any such coloured listed addresses from their transaction inclusions.

Let's push to hit these lists right at their fundamentals, make them undesirable and unusable, not the other way around.

Exactly what I am talking about.

We must make coin mixing almost as common as sending them. This way governments will have no choice but face the reality.

And/or incorporating it into clients so people wouldn't have to bother. E.g. I wouldn't mind to spend a millibit a week in network fees just to have my coins periodically mixed.