Dandelion++ (Privacy Proposal)

There have been numerous discussions in the community Discord over the past several months regarding base-layer privacy and the security of Mimblewimble/TariScript, as other implementations of Mimblewimble have suffered from transaction linkability via malicious sniffer nodes.

Upon further investigation, it would seem that Tari utilizes a more typical gossip protocol/flooding to propagate transactions across the network as opposed to one of the various Dandelion protocols common in other Mimblewimble-based coins like Grin/Beam.

As it currently stands Tari effectively outsources its network-privacy threat model to the Tor network. If the Tor circuit is compromised (which is historically proven to be possible), then an observer would be able to see which Tari node broadcast a particular transaction, and Tari’s privacy fails.

I would like to propose adding Dandelion++ to Tari.

Dandelion++ in conjunction with Tor would harden Tari’s privacy with minimal tradeoffs.

3 Likes

I agree, dandelion has proven to be effective for many years in Grin. I think it would be a great privacy addition.


Dandelion was disabled to get TariScript to work. If you cut-through outputs, you can never verify the script on them, which would allow you to spend an output with an invalid script.

Grin only has a single “spend” key per output. This is the commitment mask on the Pedersen commitment — the k in v*H + k*G. Tari has this spend key as well, but in normal transactions this k is shared between sender and receiver. In Tari we have a second spend key called the script key, which is used to sign the script signature. This key unlocks the script.

You can read more here: RFC-0201: TariScript - The Tari Network: RFC library

1 Like

Thank you for taking the time to explain @blackwolfsa that makes sense.

Would I then be correct in my assumption that PayJoin/P2EP could solve this issue utilizing the onesided + interactive combined addresses? If so, why doesn’t Tari Universe use these (combined addresses) by default? Was it just a UX choice because it’s a mining (and mobile) app?

Also, doesn’t the L2/Ootle solve this issue via Cerberus/sharding? If transactions aren’t being broadcast to the entire network of validators by design then a sniffer node shouldn’t be able to discover the transaction graph.

It seems like transaction amounts and participants are hidden, the Ootle isn’t susceptible to the same type of sniffer attacks, and there’s no “peg out” due to the one-way turbine, so what is it about the L2/Ootle (and transacting in “native” TARI/XTR) that makes it functionally inferior in privacy to Monero/Zcash?

Using a traditional interactive transaction in MW terms wont stop the invalid script.
Even if you have an interactive transaction where only the recipient knows the blinding factor of the pedersen commitment, that output could still have a script where its timelocked, and if we implement Dandelion, it could allow the recipient to bypass the timelock.

This also does not touch on the fact that interactive transactions are terrible for user expieriance. Getting two devices to talk to each other without a central server, espcially a mobile device, is soo unreliable. There is a reason we moved to one-sided transactions by default. Infact the current wallets dont even support interactive atm.

1 Like