← Back to team overview

mimblewimble team mailing list archive

Re: Integrating ValueShuffle into the Mimblewimble protocol


Hi Luna,

You found yourself a very nice name, congratulations and welcome. Thank you for sharing that Chaum paper, always an enjoyable read.

I have to admit my current understanding of ValueShuffle goes barely further than "CoinShuffle with CT", and I'll need a little more time to go through the DiceMix paper and CoinShuffle pseudocode. However, I'm also very supportive of the idea, especially as transaction pool cut-through stays problematic (so far).

As Andrew predicted (he's starting to know me well), I'll first say there's still a lot we need to work on and figure out but if you're willing to work on ValueShuffle in Grin, I'd be very happy to help. The first thing to clear may be a good Schnorr signature implementation, which would be generally very beneficial (hint).

- Igno

-------- Original Message --------
Subject: [Mimblewimble] Integrating ValueShuffle into the Mimblewimble protocol
Local Time: May 27, 2017 9:47 PM
UTC Time: May 28, 2017 4:47 AM
From: luna-loony-lovegood@xxxxxxxxxxxxxx
To: mimblewimble@xxxxxxxxxxxxxxxxxxx <mimblewimble@xxxxxxxxxxxxxxxxxxx>

Hello Mimblewimble mailing list,

ValueShuffle[1] is a CoinJoin implementation that is compatible with CT and
will complete Mimblewimble's privacy by improving untraceability with DC-nets[2].

An open question in Mimblewimble is how users will aggregate their transactions
and ValueShuffle is a novel approach for p2p communication between users for
shuffling transaction inputs, which conveniently aggregates all participants
inputs and outputs into a single transaction and a single schnorr signature.

Things to take into consideration:

-Low liqudity. If transaction volume is low, then lone transactions will need to
wait for additional transactions to be relayed for ValueShuffle round execution.
In a bitcoin sidechain, for example, liquidity is unlikely to be an issue.

-Some users may want to do multiple rounds of ValueShuffle over several blocks
for additional untraceability. I foresee each 'round' costing a dynamic fee to
defend against DoS attacks, otherwise an attacker will be able to freely DoS
node tx pools with minimal cost. Users should be encouraged to do multiple
rounds of ValueShuffle to provide liquidity for other users in future blocks,
decreasing ValueShuffle wait times for everyone in the network. As far as I know
ValueShuffle does not currently allow for transactions to persist through
multiple rounds spanning multiple blocks, so the specification will need to be
tweaked so a user is not deemed malicious and get removed from a ValueShuffle

-Sybil attacks are always a concern, but allowing users to do multiple rounds of
ValueShuffle should help mitigate these attacks. In the event of a successful
sybil attack on a user in a round of ValueShuffle, Mimblewimble will still hide
transaction amounts and enable payee anonymity, so users can be assured their
privacy is still (mostly) intact, only sacrificing untraceability. If there is
even a single other honest participant in a round where a sybil attack is
present then an attacker has a 1/N chance of guessing the corresponding inputs
and outputs among N honest participants in a round.

I am interested in what this mailing list thinks of integrating ValueShuffle
into the base layer of Mimblewimble. ValueShuffle provides Mimblewimble
untraceability and a protocol for transaction aggregation among users of the
network without compromising on Mimblewimble's goals of simplicity and

~Luna Lovegood

[1] https://people.mmci.uni-saarland.de/~truffing/papers/valueshuffle.pdf

[2] https://users.ece.cmu.edu/~adrian/731-sp04/readings/dcnets.html

Follow ups