even when the number of malicious nodes is linear in the number of total nodes in the network.
Based on the insight that symmetric message propagation makes deanonymization easier,
it introduces a probability for nodes to simply forward the message to one select relay node
instead of disseminating messages as per usual relay operation.
## Background and Motivation
[Waku Relay](/spec/11/), offers privacy, pseudonymity, and a first layer of anonymity protection by design.
Being a modular protocol family [Waku v2](/spec/10/)
offers features that inherently carry trade-offs as separate building blocks.
Anonymity protection is such a feature.
The [Anonymity Trilemma](https://freedom.cs.purdue.edu/projects/trilemma.html)
states that an anonymous communication network can only have two out of
low bandwidth consumption, low latency, and strong anonymity.
Even when choosing low bandwidth and low latency, which is the trade-off that basic Waku Relay takes,
better anonymity properties (even though not strong per definition) can be achieved by sacrificing some of the efficiency properties.
44/WAKU2-DANDELION specifies one such technique, and aims at gaining the best "bang for the buck"
in terms of efficiency paid for anonymity gain.
44/WAKU2-DANDELION is based on [Dandelion](https://arxiv.org/abs/1701.04439)
and [Dandelion++](https://arxiv.org/abs/1805.11060).
Dandelion is a message spreading method, which, compared to other methods,
increases the uncertainty of an attacker when trying to link messages to senders.
Libp2p gossipsub aims at spanning a [d-regular graph](https://en.wikipedia.org/wiki/Regular_graph) topology, with d=6 as the [default value](/spec/29/#gossipsub-v10-parameters).
Messages are forwarded within this (expected) symmetric topology,
which reduces uncertainty when trying to link messages to senders.
Dandelion breaks this symmetry by subdividing message spreading into a "stem" and a "fluff" phase.
In the "stem" phase, the message is sent to a single select relay node.
With a certain probability, this message is relayed further on the "stem",
or enters the fluff phase.
On the stem, messages are relayed to single peers, respectively,
while in fluff phase, messages are spread as per usual relay operation (optionally augmented by random delays to further reduce symmetry).
The graph spanned by stem connections is referred to as the anonymity graph.
Note: This is an early raw version of the specification.
It does not strictly follow the formally evaluated Dandelion++ paper,
as we want to experiment with relaxing (and strengthening) certain model properties.
In specific, we aim at a version that has tighter latency bounds.
[Further research](https://arxiv.org/pdf/2201.11860.pdf) suggests that Dandelion++'s design choices are not optimal,
which further assures that tweaking design choices makes sense.
We will refine design decisions in future versions of this specification.
Further information on Waku anonymity may be found in our [Waku Privacy and Anonymity Analysis](https://vac.dev/wakuv2-relay-anon).
## Theory and Functioning
44/WAKU2-DANDELION can be seen as an anonymity enhancing add-on to [Waku Relay](https://rfc.vac.dev/spec/11/) message dissemination,
which is based on [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
44/WAKU2-DANDELION subdivides message dissemination into a "stem" and a "fluff" phase.
This specification is mainly concerned with specifying the stem phase.
The fluff phase corresponds to [Waku Relay](/spec/11/),
with optional fluff phase augmentations such as random delays.
Adding random delay in the fluff phase further reduces symmetry in dissemination patterns and
introduces more uncertainty for the attacker.
Specifying fluff phase augmentations is out of scope for this document.
*Note:
We plan to add a separate specification for fluff phase augmentations.
We envision stem and fluff phase as abstract concepts.
The Dandelion stem and fluff phases instantiate these concepts.
in which the attacker controls a certain percentage of nodes in the network.
44/WAKU2-DANDELION provides significant mitigation against mass deanonymization
even if the attacker knows the network topology, i.e. the anonymity graph and the relay mesh graph.
Mitigation in stronger models, including the *active scaling multi-node* model, is weak.
We will elaborate on this in future versions of this document.
44/WAKU2-DANDELION does not protect against targeted deanonymization attacks.
#### Non-Dandelion Peers
Stem relays receiving messages can either be in stem state or in fluff state themselves.
They might also not support 44/WAKU2-DANDELION,
and interpret the message as classical [19/WAKU2-LIGHTPUSH](/spec/19/),
which effectively makes them act as fluff state relays.
While such peers lower the overall anonymity properties,
the [Dandelion++ paper](https://arxiv.org/abs/1805.11060)
showed that including those peers yields more anonymity compared to excluding these peers.
### Future Analysis
The following discusses potential relaxations in favour of reduced latency,
as well as their impact on anonymity.
This is still work in progress and will be elaborated on in future versions of this document.
Generally, there are several design choices to be made for the stem phase of a Dandelion-based specification:
1) the probability of continuing the stem phase, which determines the expected stem lengh,
2) the out degree in the stem phase, which set to 1 in this document (also in the Dandelion papers),
3) the rate of re-selecting stem relays among all gossipsub mesh peers (for a given pubsub topic), and
4) the mapping of incoming connections to outgoing connections.
#### Bound Stem Length
Choosing $q = 0.2$, 44/WAKU2-DANDELION has an expected stem length of 5 hops,
Assuming $100ms$ added delay per hop, the stem phase adds around 500ms delay on average.
There is a possibility for the stem to grow longer,
but some applications need tighter bounds on latency.
While fixing the stem length would yield tighter latency bounds,
it also reduces anonymity properties.
A fixed stem length requires the message to carry information about the remaining stem length.
This information reduces the uncertainty of attackers
when calculating the probability distribution assigning each node a probability for having sent a specific message.
We will quantify the resulting loss of anonymity in future versions of this document.
#### Stem Relay Selection
In its current version, 44/WAKU2-DANDELION nodes default to fluff state
if the random stem relay selection yields at least one peer that does not support [19/WAKU2-LIGHTPUSH](/spec/19/) (which is the stem protocol used in 44/WAKU2-DANDELION).
If nodes would reselect peers until they find peers supporting [19/WAKU2-LIGHTPUSH](/spec/19/),
malicious nodes would get an advantage if a significant number of honest nodes would not support [19/WAKU2-LIGHTPUSH](/spec/19/).
Even though this causes messages to enter fluff phase earlier,
we choose the trade-off in favour of protocol stability and sacrifice a bit of anonymity.
(We will look into improving this in future versions of this document.)
#### Random Delay in Fluff Phase
[Dandelion](https://arxiv.org/abs/1701.04439) and [Dandelion++](https://arxiv.org/abs/1805.11060)
assume adding random delays in the fluff phase as they build on Bitcoin diffusion.
44/WAKU2-DANDELION (in its current state) allows for zero delay in the fluff phase and outsources fluff augmentations to dedicated specifications.
While this lowers anonymity properties, it allows making Dandelion an opt-in solution in a given network.
Nodes that do not want to use Dandelion do not experience any latency increase.
We will quantify and analyse this in future versions of this specification.
We plan to add a separate fluff augmentation specification that will introduce random delays.
Optimal delay times depend on the message frequency and patterns.
This delay fluff augmentation specification will be oblivious to the actual message content,
because Waku Dandelion specifications add anonymity on the routing layer.
Still, it is important to note that [Waku2 messages](https://rfc.vac.dev/spec/14/#payloads) (in their current version) carry an originator timestamp,
which works against fluff phase random delays.
An analysis of the benefits of this timestamp versus anonymity risks is on our roadmap.
By adding a delay, the fluff phase modifies the behaviour of [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md),
which Waku Relay builds upon.
Note: Introducing random delays can have a negative effect on
