Open casey opened 5 years ago
sesam
commented
5 years ago have you tested if this can be built simply by putting one grin node in front of another? I think Dandelion would kick in even in that case. otherwise we might offer some parameter to force stemming, like we today already support immediate fluffing
phyro
commented
2 years ago @casey I stumbled on this issue sort of random. I was pleasantly surprised to find out that you were looking for the right properties in the aggregator service even before the launch of Grin. I'll leave a link below in case you're interested in checking a variant of an aggregator that is non-interactive (fire & forget), doesn't block real transactions and produces a single kernel. This aggregator has a chain of N mixnodes where if only one of these mixnodes is honest, it blinds everyone from knowing the input/output links including this aggregator.
This is a continuation of this forum thread.
If an entity is sending or receiving many transactions, it may be a privacy win if that entity aggregates those transactions before they're broadcast to the network. Although the entity itself would have observed the relationship between the inputs and outputs of the aggregate transaction, other the nodes on the network would not have, partially defeating the ability to observe un-aggregated transactions on the network and thus the true transaction graph.
If the transactions could be aggregated such that they shared a single kernel, this would also be a space savings. However, this might be impractical since it would require additional rounds of communication between unrelated transactees.
This could be supported by a separate service, or by the wallet/node itself. One possible way this could work would be allowing the wallet, when providing a transaction to the node to broadcast, to specify a delay before which the transaction should not be broadcast, and during which time it should be aggregated with other transactions that originate from the node.