I was thinking it was about time that someone put together a new Mimblewimble whitepaper. Perhaps a combined effort between Grin & Beam, so that everyone stops referencing Vanilla MW as per the Poelstra Whitepaper and the Breaking Mimblewimble article, which has been the most popular and damaging article for both Grin & Beam. A popular narrative is that privacy is broken in mimblewimble(linkablity) and can’t be improved, when they are various known techniques: eg Decoy outputs (1), Grinjoin, daily aggregator/ coinswap(2)(3), and of course Beam’s Lelantus-MW (4). Another popular narrative is that usability will always suffer because of interactivity and the 3 step tx method, when there are now slates/ Tor addresses, non-interactive solutions(5)(6)(7), and also a proposed 2-step method that needs more eyes on it (8) ( perfect opportunity to present that as a Future research question). The paper could also detail the likes of atomic swaps/ payment channels/ sidechain support/ CA etc( which were more like research questions in Poelstra’s paper)
^All these methods are already documented, however, they are not all in one place and they are only really getting attention from inner circle folk who are currently involved in one of the MW implementations. The hope would be that a new MW whitepaper might be seen by new eyes( and old ones).
^If this is something you would like to participate in please join.
I thought someone like @phyro@david could be interested. Ideally, it would require someone(or a small group) to take a lead role on the Grin side and then for many others to review it. If it’s an idea most support then whoever takes the lead could consider submitting a funding request for their time.
The proposed two step method relies on a version of Bellare-Neven multi-signatures that does not commit to both parties’ public keys in the hash challenge.
That modification invalidates the security proof (Theorem 4 in the Bellare-Neven paper) of the signature scheme. So what is really needed is a new security proof for the modified version.
I don’t think we should be using a signature scheme that lacks a security proof.
So what we can do is offer a bounty for someone to write such a proof, and have it pass peer review.
Thanks for bringing this up, I’m sure everyone would appreciate having lots of ideas written down in one place As for myself, I just invested some time into making some blog posts about how MW works, so I’ll likely not be tackling documentation oriented tasks next (and I believe many others are more appropriate for this). But I would be happy to give it a read and check parts I’m familiar with.
I think of many things that have been mentioned here as being unrelated to the MW protocol itself. For instance slatepacks/tor, 2-step vs 3-step, decoys, payjoins and daily aggregator are specific implementation details that Grin has which are transaction decisions/flows on the p2p level - p2p handling isn’t defined in the MW protocol (nor do I think it should be).
My point is that yes, Grin implementation leaks tx graph, but I think this is a Grin problem and not that of the MW protocol itself (because p2p aggregation is an implementation issue and isn’t defined in the protocol). I’d go as far as saying that the MW itself doesn’t leak unaggregated block txs, only the implementations do because they’re the ones hit with some annoying implementation details that we don’t yet know how to solve. The question is now, how do we implement the p2p layer without introducing leaks or how do we minimize those. An aggregator is one such possible step, but we’ll likely find more ways in the coming years. Btw, a trustless aggregator to which everyone sends their tx would have already been a really cool solution that would match the spec privacy - I’m ignoring possible issues like what happens if it’s offline etc…
The ideas you enumerated are definitely all worth putting together in some document because right now you need to know what you’re searching for in order to find it, so I’d support having these described somewhere
As you can see in my privacy chart at https://forum.grin.mw/t/scalability-vs-privacy-chart, I ascribe the linkability problem to Mimblewimble itself, since the only reasonably straightforward way to make transactions known to arbitrary miners for inclusion is by broadcast.
I think most people would agree with you on this one and I believe both views are ok. If you assume the protocol users perform the simplest tx transmission path which is just a broadcast, then yes, it leaks.
I just realized that by my definition, Bitcoin itself does not necessarily leak the tx graph because I could argue the same thing there - users should be coinjoining. I’ll need to think about it some more.
I’m doubtful anyone involved wants to tackle more document-originated tasks hence suggesting a funding request
I think we need to do more than just document everything together in one place. Part of the premise of creating another Whitepaper is indirect marketing. We want more eyes on Grin/ new contributors. If we just put together some document then it’s only likely to get viewed by those already involved in the project(small audience) however, a new MWv2 Whitepaper is likely to get picked up by news outlets eg CoinDesk, thus gain more interest/ be seen by a much larger audience.
If we created a new whitepaper with future research questions —> after the whitepaper has done the rounds and gained some attention we could then run bounties for some of the questions( eg new security proof for two-step method/ trustless aggregator- which could be at the protocol level), I’m sure many would also like to draw more attention to the protocol level NIT schemes. I also don’t see a big issue in including potential implementation details in a section of the paper
As for myself, I just invested some time into making some blog posts about how MW works, so I’ll likely not be tackling documentation oriented tasks next (and I believe many others are more appropriate for this). But I would be happy to give it a read and check parts I’m familiar with.
hence suggesting a funding request