Topic: CoinShuffle: Practical Decentralized Coin Mixing for Bitcoin - page 2. (Read 23791 times)

Kristov Atlas reviewed it, you might want to read it. Or wait a week, since open source is in a week.

Has the DarkCoin mixing algorithm been made open source?

Is this system better than DarkCoin (which is not CoinJoin like many people believe)?

Links to IP addresses would be broken?

It's actually mentioned it the related work section. But I agree, it would be clearer to mention it already at this point. We will clarify this paragraph.

CoinJoin refers only to the idea to use a joint transaction with several inputs and outputs to do mixing. There are several ways to create such a transaction. CoinShuffle is one way, using a server and blind signatures is another.

The essential difference is the following:
Creating a CoinJoin with a server and blind signatures provides unlinkability (against the server) only if the participants connect to the server already in an anonymous way, e.g., by using Tor. On contrary, CoinShuffle uses more communication between the participants to provide unlikability by itself without any other third (trusted or untrusted) party, so without a central server and without relying on an anonymity network.

It's not really about DoS actually. A simple decentralized CoinJoin, i.e., without server but also not like CoinShuffle, would be sufficient to identify participants that want to disrupt the protocol. However, in such a approach, all participants can link input and output addresses, see "Don't the users learn which inputs match up to which outputs?" in the mentioned CoinJoin FAQ.


@ Sergio_Demian_Lerner:
I'm not sure if the required zero-knowledge proofs are efficient enough, but it is an interesting idea to allow everybody to mix addresses.

Your algorithm provides a way to agree on a random permutation such that nobody can influence the result. However, the participants learn the the resulting random permutation. In CoinShuffle, they don't learn the permutation.

If multiple entities - e.g. US NSA, SVR (Russian CBP), Chinese MSS, any private entities etc - are all attempting to de-anonymize mixing they will end up interfering with each other and help anonymity.  So it seems beneficial to encourage more than one group to attempt to de-anonymize mixing and not cooperate with each other.

Private entities/people using large balance addresses to avoid transaction fees could enable multiple groups to take part in each mix at no cost to them while increasing the number of parties in the mix and consequently increasing anonymity for everyone involved.

:-)

Another related question to help me confirm my understanding of the contribution of CoinShuffle:

Is the following algorithm be semantically equivalent to the algorithm presented in your paper?

Communication is done peer-to-peer using public-key, authenticated encryption. 'Broadcast' in this context means a player sends a message to all the players over these links.

Each player i (1 < i < N) does the following:
1 Generate a random permutation P_i of (1, 2, ..., N)
2 Broadcast H(P_i), where H is a collision resistance hash.
3 For all j != i, receive H(P_j) from player j
4 Broadcast P_i
5 For all j != i, receive P_j from player j and confirm the hash value
6 Calculate output list = P_1 (P_2 ( ...P_N (1, 2, ..., N)...)), broadcast, and agree on that value

Player 1 creates the join transaction with the output list, and the transaction is signed by all players. The transaction is broadcasted to the blockchain.

Please help me better understand exactly how CoinShuffle improves upon what already can be achieved with Coinjoin

The whitepaper mentions a weakness of CoinJoin and fails to point out that a more viable solution was proposed. The whitepaper states speaking of CoinJoin:
Then you go on to describe how unviable SMPC is.
While I agree that SMPC may be unviable, you seem to fail to mention another solution from the OP in CoinJoin thread:

in FAQ


Having established the fact that a centralized CoinJoin server will not learn the input/output mappings, is my assessment correct that the only advantage of CoinShuffle over CoinJoin is that
CoinShuffle can be implemented in a fully DEcentralized manner and still identify the DOSing party,
whereas CoinJoin can identify the DOSing party only when implemented with a CEntralized server?

Somebody asked for some other ways for anonymization: you can check my old paper on AppeCoin at
https://bitslog.wordpress.com/2014/04/24/appecoin-anonymous-cryptocurrency-draft/

It uses universal encryption, so everyone can mix every other peoples outputs without asking for permission, and it's impossible for dishonest mixers to prevent honest mixers from mixing with high anonymity set (at least of course if 99.9% of the outputs in the blockchain are controlled by the attacker).

BM, I have been exploring a strategy using N-way mixing, where by 'mixing' I mean the proper sense of creating separate transactions to exchange the coins. Whitepaper/ppt/git forthcoming.

The gist of the idea is:

(1) N players use a randomized Byzantine process to agree on a mixing specification, and then
(2) Execute multiple pairwise transactions atomically on the Bitcoin blockchain, ala TierNolan's atomic cross-chain transfer solution. This is an N-way, same-chain atomic transfer within Bitcoin (ie not cross chain).

Atomic Cross Chain Transfer discussion
https://bitcointalksearch.org/topic/alt-chains-and-atomic-transfers-193281
https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

Example:
Alice wants to mix 1 BTC
Bob wants to mix 2 BTC
Charlie wants to mix 3 BTC

In step 1, they decide on the following mix:
Alice --> Charlie 1BTC
Bob --> Charlie 2 BTC
Charlie --> Alice 1 BTC
Charlie --> Bob 2 BTC

In step 2, Alice executes her transfer to Charlie, Bob does his to Charlie, and Charlie does his to Alice and Bob. This is done in a way such that either all transfers succeed or they all fail.

I'm currently working on final steps of extending TierNolan's solution and a prototype.

Yes, this means the players pay for more transactions. One of the advantages is that the temporal locality of the transactions is loosened.

But accomplishing this within a client would be a trustless solution and a time saver, so using a 3rd party exchange wouldn't make sense when you could use an internal exchange/shuffle such as the case with Coinshuffle/Nxt.

right, this is why if you use an exchange that lies outside of eg. US jurisdiction, they are unlikely to comply with any requests to produce such logs.

This is likely the reason why the American/European currency authorities in particular are always vilifying the Chinese exchanges.  The Chinese exchanges are a doorway in and out of Bitcoin that they don't have any control over.

-bm

But then you're trusting the exchange not to keep logs that link your incoming tx to the outgoing one.

The fact is you can get fairly good anonymity simply by putting your coins on an exchange that doesn't require ID, and then transferring it out to an address that you have never used.  If you use Tor for all your interactions with the exchange website, then the coins are mostly untraceable.  Any exchange in the US, Singapore, most of Western Europe does not offer you anonymity.  If you issue the outgoing payment TX using Tor as well, the payment is mostly untraceable.  It's possible to automate all this in the wallet.

I don't know of any ideas that are not in this class of input/ouput mixing although it may be possible to implement something using cryptographic blinding.

-bm

I think that's the most popular as no one is about to change BTC core to include anonymity at a protocol level.  Do you have any other projects to review?  Input/Output can always be correlated but it would take QC power to do so.

the fact is, that even if you were to have 100% reliable and untraceable mixing of inputs/outputs the transactions are still temporally correlated.  As in: the transfers occur at the same time and thus are statistically related.

-bm

Has anyone explored other anonymity strategies aside from input/output mixing?

-bm

@wladston: thanks.

The obvious attack vector here is I operate many anonymity nodes, do all the mixing pretending as though I were many people(sybil attack).  Then I possess all the identity credentials and can de-anonymize the transactions.  One way to prevent this occurrence is some kind of rating system for the nodes, but this would be difficult to impose.  It seems this system is a step up from CoinJoin though.

-bm

@bluemeanie1, yes, every kind of mixing anonymization strategy will inevitably have this drawback.