#grin2020 Roadmap - calling for blog posts with ideas

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.

3 Likes

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.

7 Likes


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

3 Likes

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

2 Likes

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?

3 Likes

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.

6 Likes

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.

4 Likes

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.

3 Likes

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.

6 Likes

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

1 Like

In terms of pros, it’s been said that supporting BLS signatures would enable:

  1. Transactions to be created non-interactively, i.e. no communication between sender S and recipient R required for a valid transaction to be built;
  2. All transaction kernels (moving forward from that point on) to be aggregated into a single kernel.

In terms of cons, I understand that:

  1. Additional hardness assumptions would be added so that Grin would no longer have the same security assumptions as Bitcoin.
  2. Adaptor signatures (scriptless scripts) would not work with BLS. Even if there are efforts to figure out how to support this, they have not been confirmed to work yet. This means things like atomic swaps and lightning-network style scaling on L2 might not be possible in the future.
  3. There’s added complexity in terms of supporting two signatures (Schnorr + BLS), there’s added effort in terms of building/integrating a BLS library where there currently is no standard, and added risk in terms of getting something wrong in the implementation process where there’s not been an implementation in production yet.

In addition, there’s an open question in terms of how to best introduce the signatures and (any) migration process. A turnstile approach has been mentioned in the past, but I don’t think there’s been an actual proposal yet for how this would work in practice.

What else is there in terms of pros/cons/questions that I’ve failed to include above? For the record, I don’t think it’s been established yet whether the above claims are factually correct.

1 Like

I think item 2 is misleading. A kernel consists of several parts: a public excess, a message (usually including a fee, and an optional lock height), a nonce commitment, and the actual signature scalar.

With BLS there are no nonces, and the signature scalar becomes a signature curve point.

Even with BLS, one still needs to store all the public excesses (i.e. public keys), and all the messages. For each unique message, one can then aggregate their signature curve points into a single one.

Overall this appears to be at best a small constant factor reduction in size and processing.

2 Likes

That’s great to get clarified, @tromp.

With regards to point 1, I think there was some questions around that as well? I saw some discussion in the keybase chat recently but can’t find it now. Was it ever established to what degree transactions would be non-interactive under BLS? @jaspervdm @david

Assuming we don’t want to put additional data on-chain, you might be able to reduce transaction building to a single trip, i.e. S->R instead of S->R->S, but not better than that. We are still limited by the bulletproof, which can only be generated by the receiver.

I think the main question right now is if at our current point in time it would make sense to dedicate our limited resources to BLS.
Grin has been relying only on “established” cryptography, based on ECDLP. Using BLS would be a significant departure from that, pairing based crypto is less mature and “battle-tested”. In addition we would have to indefinitely support 2 crypto libraries simultaneously that use different curves and devise a way to allow users to transfer between them.

Edit; oh i see daniel already did a good job of summarising the downsides :slight_smile:

1 Like

I’ll have to re-read the Gandalf the Pink proposal, but I think the idea behind hanging transactions was that the bulletproofs would be added when spending, essentially making them part of the input instead of the output.

For scriptless scripts, one possibility is to support them with lesser security properties by including an additional signature that’s pruned after the horizon. It’s debatable whether that provides enough security, and can be made to work.

The biggest point to be made is we won’t know what’s possible until we actually fully investigate the consequences of BLS, and try to design a system that uses them. It appears to me that some have already written them off, while others believe they will solve everything, but I don’t think any of us have done enough legwork to come to any such conclusions.

2 Likes