Introducing CoinShuffle++: Enhancements for Peer-to-Peer Coin Mixing

Hey everyone, I'm Tim from Saarland University, and along with Pedro and Aniket from Purdue, we’re excited to share our updated project: CoinShuffle++. It's a new and improved version of our original CoinShuffle, aimed at better privacy for Bitcoin users.

Sounds cool! Any way I can help out? I'm a PHP and JS dev.

This looks really promising, thanks for sharing! About the protocol's ability to identify bad actors, it seems like a double-edged sword. If a few participants decide to coordinate, could that compromise the anonymity? What do you think?

Yeah, that's the concern. Blacklisting certain outputs could help, but it feels basic.

Got it now, the protocol aims to wrap up things for honest users even with a few bad apples. If you've got one troublemaker among a small group, it still stands a chance to work.

Right! I meant to bring up the previous discussions we had on this. My understanding was a bit off at first, but I'm following now.

Funny you mention that, jl777 was onto something similar months back. My past critiques still stand. Not having read your paper, but seeing the notation about rounds with malicious peers raises a flag for me.

You’re hitting on key issues here!

Following this thread. Grateful for the work you're doing on enhancing privacy!

Just brainstorming...but what if we tackle the problem of a misbehaving node by completing every combo of participants? You know, like doing multiple coinjoins at once to cover all bases?

Exactly what the protocol aims for! If you have five users and one acts up, the other four can still finish with some extra rounds.

Nice to hear!

Quick question, is CoinShuffle still active or is it considered outdated? Just trying to get the lay of the land.

Not the author, but I’ve skimmed the thread. Tim here is one of the original creators, and he’s laid out the differences in the new paper.

In the step KE, how do you determine NPK[] before getting input from p?

Good point! That part needed fixing. It should actually be VK[] instead of NPK[]. Better safe than sorry when hashing.

A couple of thoughts: 1. Why do we need sid' if we're using it already in the hash? Seems redundant. 2. I’m curious about the commitment phase. How does a malicious peer profit from not including the DC-PAD?

Tim already tackled some of this. We include peer views in the hash to avoid mishaps. Commitments are key for ensuring we finish the process.

Just read through your paper. Forgive my skimming! But how do you plan to prevent that attack where subsets to inputs and outputs match? Seems tricky.

Great catch! We ask users to contribute equally in the mixing, which does limit flexibility. But it's essential for security. Can you clarify what part you’re worried about?