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

  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.
  1. 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.

  1. 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.
  1. 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.

  1. 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.
  1. Current Implementations
  1. 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.
  1. 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.

  1. 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)

3 Likes

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.

1 Like

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

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.

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.

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:)

1 Like

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.

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.

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.

1 Like

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?

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.