Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 70 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
- dburkett
- joltz
- lehnberg
- quentinlesceller
- yeastplume
(apologies if I missed someone - submit a PR or contact @lehnberg to add)
- yeastplume: So quick retrospective of the last two weeks, we've released a few betas now and have been testing and ironing out a few issues. Overall I think things are mostly working as intended, with the odd hiccup here and there.
The proposed agenda was accepted without modifications.
- quentinlesceller: Done very simply. Followed lehnberg advices and rename to release_process.md. Which contains the different steps to follow for every new release. We might want to have a followup issue for every new release or maybe We can manage without it (as we did for now).
- yeastplume: Nice 👍 Is it finalized, seems there's still a bit of back-and-forth? I'll have a detailed look as well.
- quentinlesceller: It's a start:) thanks:)
4. Status of Grin v4.0.0
-
yeastplume: Remind me what the RC date is?
- quentinlesceller: 16-06? https://forum.grin.mw/t/grin-v4-0-0-network-upgrade-hard-fork-3-july-2020/7001.
- yeastplume: Well, that just flew by, didn't it?
- quentinlesceller: We are a bit late but however we found a pretty annoying issue during floonet hardfork that was just fixed. We = @antiochp:)
- antiochp: Yeah - I think we plugged the last hole there in terms of a smooth transition during hf3.
- yeastplume: Should we aim for rc at the end of this week?
- 👍: antiochp
-
lehnberg: My beta2 nodes have been running w/o hiccups. Only got some
fraudheightbanreasons in the logs tab. -
yeastplume: And I note we don't have a date in there for the actual 4.0.0 release.
- quentinlesceller: I'd say yes wdyt @antiochp.
- antiochp: Yeah lets do it.
- antiochp: I don't anticipate anything else getting merged to node between now and then - unless we uncover another fix.
- yeastplume: Okay. There's a small api change I want to get in tomorrow on the wallet, and I'll do up proper release notes.
- yeastplume: So we have a thread with plenty of lively discussions, but no definite decisions one way or another. Is this something we want to discuss right now or wait until 4.0.0 is a bit more out of the way.
- antiochp: I think we can hold off until after 4.0.0?
- yeastplume: Yeah, I think so, we can leave the thread going anyhow until then.
- 👍: antiochp
- antiochp: Its not an ideal situation, but its known and we need to think it though before getting ahead of ourselves with a fix.
- yeastplume: Agreed, we can defintely target 5.0.0 as the deadline.
- yeastplume: Similar conclusion on this point?
- antiochp: Yeah we need to discuss that one some more.
- yeastplume: There's an evolving thread, need to digest it myself before having an opinion.
- antiochp: (those are both additional ongoing tx related discussions that I forgot to list in my forum post)
-
lehnberg: There's a nascent attempt at a planning issue here: mimblewimble#287. So far proposals in there are
slatepack: Support for multi-party txsandtor Support for nodes. -
lehnberg: There's the wishlist thread on the forum: https://forum.grin.mw/t/wishlist-for-v5-0-0-the-last-of-the-scheduled-hard-forks/7238/23.
- 👍: quentinlesceller
-
yeastplume: I'm sure we all have plenty to add to that list, just haven't got around to putting them down.
- lehnberg: Yes, so might be good to start sketching some stuff out now, and try to get a grip on what our must-haves are. While still acknowledging that it's super early in the process.
- yeastplume: Yep, +1, will start getting those down once our rc is out, it's super early in the process but it's also time to start focusing on it, once everyone's had a chance to recover from 4.0.0.
-
lehnberg: Take parallel ibd for example. Afaik it's not consensus breaking, but it's thought to be "nice" to roll it out clean. Original idea was to get something out in 4.0.0 and then see it in production and fix the final stuff for 5.0.0.
- 👍: antiochp
- dburkett: I don't think stuff like this is too difficult to roll out without a hardfork.
-
lehnberg: Jasper, who was point, is still out of pocket and we're not sure when exactly he's coming back. So might make sense to do Some mitigation there. Or, maybe we say "you know what, we don't need this for 5.0.0 at all"? And just do it as part of 5.x?
- dburkett: We have protocol versioning and feature flags to manage that stuff.
- lehnberg: Yeah so it would be good to get us all aligned on how we want to go about stuff like this, well in advance before actual work on 5.0.0 kicks off. So we're sure we're working on what's most important for this year.
- 👍: dburkett, yeastplume
-
lehnberg: With that in mind, I think @antiochp's wish to go and explore wallet for a while now makes more and more sense to me. Even if it's not directly consensus breaking, he might uncover some stuff that will need consensus changes. But there might be similar areas in node land as well?
- 👍: yeastplume
- yeastplume: I do as well.
-
dburkett: Personally, I think we need to decide if we're going to add softfork support. If we are, that's top priority before the next hf. Additionally, we should determine if we're going to allow duplicate outputs, and prioritize that. Beyond those 2, which must be figured out before the last hardfork, then wallet approach seems reasonable.
- 👍: yeastplume
-
antiochp: Yeah duplicate outputs needs some discussion/decision early on after hf3. And does overlap with "coinbase outputs as transaction outputs" so we need to consider that also.
- 👍: dburkett
-
lehnberg: Re softfork: Is there any way around an approach where we end up supporting arbitrary data to chain? And if there is no way around it, how do we feel about that trade-off?
- dburkett: The best we can probably do is limit the amount of arbitrary data to 32 bytes, but that still causes other messiness. 32 bytes per kernel, that is.
-
lehnberg: If we cannot soft fork, that means we have to hard fork for such changes. Naively, could that "motivate" us to ensure we manage to hard fork? Or does it just mean We can never hard fork, i.e. We cannot soft fork either, and we're stuck with what we got. If we had an easy way to soft fork, I would imagine hard forks would hardly ever happen.
- dburkett: It's a risk.
- antiochp: Yes I think there is argument to be made that if we can only hf then we (as a community) may be more likely to make it actually happen if required.
-
dburkett: I suspect that if we don't include code for an additional, planned hardfork as part of the next hf, and we also don't include softfork support, then there will probably always be a grin (grin classic maybe) that follows the v5 consensus rules. But that assumes there's someone to actually lead that effort. With the currently low dev interest, maybe it wouldn't be a problem after all. But 5-10 years from now, who knows.
-
lehnberg: Yeah and that's another question to iron out once and for all as part of hf planning: Are we adding more planned hard forks or not? The current position I am estimating to be little support for additional scheduled hard forks. When we discussed it before, major arguments was "slippery slope, add one, you enable indefinite more to come" and "grin's baselayer should be immutable by default".
- yeastplume: I think the ecosystem is rightfully becoming weary of hardforks and large changes.
- quentinlesceller: What's the risk of adding another scheduled hard fork in a 1 year and half?
- lehnberg: That we'll keep doing it. Each time saying "last one, promise!".
- quentinlesceller: Mmm I see.
- yeastplume: And I would love the project to move into a mode where the base layer is established, the transaction flow is established and we can move on to refining without having to be almost solely focused on what has to go into the next hard fork.
- 👍: quentinlesceller
- quentinlesceller: I'm not a big fan of soft fork and I think emergency hard fork are doable.
-
antiochp: So yeah we would default to immutable with a requirement to do an unplanned, unscheduled hf if required (where presumably the bar is set pretty high for this).
-
joltz: It is impossible to prevent possibility of a hardfork. They will always be possible if there is a good enough argument made to community, miners etc.
-
lehnberg: I guess. Yeah I mean one argument which I think would be valid for more hf is if for some reason discover we need more time for something very specific. Example: We discover during q3 slatepack is a disaster, utter failure, We pivot to some dht style message store on the nodes → We need to make more consensus changes and we don't have time to do it.
- quentinlesceller: That'd likely not require a consensus change though?
- lehnberg: Maybe not! Seems like very few things do. Does it btw also make sense then to audit our consensus code at some specific date, giving us enough time to fix any issues uncovered? Or would a security audit be likely to uncover things that can be fixed without breaking consensus here?
- joltz: I would be surprised if one turned up anything that required a changing for the consensus rules but there could always be changes required to the implementation code, but this would not require consensus-breaking changes necessarily.
- 👍: lehnberg, antiochp, quentinlesceller
- lehnberg: Okay, good one less thing to worry about.
- joltz: Don't take that as a guarantee though!:)
- antiochp: Yeah its possible to discover we have de-facto consensus rules that differ from what we thought was going in (due to a bug).
- 👍: joltz
- joltz: I just mean the likelihood of something being turned up in an audit that we can afford, not the possibility of something existing at all.
-
lehnberg: Okay so still not seeing anyone making a compelling case for adding more scheduled hard forks beyond v5.0.0 (hf4). Of course, a situation might present itself that mandates this for whatever reason, but it doesn't look like there is one now.
- yeastplume: Don't need to take a decision just yet, but it feels like most are leaning toward immutability.
-
lehnberg: Is tor support on grin nodes consensus breaking? Not really right?
- joltz: Nope.
- 👍: lehnberg
- joltz: Nope.
-
lehnberg: What about dandelion changes?
- joltz: No, shouldn't be. Unless we make major changes with some kernel tricks or something.
-
dburkett: I think the softfork decision needs to be made first. If we decide to not support soft forks, I might lean toward adding a hardfork. Immutability works for bitcoin because it's flexible. Mimblewimble, and grin in particular, are not flexible at all.
- lehnberg: What kind of hardfork? Just one, scheduled at some point? What's the motivation?
- joltz: I don't necessarily think immutability and a possible future hardfork to add a new feature are mutually exclusive.
- dburkett: Yea, scheduled in the future to avoid contentious hardforks that could occur due to some new feature we decide we want to add (like bulletproofs+ or something). Anyhow, not a strong opinion. Just the way I would lean.
-
lehnberg: As long as we have scheduled hard forks, we're still not really in proper "production mode", I've come to realize. Exchanges and wallets will have issues supporting us, and there's a lot of friction (and distraction) at the lead up to those hfs. So if we add more, we should be aware of that at least, basically considering us still to be in "dev". And experimental.
- dburkett: Then eth isn't in production mode:) But yea, 6 month hardforks are horribly distracting.
- lehnberg: "immature" perhaps?
- antiochp: Yeah those are good points - these 4x 6 month hfs gave us opportunities to improve, but moving beyond them is good.
-
lehnberg: Okay so mindful of yeast kicking us out soon. There isn't really that many big ticket items we can identify at this point? What's the verdict on parallel ibd at this point? We think we can do it later? Would be really nice to get rid of those zip files...
- dburkett: It's absolutely doable at a later date. It's certainly a nice-to-have feature, but no need to coincide with a hf.
-
lehnberg: Hmm. Yeah so then @antiochp looking into multi-party transactions become... Even more relevant?.
- dburkett: Well, still have to focus on the duplicate outputs & coinbase outputs stuff first, imho. Those are still high priority. But beyond that, multi-party seems relevant. I suspect it's not going to require consensus changes though.
-
yeastplume: Let's all aim to get our wish list down before the next dev meeting, then we can start the process of sifting through them?
- lehnberg: Sure. Feel free to add ideas here and we can go through in next dev meeting mimblewimble#287
-
lehnberg: Coinbase outputs are consensus breaking?
-
dburkett: Yes. Coinbase outputs and duplicate outputs are both consensus breaking.
- 🎉: lehnberg
- 👍: antiochp, joltz, lehnberg
-
lehnberg: Soft fork proponents will need to build a case for it and why it makes sense and how the trade-off with allowing arbitrary on chain data is acceptable.
-
antiochp: Proponents of coinbase outputs as transaction outputs also need to convince everyone that immediately spendable coinbase is safe to do.
- lehnberg: Yes good point.
None.
Meeting adjourned.