Dandelion Improvement Proposal - Stem > Bloom > Fluff

Development and Technical Discussion
1

I’m brand new to this community and just learned about this project two days ago, so what I say here may be completely wrong and not make any sense. Bear with me.

My understanding is that there is a problem with transactions being monitored and mapped to individuals before the aggregation/cut-through process. Looking through the forum, there are two other similar threads I saw: objective-dandelion and Dandelion w/ Onion. Sorry if this seems too similar, but I think this is different enough to merit discussion.

The stem and fluff phases remain unchanged, but a bloom phase in the middle is added. Similar to the current process, a node randomly and asynchronously decides to be in one of two states: Stem (unchanged) and Bloom/Fluff (new).

The Process
Bloom/fluff nodes wait to receive a transaction from a stem node. As soon as a transaction is received, the node starts actively blooming. A countdown is started and the transaction kernel is hashed. This hash is then used in a DHT (distributed hash table). The node seeks out another “blooming” node that has the “closest” hash in terms of keyspace distance. During the countdown the node is still receiving transactions from stem nodes. Because it now has a key for the DHT, it now can receive transactions sent from other blooming nodes that failed to fluff (explained below) and aggregate them along with transactions received from stem nodes.

At the end of the countdown, the node checks if it has enough transactions to aggregate. There are two possible outcomes: 1. If the node has collected a sufficient number of transactions to aggregate, the “fluff” phase starts and the transactions are distributed out to the network. 2. if the node has failed to aggregate enough transactions, all transactions are passed on to the “closest” blooming neighbor.

Other thoughts/problems
A blooming node is supposed to create a hash for the DHT based on only the Kernel. The nature of a DHT means that this hash is public information. Someone snooping on the network could learn that a node was in possession of a specific kernel once its corresponding transaction gets broadcast to the network. I think this is fine though, because if you only know a kernel you cannot correlate inputs and outputs. If they made the hash based on any input or output data, that could be correlated together.

How can a receiving bloom node prove that it has valid transactions to process? a malicious node could make up a hash and add itself to the DHT and collect transactions from other honest nodes. Is there a way to prove using only a kernel that a node has a real transaction? I think a kernel on it’s own proves nothing, it only works when it is processed with the correct inputs and outputs.

I have no idea how this process could protect against “black holes”, or nodes accepting data but never passing it along.

2

Something I forgot: When a node fails to bloom and passes on its transactions, it takes longer for that transaction be broadcast to the network. The time is still finite though. suppose nodes set their countdown to 30 seconds and require at least 4 transactions to bloom. In the absolute worst case, it would take 2 minutes. The worst case is unlikely though, since a blooming node receives transactions at any time during its countdown.

by way of explanation: 1st node with 1 transaction waits for 30s then passes on to 2nd node which now has at least 2 transactions and waits for at most 30s then passes on to…

3

Welcome, happy to see someone new thinking about the improvements :beers:

My guess would be that it can’t, it can even create a temporary self-spend and not broadcast it

Yeah dandelion seems to have a limited guarantees about privacy increase because the nodes can be evil. If it doesn’t broadcast then your wallet will rebroadcast it after some time (or some previous intermediate dandelion node) - i think that’s how this is handled today. From my limited understanding i believe a node couldn’t lie about its current phase (it could be derived from some hash of its DHT public key and some blockhash) but it could decide to send it directly to some evil node that this node operator controls. So the problem with seeking privacy on the dandelion is that it works great if the actors are good but if there are many evil nodes (which are probably not that hard to deploy) then it doesn’t really give you much privacy (except for probabilistically hiding the source-node of the tx)

4

Ah, that self spend without broadcasting is tricky. Are there any promising proposals to fix this issue? I saw one on the forum about a coin mixing service, but I wasn’t sure if it was an actual proposal or just shooting the breeze. It sounds like a different currency like monero is technically more private, at least for now. Don’t get me wrong though, grin is still amazing. I can’t believe the blockchain is only 2 gigs!

5

Yeah grin needs to obfuscate tx graph somehow, i think coinswap proposal is great for this. It isn’t completely trustless (at least 1 coinswap node needs to be fair, otherwise you get no additional privacy from it) but it has a great advantage of it being non-interactive. The only real disadvantage i see is that reorg handling seems difficult

6

This is a bad idea for privacy, you would want the DHT to be based on the identity of the node (e.g. hash of their onion address), not derived from the information they are transmitting. It’s bad for a number of reasons:

  • too much churn (DHT topology changes for each kernel transmitted)
  • snooping spies can track route of the tx pretty easily (as you mention)
    • this is not “fine enough”, it completely destroys the purpose of using Dandelion
  • DHT storage would be exponential
1 Like
7

All very good points. The reason I was thinking an address should be based on the kernel is because it would be random in a way that a node couldn’t manipulate. Also when a transaction is broadcast out to the network, it becomes publicly known information. In the broadcast step the node gets revealed anyway, right? Wouldn’t the stem phase still hide the original sender?

I believe you are right, I’m just trying to understand. I also didn’t know that high churn in a DHT was an issue. Now I know, so thank you!

P.S. I’ve been trying to figure this out, but I couldn’t find anything. How does the current network decide which nodes to connect to? Is it already using something like a DHT?

2 Likes