#grin2020 Roadmap - calling for blog posts with ideas

I think developers need to focus equally on easy usability of Grin and for this a good secure mobile wallet with easy user interface is must.



Comments such as “Only TOR” or “no HTTP” make no sense at all.

Do you realize HTTP is the transport mechanism for transactions via TOR?

1 Like

I’m interested, now grin is used among themselves as a test network. but when will it be possible to buy coffee in the store using grin? will it be in the future? I hope you understand what I mean

1 Like

Can we add QR code feature to any GRIN wallet ? If possible … It would be a great development for ease of use of GRIN as currency. Thanks


This has also been discussed before in Gitter. There is also some recent discussion in the Ironbelly group about sending via QR codes: https://t.me/ironbelly/942

The initial drawback was that QR codes could not support enough data to send large Txs. However, it’s been suggested that color QR codes could be sufficient and animated QR codes(fountain codes) can support large data transfer( much larger than any Grin tx) https://github.com/divan/txqr

Sending via NFC for in-person TXs was also another suggestion.


I think bug fixes are the most needed. Features are fun and nice but secondary to basic reliability. I would like to see a solid foundation which would require work on:

  • Chain Syncing issues
  • Chain corruption issues
  • Wallet corruption issues
  • Wallet locking issues

Thanks for listening.


When : https://eprint.iacr.org/2019/226 ?


A first draft of a roadmap RFC: https://github.com/mimblewimble/grin-rfcs/pull/38

1 Like

I know I’m way late, but I’d like to see end-to-end encryption, at the very least support for self signed certificates (I haven’t been able to figure out why this isn’t supported but there is maybe a reason). Most people don’t have domains and trusted certificates. This would make all of our communications more secure and let us connect our ironbelly or other wallets to our nodes more securely


thank you @lehnberg for putting this together!
I’m personally still wondering what the community thinks of BLS pink research
It seems to be done by someone that has AT LEAST basic understanding of crypto (likely way beyond that) and seems to actually improve the scalability in the big O notation with regards to chain size. Sure, it’s a tradeoff in the end, but it feels like it should be discussed and has been put off for quite some time. Are there any specific reasons we are not seeing discussions in this direction?


I for one would welcome more discussion about BLS signatures in general, and about the ideas that GandalfThePink proposed in the paper you refer to. [0]

With regards to the RFC, I was thinking where BLS signatures and where the “Grinsecure” nightly experimentation chain that @yeastplume had proposed belonged in the context of a 2020 Roadmap. Even if I welcome exploring both these ideas further, I couldn’t come up with a solid argument as to why this should be a priority for 2020, over stabilisation, quality of service, and developer usability improvements.

In addition, BLS is in the process of being standardised, and it might make sense to wait until this has happened and there are more mature libraries for us to use. I’m not sure.

[0] https://github.com/mimblewimble/grin/issues/2504#issuecomment-467446197

1 Like

I can’t think of any greater usability improvement than providing non-interactive txs. I agree we should not release BLS code until after it’s standardized, but realistically, it’s going to take us a long time to get right. In my opinion, there’s no better time than now to start working on this.


Glad to hear that. I don’t understand the pink implementation right now, but my guess is that its not possible to aggregate the previous kernels. If this is true, then the incentive is to research it ASAP because if we do get any significant chain activity (it’s likely that the number of transactions will grow and it can grow up quite fast) then we will be ‘bloating’ the chain with kernels that we won’t be able to get rid of.
Another good thing is the non-interactivity that David mentioned. I agree that it should first be standardized though. All that said, I’m not a cryptographer, just trying to encourage some movement in this direction. Perhaps having a cryptographer look into questions like:

  • is it possible to aggregate bulletproofs while keeping the prunning?
  • is BLS pink research viable and can it be improved?
  • could MW benefit from Halo?
  • what are the lattice based alternatives?
    etc., would be a good idea.

I’m all for moving slow and not rushing, but we also need to be aware that it becomes much harder to make bigger changes once the community grows.


100% agree. Now, where to find a cryptographer… :thinking:

1 Like

Stabilization/ quality of service should be worked on regardless. IMO BLS should be near the top of the list in terms of development ideas to explore in 2020. Why wait when Grin can help standardize BLS? I thought Grin was supposed to be innovative/ cutting edge, not Mr conservative. It also seems slightly trivial focusing on usability improvements when BLS could change everything. From what I’ve gathered most in the Grin community are eager to hire a cryptographer to further explore BLS.

At the moment you can make the argument that Grin scales no better than Bitcoin because of Big-O.


Generally speaking about BLS, it is promising for sure, but the benefits do not come for free. New hardness assumptions would be introduced, we might lose ability to do adaptor signatures (although there are some ideas around that too), and there’s an upgrade and rollout mechanism that is yet to be defined. For me personally, it’s difficult to reason about whether it makes sense to introduce this or not without a more concrete plan and an evaluation of the pros and cons.

If we think exploring this is a priority for 2020, then there is arguably a lot of work around planning, design, and consensus building to be done even before there is a library that we can integrate.

Where do we start? What is a “good” step to have as a bullet on the roadmap? A BLS RFC proposal? What do we think is reasonable to achieve here by the end of the year?

Not sure if that’s a good step, but I’ll start with something and hope others can add to this. It seems easiest to start by analyzing/understanding the pink research paper and then writing down the pros and cons of making the switch to BLS as described in the paper - this, of course, includes a detailed transition plan. Without knowing the transition process, we can’t know the cons that the implementation details could bring.

It seems like no one in Grin core/ any active dev is confident they could design/ implement a BLS solution.

So, we start by hiring an independent cryptographer like some of us have been harping on about for many months now. This cryptographer would head up a BLS sub-team and other members of Grin core/ community could be appointed roles within that sub-team

To find the right Cryptographer we could advertise a full time( contract) role that paid the equivalent of 1x Yeast unit per month. This role could be reviewed quarterly. The premise of the role would be around investigating and then developing a production-ready BLS implementation for Grin. However, additional tasks could be added on top.

If we let the world know that Grin wants to hire a Cryptographer to investigate/ potentially implement BLS sigs then it’s going to create some buzz( free marketing). Because we’re doing something that everyone knows about but no one’s dared to do yet.


So what is the main pro? And how can we quantify that?

1 Like