mimblewimble team mailing list archive

[AzureSky <azuresky@xxxxxxxxxxxxx>]

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/
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