You could do the same thing with the current Dandelion++ impl, knowing that stem txs can flow randomly from any node to an adjacent outbound peer.
Yes, you are right, this is already possible, but the impact today might be less. I.e. today, if I understand the topology of how nodes are connected, then I can only assign a probability that a certain node will be stemming or fluffing (based on DANDELION_STEM_PROBABILITY
).
On the other hand, with this proposal, if I understand the topology, then in every epoch I will know which node will be fluffing, and which nodes most certainly will not be fluffing. Granted, your proposal of randomly choosing a heavier weighted node to stem to mitigates this somewhat. I don’t know how much or what the implications of this are.
All in all, I personally like the ideas and directions here, combined with what’s proposed in Dandelion++ Thoughts on Timers/Scheduling · Issue #2880 · mimblewimble/grin · GitHub of using blocks as timers.
We’re are already making considerable deviations from the D++ spec today in our implementation, which leads to some attacks being possible.
The direction of this proposal allows nodes (and passive adversaries) to deterministically understand where fluffing will occur on the network and in which direction transactions will flow during an epoch. It’s not clear to me how these changes would lead to particularly worse privacy than what we have today. I am not convinced we today are able to adequately protect against an adversary that monitors the entire p2p network in any case. The proposed changes do not impact this as far as I can tell.
I do see however that with this proposal, our design would become more simpler and elegant, less error-prone, and lead to increased pre-fluff aggregation. Which is good.
It would be nice to get other people’s thoughts on the matter.
@rodarmor do you have thoughts or anything to add? It was your ideas above that originally put us on this path and inspired some of the thinking after all. For example, what do you think of @antioch’s suggestion to use
H(ip_address|block_hash)
every n
blocks
over your proposed
relay_weight = blake2b(node_id || epoch_id)