Dandelion++ Rewrite #2628
Dandelion++ Rewrite #2628
Conversation
antiochp
force-pushed
the
dandelion_rewrite
branch
from
58fdadb
to
08046f7
Compare
antiochp
force-pushed
the
dandelion_rewrite
branch
from
f5d1dad
to
c844177
Compare
so we fluff final outstanding txs
aggressively aggregate when we can
antiochp
force-pushed
the
dandelion_rewrite
branch
from
c844177
to
69ad669
Compare
antiochp
changed the title
|
Default Dandelion config - |
|
This is from a node running on mainnet - This was an "in the wild" tx aggregation via Dandelion++ which I don't think we have seen very often with the existing Dandelion impl. 2 txs arrived within 30s of each other on this node which was in a "fluff" epoch. Note: Node was running in "fluff" mode 100% of the time here as part of my testing (normally in stem mode 90% of the time). So this node is basically always acting as a "sink" for stem txs, collecting them and periodically fluffing them. Given we are "fluff" all the time, we do still see a decent number of actual tx aggregation, and not just fluffing individual txs (note the kernel counts > 1) - |
|
If anybody does want to test this out, feel free to set |
|
@antiochp is the node able to set its own fluff/stem status? Or was that just something for testing here, where a node was set to “100% fluff mode”? Could nodes decide on this individually in the wild? If so, is that a problem? Could it be used to attack the network somehow? By deploying lots of "100% fluff, never broadcast" nodes that “drains” all the transactions? I know we use embargo timers, but would that then lead to the originating nodes sending out the transactions at expiry of embargo? |
|
@lehnberg nodes can choose any value between 0% and 100% in terms of stem probability. What you are suggesting is not limited to Dandelion in any way. I could run a modified node that simply did not broadcast any txs (or blocks for that matter). There's nothing we could do to prevent that. |
|
Understood. In such an event and at the embargo timer expiration, would it lead to the originator broadcasting their transaction? Or could it plausibly also be other nodes doing that? Given that the originator will have the shortest time left on their embargo timer, it would be them doing that, right? |
|
There's some randomness in terms of the timer length - so even though the originator starts their timer first its still reasonably random who would actually broadcast. |
|
Note: 40 lines of code removed! 🚀 |
|
ok merging this into 1.1.0 🤞 |
|
@antiochp does https://github.com/mimblewimble/grin/blob/master/doc/dandelion/dandelion.md also need to get updated? |
|
Indeed @Kargakis this doc reflects the previous version of Dandelion. |
|
Yes it does and should. I totally forgot about that. I'll open an issue to track this. |
|
Note my |
|
Thinking about this some more (belatedly), I'm becoming less convinced of the privacy benefits of aggregation before fluffing. With the probability of a node being in stem mode set to 90% and fluff mode set to 10%, it implies that only 1/10th of the nodes on the network will be fluff nodes, i.e. "sinks" where transactions become aggregated. If this is the case, deploying malicious surveillance nodes with fluff mode = 100% will have a relatively high weight in the pool of total fluff nodes. These can then start collecting data on stem transactions. Even if the nodes end up aggregating and broadcasting the transactions correctly (thus disguising any issue on the network), they will be able to deduce the original unaggregated transactions (as they will be receiving them in piecemeal one by one). Wouldn't some aggregation by honest nodes be better than nothing, i.e. not even attempting to aggregate? Maybe. But I think there's a problem to have a system that users believe achieves a certain degree of privacy, if this can easily be circumvented. In the dandelion++ paper, the node's choice between stemming or fluffing is pseudorandom [edit: but still recommends 10% or 20% fluff mode setting]. Perhaps the entire objective of aggregation should be removed from our thinking around Dandelion? |
If a malicious actor controlled 10% of the nodes on the network then they would have 50% of the "sinks" and would therefore see roughly 50% of all stem txs. Is that your thinking? How likely is it that a malicious actor would be able to do this? Kind of feels like if we are in this situation there is not a lot anybody can do in terms of preventing them observing txs and constructing a reasonably complete tx graph. |
Is that true? I thought it was still 90/10. |
Yes, how many nodes are there on the network today? ~100? This means that 10 nodes will be fluffing nodes at any given time. If a malicious actor deploys 10 always-fluffing nodes as well, it means they see 50% of all transactions.
It's 5x as likely compared to if the probability was a fair coin flip and we had 50 honest fluff nodes in my example above.
[Edit: yes, digging deeper you're right, I struggle to understand what the benefits from aggregation are. It's not a bad thing, but it's not clear to me why we should strive for it in our design objectives. If it happens, then great. [truncated] |
|
Please disregard the statement of 90/10, I dug deeper in the papers, and now see that |
|
@antiochp in the Grin implementation, does a peer always stem their own transaction? this is what's instructed in the paper, i.e. to only ever fluff stem transactions received from other peers, but never their own. |
Good question. The downside here is we may end up aggregating our own txs if our node is in a fluff epoch (and not a stem epoch). I'm not actually sure what kind of downside we see with this implementation. Some txs will end up appearing on the network from the nodes where they actually originated - but we won't know which txs these are, so I'm not entirely convinced we actually lose any privacy here? |
Why is it important to keep the "is this our tx?" knowledge? In my naive interpretation of how D++ was being implemented in Grin, I was presuming that nodes add any tx, whether received or originating from themselves to their own stempool and set an embargo timer on them. If you stem it, and don't see it within the embargo, you will fluff it either way.
I think they added this requirement for a reason. Let's say we have a network of 100 honest nodes that are being observed. 10 of those will be fluff nodes, and 90 will be stem nodes. Let's also assume that each fluff node fluffs 5 transactions each epoch (which is a fairly high estimate I would imagine). If a fluffing node fluffs its own transaction, an attacker will know that "every 10% of the time, the anonymity set of a node's own transaction will be 1 in 5". If they manage to figure out which one that was, then they would also reduce the anonymity set of the other transactions being fluffed to 1 in 4. This might sound like little additional information to give up, but if you monitor a network over time and build up a lot of data, this will have an impact on your model's prediction accuracy. On the other hand, if a node always stems their own transaction regardless of whether it's in fluff or stem mode, the attacker will know that "every 100% of the time, the anonymity set of a node's own transaction will be 1 in 90". Which would make it much harder to pinpoint the originating source, as you're hiding amongst all the other stem nodes. |
antiochp
added
the
release notes
Resolves #2176.
Replaces #2344. Minimizing unrelated changes and keeping focused on Dandelion++.
This is a minimal implementation of Dandelion++ to replace our existing minimal implementation of the original Dandelion.
DandelionEpochto track current epoch stem/fluff and current outbound relay peerPoolEntryStateepoch_secsaggregation_secs), aggregate and fluff all stem txsembargo_secs) by broadcasting individual txs