Good morning Azure, Thank you for your question. I am happy to say that the protocol has already been implemented into Grin as of 2 days ago; https://github.com/mimblewimble/grin/pull/1067 <https://github.com/mimblewimble/grin/pull/1067>. I'm going to explain here the details for the ML.
We started with Dandelion [1], a privacy-preserving transaction propagation protocol. Basically, instead of broadcasting transactions to a subset of your peers, you broadcast it to only one peer: the Dandelion relay, a randomly chosen outgoing peer. This peer will do a coin flip to determine if it should send the transaction to everyone (fluff it), or only its own Dandelion relay (stem it). So basically, transactions are propagated in two phases: the stem phases (only to one peer) and the fluff phase (to all the peers). This was implemented in #719 [2]. Still no aggregation at this point. Then we found that we can leverage this protocol to aggregate transactions during the stem phase. But in that case, we need to allow transactions with multiples kernels [3] and be resilient to the Denial of Service attack that Andrew talked about where a random peer can just perform a weird aggregation (which can possibly invalidate transactions). In the last case, we developed a way to de-aggregate aggregated transactions [4]. Finally, in order to aggregate transactions with the Dandelion protocol, we implemented the following protocol. When you send a transaction that you want to be aggregated with other transactions (we use the term stem transaction here), we will broadcast this transaction to our Dandelion relay. The Dandelion relay will then wait a period of time (the patience timer), in order to get more stem transactions to aggregate. At the end of the timer, the relay does a coin flip for each new stem transaction and determines if it will stem it (send to the next Dandelion relay) or fluff it (broadcast normally). Then the node will take all the transactions to stem, aggregate them, and broadcast them to the next Dandelion relay. It will do the same for the transactions to fluff, except that it will broadcast the aggregated transactions "normally" (to a random subset of the peers). This gives us a P2P protocol that can handle transaction merging. Antioch did an amazing job, the code is well written and well commented [5]. Finally, it is still possible to broadcast a transaction normally (bypass this protocol and then send it to all your peers) if you are in hurry and cannot wait for the aggregation with others transactions. I understand that some may find this explanation slightly complicated, considering all of the new vocabulary. You can read more about Dandelion in the Grin docs [6], and I also created some slides (which are not up to date but should give you a good understanding of Grin & Dandelion) that you can review[7]. Cheers, ~ Quentin [1] Dandelion BIP https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki <https://github.com/gfanti/bips/blob/master/bip-dandelion.mediawiki> [2] Dandelion PR https://github.com/mimblewimble/grin/pull/719 <https://github.com/mimblewimble/grin/pull/719> [3] Allowing multi-kernels transaction https://github.com/mimblewimble/grin/pull/681 <https://github.com/mimblewimble/grin/pull/681> [4] Anti-aggregation mechanism https://github.com/mimblewimble/grin/pull/984 <https://github.com/mimblewimble/grin/pull/984> [5] Dandelion monitor code https://github.com/mimblewimble/grin/blob/master/servers/src/grin/dandelion_monitor.rs <https://github.com/mimblewimble/grin/blob/master/servers/src/grin/dandelion_monitor.rs> [6] Grin Dandelion docs https://github.com/mimblewimble/grin/tree/master/doc/dandelion <https://github.com/mimblewimble/grin/tree/master/doc/dandelion> [7] Grin & Dandelion slides http://lesceller.com/doc/dandelion.pdf <http://lesceller.com/doc/dandelion.pdf> > Le 1 juin 2018 à 05:19, AzureSky <azure...@protonmail.ch> a écrit : > > Goodmorning everyone, > > I'm trying to deepen the technology and I was watching a podcast of Andrew > Polstra > https://www.weusecoins.com/mimble-wimble-andrew-poelstra/ > <https://www.weusecoins.com/mimble-wimble-andrew-poelstra/> > that in November 2016 left open a question / opportunity, which I report: > > Another open problem that I didn't talk about too much is something that Grin > is facing right now. How do you design a p2p protocol where it is possible to > just combine transactions freely? It turns out that if you just allow free > combination of transactions, this causes serious problems at the p2p layer > even without Denial of Service attacks or griefing. Suppose you're a > privacy-minded user, and you want to sed a coin to someone, but you don't > want anyone to know this is happening. You might wait for some other > transaction to come along, and when it does happen you want to broadcast a > combination to the network instead of just yours. What happens if I do that, > and someone else has the same idea? So now I have a combination where two > transactions are conflicting, where it's missing my part but it has other > parts. So now there are two conflicting transactions that conflict, and only > one can geet confirmed. This is pretty bad. In practice, we need something > different probably a bit more complicated than a simple flood network where > people are combining all willy-nilly. For example, this might look like > people sending transactions directly to miners, and they give a variant of > the transaction to each miner. And then one miner knows what the original > transactions were in the block, but nobody else knows. This is pretty good > privacy and it's a fairly simple model to reason about, but it does require a > communication channel with a miner which is a little annoying. > > Is this protocol developed in grin, in plan or it is a hypothesis definitely > waned? > Can you give me a link to how it was implemented, designed or possibly a > brief reasons that make this road impractical? > > ~ Azure > -- > Mailing list: https://launchpad.net/~mimblewimble > Post to : mimblewimble@lists.launchpad.net > Unsubscribe : https://launchpad.net/~mimblewimble > More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
