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).
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.
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.