20200804-meeting-development.md

Meeting Notes: Development, Aug 04 2020

Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 60 min.

Notes are truncated, and conversations sorted based on topic and not always chronological. Quotes are edited for brevity and clarity, and not always exact.

Community attendance:

• joltz
• kurt2
• lehnberg
• mably
• paouky
• phyro
• tromp
• yeastplume

(apologies if I missed someone - submit a PR or contact @lehnberg to add)

Agenda points & Actions

1. Retrospective

• yeastplume: On a quick reminisce during the lazy days of summer. It's been mostly a few refinements, addressing issues, and post-hf clean ups, refactors, etc. Of recent note there's been a interesting discussion of eliminating the finalize step from David Burkett.

  Also a new contributor, who's added some code and sparked some discussion on slatepack max sizes unsedd (whose handle on KB I don't seem to have) mimblewimble/grin-wallet#495.

  • 🚀: joltz

2. Agenda review

The proposed agenda was accepted without modifications.

3. Action point follow ups from previous meetings

3.1 Release checklist

Actioned.

3.2 Mitigating re-org risks actions

• yeastplume: Forum post has been published, the rest of the items hav enot progressed.

3.3 Bulletproofs+ questions

3.4 Bulletproofs+ reach out to researchers

• yeastplume: So on bulletproofs+ questions, I forgot who was to have taken that point, let me look.

  • lehnberg: Was meant to be you and I, I believe. (we've not done it)
  • yeastplume: Yes, I think we can safely assume that.

• lehnberg: But yeah I think key takeaways were to understand:

  1. whether bp+ is compatible with what we're doing in grin with bulletproofs (storing extra info etc);
  2. whether original bp authors were thumbs up on the approach of bp+;
  3. even if all good in 1 & 2, would we really touch libsecp for this right now?

  If we would, then 1 &2 makes sense and should be a priority. If not, maybe it's not really that urgent.

  • kurt2: The answer for 1) is yes.
  • yeastplume: Right, be is a bunz/poelstra question.
  • joltz: And 4) is it even possible to get an adequate level of review between now and hf even if that is the only thing we focus on? Wrt both specification and implementation.
    • 👍: phyro

• tromp: I'd rather have effort spent on pibd than on doing bp+ before hf4.

  • 👍: kurt2, yeastplume, phyro

• kurt2: Note that for 1), there are two solutions to retrieve the value v at wallet restore. 1) lll algorithm, which is a bit slow. 2) adding 64 bits of data to bulletproofs+ to store v directly (hidden version of v). So we probably have to assume that 2) is the only reasonable solution. Just for notice:) 64 bits is not a lot of extra data anyways.

• yeastplume: On 3), I've implemented aggsig (which is a simple algorithm), and made some changes to some bp code to allow for derivation path storage. I don't feel I'd be the right person for a full bulletproof+ implementation. And It feels bp+ would be an easy sell to the community for a reason for an hf, once it's more fully reviewed and if audited impls later become available. It doesn't feel like an emergency.

• joltz: I'm not sure we are in a position to expend the resources necessary to get bp+ from its current state to production ready. May be best to take long road and collaborate with greater community on that.

  • 👍: yeastplume, tromp, paouky, lehnberg

4. v5.0.0 planning:

• yeastplume: I guess that all leads into... 5.0.0 planning.. I think I might not be alone in wondering what we should be doing, it feels like a lot of things were thrown out as potential changes, with many rejected for some reason or another.Or rather, a sense they weren't urgent, or appropriate. It feel like short of pow changes there isn't much that people are clamouring for in the last hf.

  • lehnberg: Well, clamouring I think there are. I'd maybe say it's hard to build consensus around any proposal.

• tromp: Pibd!

• kurt2: Unique kernels! :o

• joltz: If only we had a process to formalize these ideas and track the comments...

  • 🔥: yeastplume, phyro
  • 🧂: lehnberg, phyro

• lehnberg: Is there anything 5.0.0 related from that list we ought to talk about today? Tromp you're writing an RFC for the proposed difficulty adjustment change, correct?

• yeastplume: That's true.. Remember everyone that we don't require rfcs to be peer-reviewed, intensely researched and then typed up with hundreds of supporting formulas and proofs in latex. Just get the idea up there in any form.

• tromp: I'm focussed on writing an RFC for changing DAA but would be happy to help on an RFC for adding (re)-play protection rules to grin-wallet.

  • lehnberg: Help... @phyro you mean? 😬
    • 👀: phyro

• kurt2: All the replay and plays can be helped with social engineering I think.

• phyro: I guess I could put something together about anchors but definitely won't be implementation details. If anyone with more background picks this one up I'm also all for it.

• yeastplume: Btw, the nice thing about that idea is that there's nothing preventing anyone from trying it whenever they like.

• tromp: Would you want to help out with wallet rules rfc, yeastplume?

  • yeastplume: Sure, I can do that.

• phyro: Oh we're talking about sweeping rules?

  • tromp: About (re)play protection rules. Possibly including anchors and payjoins.
    • 👍: yeastplume, phyro

• yeastplume: Okay.. Is that really it for 5.0.0 dIscussion for the time being though?

• joltz: It's also our last chance for critical security fixes so find 'em if we got 'em:)

  • 🙏: lehnberg
  • kurt2: There are already critical ones. As much as reorgs can make people loose coins (which were discussed to be mitigated) the current attacks allow the theft of coins.

• lehnberg: Are we all on the same page about not doing nrd activation on 5.0.0? I'm for the record still in favour of doing it.

  • tromp: I'm ok with leaving both bp+ and nrd activation as prime targets for an eventual unplanned hf.
  • yeastplume: Am okay with this as well. Perhaps something we didn't consider originally and are now realizing is that the last hf should possibly be the most careful and conservative one.
  • lehnberg: Fair enough I guess, I can't really argue with that...

• tromp: Did we plan to deprecate https as well?

  • yeastplume: Yes, that we do.
  • tromp: Ok, so just tor + slateplacks after hf4, cool.
  • joltz: I'd like to see more feedback from slatepack integrations personally.
  • lehnberg: Afaik there are few of those in the wild yet. We might want to see if we could incentivize that somehow? Maybe even a "slatepack supported" stamp and a place on the website for every service that does it.
    • 👍: yeastplume

• kurt2: And as often, and unfortunately, even for the smartest organisations/communities/entities, it is after the actual realization of the attacks that we measures are taken to prevent them more strongly.

  • phyro: Yeah, I think everyone here wants to get rid of the attacks which is why we had many conversations around these. We just need to decide on which approach to take.

• phyro: Slatepack integration lib for exchanges? With promises of having less issues.

  • lehnberg: That would be very nice as well ofc. I believe @joltz and @quentinlesceller wanted to put together integration docs.
  • joltz: There should be a copy of the docs out there, just waiting for some formatting from quentin maybe.
  • lehnberg: Yep believe he's away these days.

• joltz: It would be good to engage services to encourage and assist them to upgrade to slatepacks before we get too close to the deadline.

• paouky: Worst case, services will be rushing to implement slatepack right before the last hard fork, when it will become the only option.

  • lehnberg: Or just stop supporting grin. When it stops working.

• paouky: We all know that would happen haha.

• phyro: I have faith if we have some transitions docs ready.

• joltz: Now is a good time while things are relatively calm. If macro market picks up the engineers will be too busy to bother for sure.

  • 👍: phyro, yeastplume, lehnberg

• yeastplume: We should have those docs out soon anyhow (and we should be making them prominent asap).

  • 👍: joltz

5. Other questions

5.1 Eliminating finalize step

• lehnberg: Perhaps somewhat related (to kernels), @mably was asking whether we could talk about david's idea of eliminating finalize step in tx building.

  • 👍: mably

• tromp: I find the fact that a possible attacker is picking your nonces to sign with rather scary. Since they can easily introduce bias into the nonces which is a known attack leading to key leakage.

  • kurt2: No they cant. The nonce is a function of a hash of a diffie hellman secret. Lets be precise. Which you can not control the output randomness. When attacker chooses new keys each time for example. And this is clear. I am not inventing this. It is call a hash function.
  • tromp: Maybe it can be bias proof. But we need to nail down technical details first so we can better reason about it.

• yeastplume: Agreed, but I also like that there's basically nothing anyone can do to prevent anyone trying this. We had a lot of ideas in the early days about enabling cold storage or offline wallets by 'pre-generating some stuff', and this is along the same lines except it's deterministic.

• yeastplume: Am quite happy to see varying solutions to whatever problems out there, and wallets/users can choose whichever protocol they'd like to follow if the tradeoff is acceptable to them.

• yeastplume: So would definitely like to see the results of that thread written up in an rfc.

  • 👍: phyro, mably

• lehnberg: So zooming out a bit. I guess we all can agree that the idea of eliminating finalize in the tx building step is very interesting, right? Might make tx-building simpler // reduce state and mishaps. And also possibly enable some kind of simpler offline sends. Than what was previously possible. Right? Is there anyone that have a good reason why we wouldn't want the third step eliminated if we could?

• yeastplume: And if the drawbacks are known and documented, users will be better informed as to whether they're an acceptable convenience trade-off.

  • lehnberg: In my most humble opinion, we don't want a situation where there are multiple ways to finalize a grin transaction or it will be a ux nightmare. So either 1 trip + broadcast or 2 trips + broadcast. But not both at the same time.
    • 👍: paouky

• kurt2: It would be fair to give the constructions to a cryptographer for review. If we think we could implement it.

  • 👍: phyro

• yeastplume: We also can't stop anyone from doing so if they choose.

  • lehnberg: Yes, we can't prevent it. But we ought to urge consistency here.
  • yeastplume: Can only advocate.
  • lehnberg: Which can go quite far.
  • yeastplume: Indeed. We can also urge consistency to the point of rigidness.. But we're getting ahead of ourselves. We need a proper write-up.
  • lehnberg: Yeah, it's great that the forum thread is active, which feels like a nice whiteboard brainstorming kind of thing. Would be good to have a document that keeps track of the latest and greatest of the actual proposal. As it's very hard to parse and understand that. I think payment proofs are worked out right? Or not?
  • kurt2: Yes they are. Well, we are not cryptographer. So still 0.0001% to have missed something.
  • phyro: You mean 5%? Not missing things is hard.
  • kurt2: I mean or the attacks, I would say something like 4%. For the fact that payment proof is provided, I think I am fairly certain it is sound.
  • lehnberg: Okay, it's nice that we have these percentages.
    • 😂: phyro
  • yeastplume: Right, let's not hold anyone to them.

• lehnberg: But yeah, if we want a cryptographer to review sth, it helps to have an actual proposal. That we could point to. I love forum threads, but not sure it's the right format.

  • phyro: No They are not. They too easily get side-tracked as well.

• kurt2: Yeah for me I know nothing about wallet implementations. So I just do the theory.

  • 👆: phyro

• kurt2: Anyone is free to make a proposal.

• joltz: A good place to brainstorm original idea to get it solidified as a proposal for an rfc.

• tromp: Sometimes it's good to start a new thread with a first post that summarizes insights gained in earlier thread.

  • 👍: lehnberg, phyro
  • lehnberg: @kurt2 do you think david would be interested in writing something like that to get us all on the same page? Given it's his original idea and all.
  • kurt2: Ah, not any idea if he wants, I guess he could but I havent asked him.

5.2 Expiring kernels

• kurt2: There were ek in the agenda? Or maybe the decision is already taken? Just asking... :)

  • lehnberg: I think expiring kernels (ek) right now doesn't have a strong consensus around it. Some are nay, Some are yay, Some are unknown. Without a consensus, it won't go in, that's for sure. Something like this no-finalize idea, should it actually require ek, might help to sway people on it, I don't know.

  But then the no-finalize-idea would need to be formalized, and it would need to be established how/why ek is a must, etc etc and a lot of consensus building would need to happen. So there's a lot of work there. :)

  This is my understanding of the current status. It's not like we can take an official decision that there is no official agreement on how to move forward.

  • kurt2: There is also a proposal without expiry.
  • lehnberg: There's a proposal for having expiring kernels without expiry?
  • kurt2: Unique kernels without expiry ya. Well, a document. But thanks for the answer about ek @lehnberg.
    • lehnberg: Np, it's nothing new I think, it's the same situation it's been for a while.
  • kurt2: Yes but the non expiring has not been discussed. No problem if people do not want.
  • lehnberg: I don't know which of all the 5-6 different threads and proposal that is personally. So it's very possible it's not been discussed, I've personally lost track somewhere two three weeks back. Something needs to happen if we're going to get out of this (local?) equilibria. If no action is taken, It won't go into 5.0.0.
  • phyro: The replay/play discussions kind of died out 2 weeks ago.
  • lehnberg: If anyone wants to force a discussion for anything technical or consensus breaking, there's a clear way to do that → write an RFC and open a pull request. Even if it's a draft, means, we must deal with it.
  • kurt2: I mean I would be glad to hear the decision formalized. Or not if it has not been taken. So that people stop searching or arguing. Iif payjoin/unspendable outputs.
  • paouky: @kurt2 why not write an RFC to sum up the discussion? Everybody would be much more open to that.
  • phyro: I don't think anything was chosen, at least I have not seen anything and I try to read all the things lol.
  • kurt2: Ah oki. Thanks phyro.

• joltz: I don't think any approach would be chosen anyway without a complete accompanying rfc.

Meeting adjourned.