Monero Developers Investigate Possible Dandelion++ Transaction Privacy Leak

A Monero Dandelion++ privacy report describes how a node might reveal that it stores a transaction before broadcasting it. Issue #11690, opened by Ap4sh on November 6, 2026, describes a possible Dandelion++ privacy leak involving conflicting key images and different connection-handling decisions.

The report traces source code. The author has not supplied a running-network reproduction. Our review found the relevant branches in released code, but we have not reproduced the behavior over a network. The sources reviewed do not establish real-world exploitation or confirmed deanonymization.

Research cutoff: November 8, 2026, 03:10 UTC.

What Dandelion++ protects

Dandelion++ changes how nodes initially relay a transaction. During the stem phase, it follows a narrow relay path instead of immediately spreading to every connected peer. During fluff, it spreads more widely. This makes the first node an observer hears from a less reliable clue to the transaction's origin.

Monero announced the implementation in April 2020. This protection concerns network propagation. Separate cryptographic mechanisms conceal amounts and obscure which output a transaction spends.

Stem limits initial distribution. Fluff spreads the transaction more widely. A node along either path need not be its creator.

The suspected information leak

A node's transaction pool holds transactions awaiting confirmation, including transactions not yet broadcast publicly. The report concerns whether a peer can infer the presence of one of those non-broadcast transactions.

A key image lets Monero detect attempts to spend the same output again without identifying the real spent output among its ring members. Conflicting transactions can contain the same key image. The node rejects the conflict and applies a separate rule about disconnecting the peer that sent it.

In the inspected transaction-pool code, a collision with an existing pool entry can stop processing before later verification. That branch sets m_no_drop_offense, which tells the networking layer not to disconnect the peer for this rejection.

The P2P handler distinguishes that outcome from a verification failure that does warrant disconnection. Ap4sh argues that this difference could disclose pool membership while a transaction remains in the stem phase. The node still rejects the transaction, so this flag cannot make an invalid transaction spendable.

Prerequisites and limits

The scenario assumes a peer has already seen the stem transaction and knows its key image. It also needs a connection to the target node before wider broadcast makes the information public. Other validation and connection-state checks still apply.

Even if testing confirms the signal, finding a transaction in a node's pool would not prove that node created it. An intermediary may have received and stored the same transaction. The observation would not by itself expose a sender address, recipient address, payment amount or private key.

This differs from the Tor and I2P synchronization-height report. Its proposed signal comes from pool handling, not synchronization progress. The inspected handler also distinguishes public and anonymous network zones, so this report does not establish identical effects for every Tor or I2P configuration.

Developer response and patch status

On November 7, maintainer selsta said he preferred to address the issue separately from PR #11499. His response acknowledges the report without confirming a successful network test or the scale of its privacy impact.

The handling reflects deliberate tradeoffs. PR #9218 avoids disconnecting honest peers over pool conflicts. PR #11091 moves expensive checks after the no-drop rejection checks. A fix must consider connection reliability and validation cost alongside information disclosure.

The latest stable release at the cutoff was v0.18.5.4, published October 17. Source inspection found the reported ordering in both v0.18.5.4 and v0.18.5.3. That identifies releases needing runtime evaluation, not a confirmed exploitable-version range. The first affected version remains undetermined.

PR #11638 merged on November 7, but its change concerns double-spend metadata in another path. It does not remove the connection-handling distinction. We found no dedicated merged fix or stable release resolving #11690 at the cutoff.

What would establish the risk

The missing evidence is a controlled test demonstrating different peer-visible outcomes with and without the non-broadcast pool entry. Reliable detection, timing constraints and any connection to transaction origin would then need separate evaluation.

The issue also cites an automated source review. That review states that it did not execute a reproduction. It adds analysis, not independent network confirmation.

For operators, this report does not justify disabling Dandelion++ or installing an unreviewed branch. Follow the upstream issue and official releases for a tested correction. The available evidence provides no verified configuration workaround.