Skip to content

Latest commit

 

History

History
177 lines (146 loc) · 12.4 KB

20200526-meeting-development.md

File metadata and controls

177 lines (146 loc) · 12.4 KB
Raw

Meeting Notes: Development, May 26 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:

  • antiochp
  • heisenberg1995
  • joltz
  • kurt2
  • lehnberg
  • mably
  • quentinlesceller
  • tromp
  • yeastplume

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

Agenda points & Actions

1. Retrospective

  • yeastplume: Just as a yeasty reminisce the past couple of weeks has been very much trying to get all of the changes in for 4.0.0, reckon it's been similar for everyone.

2. Agenda review

The proposed agenda was accepted without modifications.

3. Action point follow ups from previous meetings

3.1 Crates.io

  • yeastplume: Not actioned, crates still need updating to 3.1.1.
    • lehnberg: 🔔.

3.2 Release checklist

  • quentinlesceller: Release checklist is created but is still a wip document. I'll update it later today.
    • ✅: yeastplume
    • lehnberg: 0.5 x 🔔

4. Status of Grin v4.0.0

  • lehnberg: We're 1 week away from tentative betas.

  • yeastplume: From my end it feels tight but achievable, on the understanding slatepack will not necessarily be 100% perfect. Particularly, there will only be a single address per wallet for now (with multiple addresses to come when we spec exactly how they'll work). Let's go through line by line.

    • 👍: lehnberg

  • lehnberg: Cuckaroo tweak, @tromp?

    • tromp: See the hf3 pr, includes cuckarooz. Not much progress on the cuda miner yet though, except on paper.
    • yeastplume: Needs review still, but seems good to go?
    • tromp: Well, there is the floonet timing...
    • yeastplume: /// floonet second hard fork height, set to happen around 2020-06-20.
    • tromp: I just took a guess on where would be june 20.
    • yeastplume: Was just going to mention that, with release candidate due June 16, that would seem okay? Though do we not want the floonet swapover during a beta rather than leaving it that late?
    • tromp: Seems ok. Just please double check if height is still on target then. Beta is fine too:)
    • yeastplume: Okay, can you add comments just so we don't forget? I think it'll be fine. These are target dates anyhow, we have 10 days between floonet and final release to fix anything up. Just add the comment to the github issue.
    • quentinlesceller: Yep that'll be fine.
    • tromp: Ah, ok.
    • lehnberg: Okay so we're going with june 20? For floonet?
    • tromp: That's consistent with previous hfs.
    • yeastplume: Yep, all okay with that.

  • lehnberg: Compact slates @yeastplume is done, just wanted to check that testing has happened to the point where you're satisfied as well? Or do you want more eyeballs?

    • yeastplume: Any issues will become apparent during the beta phase. Am satisfied with where it is right now.

  • lehnberg: Cool. Nice work making all that happen.

  • quentinlesceller: Yep impressive.

  • lehnberg: Slatepack @j01tz, @yeastplume so yes you were saying.

  • yeastplume: For slatepack, it's 80% there, still needs

    • api functions
    • changes to command line to support the flow
    • any tweaks to the armoring that need to happen.

  • lehnberg: One listening Address? Address re-use in the first impl? Or not?

  • yeastplume: No address reuse for now, but should be an easy target for 4.1.0.

    • 👍: joltz, quentinlesceller, lehnberg

  • lehnberg: Ah the other way around, very nice.

  • yeastplume: I got that wrong, edited. 1 wallet, 1 address for now.

  • lehnberg: Oh. Ah.

  • lehnberg: Haha.

  • quentinlesceller: 👍 anyway.

  • lehnberg: Ok, that will do as well then I guess.

  • yeastplume: But easy enough to move to multiple addresses afterwards.

  • joltz: There is some complexity there that is better to get right than force something rushed.

    • 👍: lehnberg

  • yeastplume: Indeed and agreed. Current master has all of the slatepack tests in place so you can see examples of everything being output. Was hoping @joltz could have a look at any tweaks required to the armoring.

  • joltz: Sure, I should be able to sneak some time to take a look there today 👍

  • yeastplume: Great! So I'll just be doing the api and command line changes and prepare for beta.

    • 🚀: quentinlesceller

  • joltz: Sounds good 🚀

  • lehnberg: Parallel IBD @jaspervdm is away, but last time I heard there was some progress there.

  • lehnberg: relative kernel locks @antiochp.

  • antiochp: Pr for feature flagged initial impl is in review. I owe some responses to feedback. @quentinlesceller pointed out a couple of things we should add to RFC and 👍

    • quentinlesceller: Yep had the opportunity to take a look at your PR this morning @antiochp and overall everything looks good. Can't wait to test it :)

  • antiochp: There is an additional big PR to go after this is merged, just fyi. Still WIP as it relies on NRD kernels actually existing in codebase. And a small wallet PR to match the additional kernel variant in the enum (so it compiles). But wallet can and will effectively ignore NRD kernels for now.

    • 👍: quentinlesceller

  • lehnberg: All check marks in todo! 🚀 mimblewimble/grin#3303.

    • 🤩: joltz
    • 💅: antiochp

  • yeastplume: On http deprecation, was thinking of forcing a command line switch if you want to send via http(s). So sending will follow the slatepack flow, but if the address is an http address then you'll get a big warning telling you that this is being deprecated, and use the --I-know-http-is-being-deprecated flag and try again.

    • lehnberg: @quentinlesceller was saying sth last meeting about not breaking anything?
    • yeastplume: It will only break on the command line. Log warnings otherwise.
    • quentinlesceller: I'm ok with breaking command line but not the api if possible:)
    • yeastplume: No, the api will be the same.
    • lehnberg: Very nice then.
    • yeastplume: Cool. Not done anyhow, will do as part of command-line changes for slatepack workflow.

  • lehnberg: Okay so that’s the list then!

    • yeastplume: awesome!

  • lehnberg: What are we worried about slipping? With jasper away atm, we don't have good visibility in the parallel IBD stuff, but I reckon that's fairly contained. It was only a preparatory pr for future work in any case not the full parallel IBD.

    • 👍: antiochp
    • antiochp: Yes, the plan was for some of the p2p msgs for IBD. So just prep work. Having them in for HF3 would simplify further work but we can work around it if need be.
    • yeastplume: Okay, we just assume it's on track for now?

  • yeastplume: On my end, it might be a bit fiddly ensuring the command line changes are correct and according to the spec.

  • lehnberg: @antiochp the second PR for the NRD stuff that you mentioned, that's consensus breaking as well?

    • antiochp: it is yes, technically, but this initial PR disables it entirely on mainnet so consensus breaking only on floonet/testnet. WIP here - mimblewimble/grin#3302 (but that PR is the index only, not yet including the NRD rules driven by the index).
    • lehnberg: Okay. and feels good?
    • antiochp: Yes but, if it does slip we're still good with getting the ser/deser in from the first PR and if it does slip it only slips for floonet. tl;dr Ideally we activate this on floonet, but plan b is just to get the serialization changes in for support at network level.
    • lehnberg: Nice.
    • tromp: So on mainnet, NRD tx will not be relayed either, right?
    • antiochp: @tromp no, txs will be treated as invalid and dropped
    • tromp: Good
    • antiochp: "CorruptedData" at the network level as far as all mainnet nodes are concerned. We are discovering just how complicated a HF involving a consensus breaking change to tx kernels is with HF3 and to be honest this was significantly more complex than I originally assumed.
    • tromp: Good thing we find out now rather than near final HF stress
    • lehnberg: Definitely.
    • antiochp: Yeah agreed. Probably informs how we think about subsequent HFs also.
      • 👍: lehnberg, joltz

  • tromp: Btw, it's scary to me how fast beam is moving, with already confidential assets and payment channels planned for their next HF, in addition to lelantus.

    • antiochp: I think there are different approaches to this... I'm happy we are approaching this carefully.
    • lehnberg: Indeed, quite refreshing even, we're on both ends of the spectrum here.
    • yeastplume: Yes, and it's good to see different MW projects taking different directions.
    • antiochp: Even if it feels like I spent the past few months adding a couple of bytes to a kernel...
      • 😅: joltz, quentinlesceller
    • lehnberg: Those bytes will be there for quite a while potentially, so good that you are taking your time!

5. Anything 5.0.0 related

  • lehnberg: Just to recap where we are on soft forks there:

    To support arbitrary future kernel variants we would, by definition, need to allow arbitrary data.

    mimblewimble/grin#3317 (comment)

    This would be pretty much unavoidable if we were to support future kernel variants, no?

    • antiochp: Yes that's the big sticking point. Is it worth it?

  • antiochp: I think if we want to activate NRD "for real" in HF4 then we need a legit use case for it implemented at the same time. Aka we need wallet support for multisig etc.

    • tromp: I think a future new kernel type warrants a hard fork.
      • antiochp: From a simplicity and cleanliness perspective hard forks would appear a good fit for Grin
        • 👍: quentinlesceller
      • tromp: Although i can't for the life of me imagine what other type we could need.
      • antiochp: @tromp agreed - the theory here is adaptor sigs would be sufficient for any interesting additional features. That building "scripts" in via additional complexity on the kernels is a "bad thing".
      • yeastplume: I'm in this boat as well... If it's important enough to need a new kernel type, there will be much discussion and preparation needed, enough to meet and justify the barrier of a hard fork.

6. Other questions

6.1 Maximum inclusion height kernel

  • kurt2: Speaking of kernels.... May i ask if you think it would make sense to prepare for having the same security and trust models (objectively) as bitcoin by preparing an additional field to the kernel signature where we would put something like blockheight (to be determined) in the message, in order to facilitate verify that all kernel are different. It seems very natural to desire to enforce at consensus layer that utxos are fully controlled by their owner and cannot be spent by third parties without they asked about it, which looks possible today.

    The advantage of doing this at next hard fork is that an efficient algorithm could be used sooner on the blockchain history, and we do not need to have an actual algorithm soon. Rant finished. :)

    • yeastplume: @kurt2 I think you'd probably be better off speccing the proposal on the forum to give people a chance to digest what you're proposing.
    • antiochp: @kurt2 I'd argue no. In that the mimblewimble "summing" is what gives us the security model. But we should discuss in the post.
    • kurt2: Oki, I'll try to make a post.
      • 👍: lehnberg, antiochp
    • tromp: kurt2 is suggesting a mandatory maximum inclusion height kernel feature so that we can efficiently enforce unique kernels.
      • kurt2: Right. More efficient explanation.
      • antiochp: Ah so I misunderstood - let's discuss in the post. (good reason to do it there and not here...)
    • yeastplume: Yes, once we digest we can also bring it up as a subject in a later meeting. Okay, coming up on time, is there anything else anyone wants to bring up? Then that's it for now. Thanks everyone and back to the salt mines!

Meeting adjourned.