CHIP 2025-01: Dandelion++ Integration for Bitcoin Cash

[ABLA]

1. Summary

   This CHIP proposes integrating Dandelion++ into Bitcoin Cash to strengthen transaction privacy and reduce traceability without requiring user reliance on extra tools like Tor or specialized wallets. By randomizing the path a transaction travels prior to full broadcast, Dandelion++ makes it significantly more difficult to pinpoint a transaction’s origin.

2. Motivation and Benefits

• Reduced Traceability

  • Dandelion++ first routes transactions (“Stem” phase) via randomized node paths. Only later does a node “Fluff” the transaction by announcing it broadly. This layered approach effectively obfuscates the transaction origin.

• Lightweight, Node-Level Solution

  • Operates at the networking layer, so no consensus changes or wallet modifications are needed. Users gain privacy benefits simply by running a Dandelion+±capable node.

• Complement to Existing Privacy Tools

  • Neutrino and Tor offer certain privacy improvements, but do not address entire-network correlation attacks. Dandelion++ tackles these root issues by ensuring transactions are well-masked before they propagate widely.

3. Technical Description

   3.1 Dandelion++ Overview

   - Stem Phase:
   

   • A newly created transaction is sent to one random peer, which relays it similarly, forming a random chain of “stem” hops.

   - Fluff Phase:
   

   • The node at the end of the stem path announces only the transaction hash (TxPoolInv). Nodes missing the transaction request it with RequestTxPoolTxs. This reduces redundant data transfers and further hides the origin.

     3.2 Comparison: Dandelion (BIP 156) vs. Dandelion++

The above table highlights how Dandelion++ improves upon the original Dandelion (BIP 156) as it was still exposed to various deanonymization attacks. Dandelion++ solved this by:

A. Randomized Relays: Transactions move through shuffled node paths during the Stem phase, making the true source harder to pinpoint.

B. Enhanced Network Topology: A more randomized structure prevents adversaries from easily mapping transaction flows.

C. Fail-Safe Mechanism: If any relay node fails, transactions automatically switch to the Fluff phase, avoiding long delays and preserving privacy.

4. Specification

• Node Configuration

  • A config flag such as enable_dandelionpp toggles this feature on/off.

  • Randomization parameters: e.g., refresh intervals for the anonymity graph.

• P2P Messages

  • TxPoolInv <hash_list>: Announces transaction IDs instead of sending full data.

  • RequestTxPoolTxs <hash_list>: Requests the corresponding transaction blobs.

• Stem Fail-Safe

  • If the stem path stalls or times out, the node fluffs the transaction directly to avoid indefinite delays.

5. Implementation Costs and Risks

• Development Overhead

  • Requires modifying node P2P logic to add new message types and random-forwarding rules.

• Partial Adoption

  • The anonymity set (and thus privacy) is stronger the more nodes participate. Early adopters see improvements, but full benefits emerge with wide adoption.

• Latency Considerations

  • Empirical Data: Simulations in the Dandelion++ whitepaper demonstrate that transaction propagation had low latency increases compared to traditional broadcasting.

  • Additional round trips for requesting missing transactions during the fluff phase are rare due to efficient inventory broadcasting.

6. Ongoing Costs and Risks

• Maintenance & Testing

  • Stochastic forwarding logic needs consistent integration testing to ensure correct behavior and performance.

• Advanced Adversaries

  • Even with Dandelion++, a global observer could attempt intersection attacks. Randomization, however, significantly raises the difficulty of tracing origins.

7. Current Implementations

• Reference Whitepaper & Proof of Concept:

  Full Article: Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees - Empirical data can be found here for testing

  3 pages summary to the point

  Grin’s Dandelion Implementation

• Bandwidth Issues Discussions:

  Monero #9334 Issue

8. Evaluation of Alternatives

• Status Quo

  • Simpler to maintain but offers less privacy. Leaves the network open to correlation attacks.

• Original Dandelion (BIP 156)

  • Provides some privacy improvements but lacks fail-safe mechanisms, advanced randomization, and robust adjacency mapping of Dandelion++.

• Tor-Only or I2P

  • More setup complexity and cannot alone prevent network-wide correlation attempts. Dandelion++ can complement these technologies.

9. Pros, Cons & Limitations

• Pros

  • Dandelion++ randomization reduces the likelihood of success.

  • No Consensus Impact : Doesn’t modify block validation rules. Security risk is minimal if carefully implemented.

  • As adoption grows, the protocol’s anonymity set improves, so earlier adopters benefit from subsequent uptake.

• Cons

  • As seen there is still some problem with the fluff phase that might cause a delay in node propagation this issue can be seen in the reference I provided before in Monero here

  • Cannot fully eliminate sophisticated global surveillance.

10. List of Major Stakeholders

• Full Node Implementations (BCHN, BCHD, others)

• Miners/Pools (transaction propagation concerns)

• Exchanges & Payment Processors (customer privacy)

• Wallet Providers (wallet changes not required, only node upgrade to the latest version)

• BCH User Community (general interest in improved privacy)

[tom]

Thank you for listing the full idea here.

I’m missing an important step, though. This is presented as a solution, but there is no research or facts pointing out that there is a problem.
Naturally everyone wants better privacy, but what is the current state and how much does such a proposal improve or maybe even worsen things. You can’t say without a baseline of current state.

To my experienced eye, this is a solution looking for a problem. A problem that doesn’t actually exist.

Full nodes being used to send a transaction to the wider network isn’t actually done by the majority of wallets. They all go via an intermediate, which already thus does obfuscation of origin.

Next, the p2p network itself is not a location-specific mesh. If your transaction is first seen in Europe, that means next to nothing because the mesh is intentionally setup between peers to have direct connections to far away places.

Next, just because a full node in a certain country broadcasts it (assuming you can find that out), doesn’t mean the user was there. But assume you can say its the same continent, then what value does that bring to an attacker knowing that person lives in a certain country, just like 20 million other people.

Maybe there are anonimity problems which need attention. I’m not aware of any, but I also don’t want to dismiss the idea outright.
But someone has to do the legwork to find out what the current state it, how easy it is for a random attacker to figure out where an actual transaction actually came from, and how much this actually affects anonimity.

The CHIP suggest doing work that may or may not be needed, and without baseline is impossible to measure success on.

That needs work.

[ABLA]

Thanks Tom for your feedback. Trying my best to make the idea into viable technical discussion. Back to your points below

@tom

You can’t say without a baseline of current state.

BCH transactions don’t include explicit IP addresses, but their propagation method can expose the originating node. There is studies showing that adversaries controlling multiple nodes can analyze transaction propagation to infer the source IP. The Dandelion++ paper explicitly highlights how a supernode monitored relayed traffic across P2P nodes, analyzing transaction spread patterns to deduce the source IP address. By linking this IP address to the sender’s pseudonym, third parties can deanonymize users and track subsequent transactions, even if new public keys are used.

@tom

Full nodes being used to send a transaction to the wider network isn’t actually done by the majority of wallets. They all go via an intermediate, which already thus does obfuscation of origin.

Next, the p2p network itself is not a location-specific mesh. If your transaction is first seen in Europe, that means next to nothing because the mesh is intentionally setup between peers to have direct connections to far away places.

It’s true that many wallets use intermediate nodes, adding a layer of obfuscation. However, this doesn’t fully mitigate the risk. Adversaries can still perform timing analysis and exploit the network’s structure to trace transactions. The non-location-specific mesh of the P2P network does add complexity, but it doesn’t eliminate the possibility of tracing, especially for sophisticated attackers they have KYC coins linking mapping and pattern of certain transactions all these tools make tracing easier.

@tom

Maybe there are anonimity problems that need attention. I’m not aware of any, but I also don’t want to dismiss the idea outright.
But someone has to do the legwork to find out what the current state it, how easy it is for a random attacker to figure out where an actual transaction actually came from, and how much this actually affects anonimity.

All I am saying is that randomizing the path and delaying the broadcast, it reduces the likelihood of successful tracing. While no solution offers absolute anonymity, Dandelion++ provides a measurable improvement over the current state. Empirical data suggests that Dandelion++ can reduce the probability of successful tracing attacks, enhancing user privacy without requiring significant changes to existing infrastructure.

The question here is this is the most efficient method for reducing the possibilities of tracing? Actually this debate has started from 6 years ago in Bitcoin until now and some projects have adopted it with different improved configurations so we can do the same thing here by improving the existing configuration. You can refer to this long debate here

I hope i have covered all the questions:)

[tom]

@ABLA

BCH transactions don’t include explicit IP addresses, but their propagation method can expose the originating node. There is studies showing that adversaries controlling multiple nodes can analyze transaction propagation to infer the source IP.

This is factually false,
I mean, sure, some people wrote papers. But they clearly had a conclusion written before they started the research. It is full of holes and assumptions that are false.
So, no, there is no way to infer the source IP. A LOT of people have historically been claiming there is, but what all of them have in common is that the have no clue how stuff actually is working and implemented.

So, I repeat, without having an actual repeatable and measurable indication of how bad things are, you can’t state to improve things.

@ABLA

However, this doesn’t fully mitigate the risk.
[snip]
The non-location-specific mesh of the P2P network does add complexity, but it doesn’t eliminate the possibility of tracing

You are assuming there is a problem. Without doing any work showing the actual problem you say this solves. I don’t believe the problem exists. Try to convince me with TECHNICAL means.
I can’t back any scheme that purports to be a solution but lacks any indication of what it is a solution to.

@ABLA

Dandelion++ provides a measurable improvement over the current state.

No, it can’t. Measurable means you need to have a baseline, you don’t have one so you can’t see improvements. You might very well be optimizing something that is entirely irrelevant.

[ABLA]

@tom

This is factually false,
I mean, sure, some people wrote papers. But they clearly had a conclusion written before they started the research. It is full of holes and assumptions that are false.
So, no, there is no way to infer the source IP. A LOT of people have historically been claiming there is, but what all of them have in common is that the have no clue how stuff actually is working and implemented. You are assuming there is a problem. Without doing any work showing the actual problem you say this solves. I don’t believe the problem exists. Try to convince me with TECHNICAL means. I can’t back any scheme that purports to be a solution but lacks any indication of what it is a solution to

There is reputable source for this tom for example this article by Fanti and Viswanath analyzes how Bitcoin’s transaction dissemination protocols enable user deanonymization. Anonymity Properties of the Bitcoin P2P Network

So by saying Timing Analysis Attacks where adversary controlling geographically distributed nodes can observe transaction propagation times to correlate the origin, Flooding Attacks where adversaries can temporarily overload the network to isolate and monitor specific nodes. Or any methods published or exploited by chainalysis. I acknowledge your point these attack vectors are either theoretical or exploited in another cryptocurrency and lack data related to BCH specifically however there is wide range of studies that discuss this in crypto space such as bitcoin and Monero and there is recent incident with Monero being tracked using same methods full video of how Chainalysis doing it here.

So how can seeing these problems out there is not relevant to bch or raising concerns especially with BCH using the same bitcoin technology?

[tom]

@ABLA

So by saying Timing Analysis Attacks where adversary controlling geographically distributed nodes can observe transaction propagation times to correlate the origin, Flooding Attacks where adversaries can temporarily overload the network to isolate and monitor specific nodes. Or any methods published or exploited by chainalysis.

Practically all fail on the same premise. Even the introduction paragrap gives away their intent: they have written their conclusions before they started their research. The approaches tend to skip over clear false assumptions and they just use estimations, models and other such things that are frankly just admitting they are making this up as they go along.
This isn’t research, this is writing fancy looking papers that spread FUD.

And you’re falling for it, which probably means you don’t actually understand it and trust them based on “reputable source”.

Do your own research, understand the problems you’re trying to solve.

And, I repeat it now for the 3rd time. Present TECHNICAL arguments. I don’t really do “trust me” arguments.

[bitjson]

I’ve been reviewing BCH’s privacy picture:

Network-Layer Privacy on Bitcoin Cash

Hi all, In anticipation of future Zero-Knowledge Proof (ZKP) Bitcoin Cash covenants, I’ve been reviewing how to make implementation in wallets as practical and private as possible. I expect now that many ZKP covenant systems can be fully supported by generalized “wallet engine” infrastructure, such that software which supports wallet templates will be able to simply import and use ZKP covenant wallet templates (create a wallet, scan for matching UTXOs, and deposit, transfer within, and withdra…

I’d love to see BCH implement a deniable broadcast solution. @ABLA have you reviewed Clover? From above link:

@bitjson

In my opinion, Clover is a clear improvement over Dandelion++ – it’s simpler, faster, more byte efficient, has fewer pitfalls, and offers overall better privacy to all network participants.

In short: nodes add a new PTX (“proxy TX”) message type equivalent to the TX type, but quietly relayed based on some simple rules such that the network first “hears” it via the standard INV diffusion after a few hops.

If you know of any advantages to Dandelion++ vs. Clover, I’d be interested in hearing them!

[ABLA]

Thank you Jason, for the opportunity to let me see Clover whitepaper. Overall, I find Clover to be simpler and generally a better choice. However, from my reading, it has a key limitation imo and correct me if i am wrong. it requires checking INV messages from outbound peers. This introduces potential weaknesses compared to Dandelion++, which offers several advantages:

1. Theoretical robustness against stronger adversaries, backed by formal guarantees.
2. Simpler operation without the need to check INV messages.
3. Greater maturity due to longer research exposure, potentially reducing unknown risks.
4. Graph-based resilience, which may handle diverse network conditions better, especially against active observers.

My main concern with Clover is about its resistance to active adversaries. While its linear proxy chain offers solid privacy against passive observers, its predictability (a fixed chain length) could be exploited by active adversaries who control multiple nodes along the path. Therefore, how well does Clover hold up against Byzantine attackers who could disrupt the proxy chain or infer the source through network manipulation? It seems optimized more for protection against passive eavesdroppers rather than active adversaries. Could this be a significant limitation?

[bitjson]

To be honest, I think the more confident language style of the Dandelion++ paper is priming AI models to really fail in comparing it against Clover.

The LLMs also seem to really be latching on to a few casual mentions by Monero researchers indicating that Clover seems better, but they want to wait for more analysis before advocating for a switch from Dandelion++ to Clover. Of course, Monero has already invested in implementing Dandelion++, so they’re in quite a different position than us WRT expected value of now implementing Clover.

@ABLA

1. Theoretical robustness against stronger adversaries, backed by formal guarantees.

I know that LLMs currently say this, but I think it’s hallucinated.

Clover and Dandelion++ simply aren’t that different, and it’s obvious that neither protocol is sufficient to protect against the most powerful network adversaries (for that we’d need widely deployed encryption + a more mixnet-like approach, at significant bandwidth efficiency loss). However, it’s reasonable to consider that out of scope: users needing global-dragnet resistance can always broadcast over Tor.

This looks like a good paper reviewing active attacks against Dandelion, Dandelion++, and Lightning Network: https://arxiv.org/pdf/2201.11860 – in fact, though they (for some reason) don’t review Clover, they recommend Clover’s behavior as a solution to weakness in Dandelion:

Since the privacy subgraph is derived from the bitcoin graph, which is itself 16-regular, this is the maximum degree that any node in the privacy subgraph can have. Thus, we constructed a
16-regular graph of 1000 nodes and computed the entropy as described in Sec. IV-B. We observed that with 10% adversary nodes, the median entropy value was 7 bit (equivalent to 128
possible senders) in the 16-regular privacy graph and 4.5 bit (23 possible senders) in the 4-regular graph.

Thus, to achieve better anonymity, hop-by-hop schemes like Dandelion should use the 16-regular bitcoin graph as-is for the privacy subgraph instead of restricting it to a line or 4-regular graph. Notably, in this case, the adversary already knows the privacy subgraph without the help of any additional mechanisms (as described in Sec. VII-A), but is still less able to effectively deanonymize transaction originators.

[…]

For instance, our analysis of real Lightning Network snapshots reveals that, by colluding with a few (e.g., 1%) influential nodes, an adversary can fully deanonymize about 50% of total transactions in the network. Similarly, Dandelion and Dandelion++ provide a low median entropy of 3 and 5 bit, respectively, when 20% of the nodes are adversarial.

@ABLA

• Simpler operation without the need to check INV messages.

LLMs hallucinating again. Clover is simpler, and it isn’t close.

Also, Dandelion++ does require “checking” INV messages, it just uses a more naive approach (again, more vulnerable to active attacks). Clover timeouts are triggered if fewer than 50% of outbound peers have advertised the transaction in INV messages. Dandelion++ simply triggers if any peer has advertised the transaction.

@ABLA

3. Greater maturity due to longer research exposure, potentially reducing unknown risks.

This isn’t a consensus upgrade: node implementations can iterate at will. They don’t even have to wait for annual upgrades.

Re risks: bugs and denial of service vectors are a real concern, but it would be very hard for either Dandelion++ or Clover to have an overall negative impact on network-layer privacy: right now we have approximately none.

@ABLA

1. Graph-based resilience, which may handle diverse network conditions better, especially against active observers.

I’m afraid I can’t parse this. Can you elaborate?

@ABLA

My main concern with Clover is about its resistance to active adversaries.

Intuitively, I’d expect Clover to have better and less luck-based resistance to active adversaries, and that’s also what the Clover paper indicates was their experimental result.

@ABLA

While its linear proxy chain offers solid privacy against passive observers, its predictability (a fixed chain length) could be exploited by active adversaries who control multiple nodes along the path.

Chain length isn’t fixed (it’s a random walk that ends probabilistically)

@ABLA

Therefore, how well does Clover hold up against Byzantine attackers who could disrupt the proxy chain or infer the source through network manipulation?

Can’t parse, can you elaborate?

@ABLA

It seems optimized more for protection against passive eavesdroppers rather than active adversaries. Could this be a significant limitation?

No, the Clover paper’s abstract just mentions that keyword. Dandelion++ appears to be (slightly) more vulnerable to active adversaries than Clover.

[ABLA]

@bitjson

Can’t parse, can you elaborate?

I was talking about the recent attacks we have seen when a lot of wallet and people use malicious nodes especially when large number of connected and active nodes is used by chain analysis.

But thanks for better clarification. i have used 3 different research model for comparison previously in tables to detect hallucination but it seems unreliable, therefore i will only talk about the reference of clover. After seeing clover results i have noticed better precision & more randomness from the graph result so it would be better choice imo i think we should drop this alternative and discuss clover in the new topic you have made unless anyone has something new to add.

@bitjson

This looks like a good paper reviewing active attacks against Dandelion, Dandelion++, and Lightning Network: https://arxiv.org/pdf/2201.11860 – in fact, though they (for some reason) don’t review Clover, they recommend Clover’s behavior as a solution to weakness in Dandelion:

I think you should add also this references to the main topic it is really good one