20200609-meeting-development.md

Meeting Notes: Development, Jun 09 2020

Development meeting held @ 3PM UTC in grincoin#dev channel on Keybase. Meeting lasted ~ 50 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
• joltz
• lehnberg
• phyro
• quentinlesceller
• tromp
• yeastplume

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

Agenda points & Actions

1. Retrospective

• yeastplume: Going to be a fairly quick reminisce today. Remember the time we released 4.0.0-beta.1? So most work has been in service of that. Some fixes and changes are still going on, and I'd hope we'd be in a position for a beta 2 at the end of the week, hopefully getting the last of any changes in once we've ensured the floonet swapover behaves correctly.

2. Agenda review

The proposed agenda was accepted without modifications.

3. Action point follow ups from previous meetings

3.1 Crates.io updated?

• yeastplume: So that being said, crates.io was updated by @quentinlesceller, who's now co-owner of the packages as well.
  • 👍: quentinlesceller, lehnberg

3.2 Release checklist

• quentinlesceller: Going to update the release checklist with that and address comments later today.

4. Status of Grin v4.0.0

• antiochp: When is floonet hf scheduled for?

  • quentinlesceller: 2020-06-19 18:49:36 +0000 utc. Last time I checked.
    • 👍: lehnberg, antiochp

• yeastplume: So gives us plenty of time for a beta 2.

• lehnberg: I'm going to try to test beta1 this week and report findings, it's been quite busy for me here dealing with baby-thormund.

  • 👍: yeastplume, quentinlesceller

• yeastplume: Do we need to go through the 4.0.0 list at this stage?

  • lehnberg: Don't think so, I will try to keep it up to date - which pr captures deprecate http listener for external addresses @yeastplume?

• yeastplume: I'm mostly just this to reflect recent slatepack changes (encrypted sender) mimblewimble/grin-wallet#428, then perhaps one or two small quality of life things that shouldn't affect transacting at all and that's it.

• antiochp: I'm hoping to get mimblewimble/grin#3302 in next day or so. Its a relatively big pr but should be fairly straightforward to test out as disabled on mainnet. If someone could help test out against mainnet and floonet prior to merging that would be 🙏.

  • quentinlesceller: I will.
  • lehnberg: If you think there's sth I would be able to pull off with your guidance, I'm happy to try in the next few days?
  • antiochp: Simply just testing that branch runs against floonet and mainnet.
  • lehnberg: Oh. Sync from scratch?
  • antiochp: I just want to ensure the various codepaths have been tested and that my local env is not weird in any way. Yeah sync from scratch is valuable testing.
  • phyro: Probably also creating nrds?
    • antiochp: No because we still pre hf.
      • 👍: phyro

• yeastplume: Ooh, btw that reminds me, if you're testing the wallet pre-fork on floonet use the --v4 flag to force input and output of v4 slates, otherwise you'll just get a v3 slate saved to file.

• yeastplume: With the v4 flag, you'll get the proper output to console to cut paste as well as a file.

• lehnberg: How about @antiochp and @yeastplume we produce test checklists? I think you started one in the forum post yeast, that was really helpful. But maybe even we do like actual commands, and be a bit detailed about it. 1. Sync a node, let it run for x hours. 2. Sync a node on branch x let it run for y hours.

  • 👍: antiochp, phyro

• yeastplume: That was slipped into mimblewimble/grin-wallet#423.

  • lehnberg: Ah cool I'll add to the list.

• yeastplume: Yea, I just added the point about the --v4 flag to the testing notes there. If only there was a qa theam.

• antiochp: Do we have a 4.0.0 branch or are we doing this off master for now?

  • yeastplume: 4.0.0 is building from master atm.
    • 👍: antiochp

• yeastplume: I'll put an issue with a more specific checklist for the wallet.

• lehnberg: Yeah, an issue might be nice, and then people can comment with their outcomes, hopefully only sweet green check marks.

• antiochp: If someone could test that branch out today I can get it merged it sooner rather than later and it would make further testing easier to coordinate. Checklist being - "full sync then let it run for a bit", "restart and let it run for a bit". On both mainnet and floonet. Multiple branches makes it harder to know who's testing what.

  • quentinlesceller: You mean this pr mimblewimble/grin#3302?
  • joltz: 👍
  • quentinlesceller: 👍
  • lehnberg: kernel_pos branch.
    • 👍: antiochp

• antiochp: I just need a second person testing it before I merge (to avoid breaking master).

  • quentinlesceller: Okay I'll take a look today.
  • joltz: I'll do that test today as well antioch if no one else testing.
  • quentinlesceller: Can't say I'll be able to review 2k loc though. 😂
  • antiochp: Yeah this "review" is going to happen as we go along. (Most of that is test coverage actually).

• lehnberg: Anything we're missing with 4.0.0? Quentin's been great putting up the banner on the website and alerting pools and miners. And exchanges.

• lehnberg: There's a beta2 in the oven from what I gather.

• tromp: A new grin-miner may not be ready until the last moment.

  • quentinlesceller: Do you need help for that?
  • tromp: No, I'm good.
  • quentinlesceller: 👍

• lehnberg: Define last moment?

  • tromp: Hoping it will be done in last week before hf.
    • 👍: lehnberg, quentinlesceller

5. Enforcing kernel uniqueness?

• antiochp: There have been a couple of conversations around that - I believe our current thinking is we solve this at the wallet level and not the protocol layer. This is to do with "replayable" txs.

  • lehnberg: Do we have an idea of what a full circled solution would look like yet? I believe there are still open questions around restoring right? (Btw some discussion about it in #crypto just scroll up a few lines, anyone who's curious.)
  • antiochp: The gap is a wallet cannot robustly identify "replayable" txs on restore - so @tromp suggests a wallet proactively self-spends old outputs. Or at least flagging them and suggesting the user does this.
    • 👍: lehnberg

• lehnberg: Yeah, could be "first in line" for spending.

• antiochp: Tl;dr it does not need to be solved at the protocol layer (kernel uniqueness).

• phyro: This means a restore would flag all the utxos it finds.

• lehnberg: True....

• antiochp: Any utxo older than the 1 week horizon would be (potentially) susceptible to replay. We also need to think through payment proofs in this context as well. I think. What does a "restore" actually mean if you have no payment proofs for any of the payments received.

  • yeastplume: Well, it means your wallet has control of those outputs.
  • antiochp: Except potentially not, for a short period of time.

• yeastplume: I'm not 100% up to speed with the entire conversation, so need to think about it more. I'm not sure I'm a fan of forcing or requesting the user to spend at any point for safety reasons, it seems clumsy.

• tromp: Should I make a post about the issue?

  • 👍: phyro, quentinlesceller
  • yeastplume: Yes, it might help to have a brief synopsis of all current thinking and proposed solutions.
  • joltz: Agree, it would be nice to have one thread to discuss/review this in. I'm also not crazy about having wallets do spends to prevent this but want to spend some time with it.

• phyro: The wallet solution could also be temporary as consensus rule can be added later if really needed.

• joltz: Just want to avoid cases of fund loss where we point to an obscure line in documentation somewhere saying they should have enabled a wallet feature or something to prevent it.

• lehnberg: Yes, would be good to understand alternatives, and what costs / trade-offs they come with.

• antiochp: I suspect there is no consensus rule that would be compatible with mw though - its not feasible to index all historic kernels. And 99.9% of the time replay is not going to be an issue.

• phyro: So making the wallet handle this seems ok and its better than rushing with new consensus constraints.

• lehnberg: Getting those outlined in the thread, would be helpful for sure.

• tromp: I think I'll start a new thread called "mitigating replay attacks". That will of course reference the existing thread.

  • 👍: antiochp, phyro, quentinlesceller, lehnberg, joltz, yeastplume
  • lehnberg: Sounds great.
  • yeastplume: Great, that would help a lot.

• yeastplume: Mmm probably need to understand this a bit more, but on restore, the only outputs you see are ones from which you can unwind the bullet proof. And as part of that you need to xor part of the recovered data with a value derived from your wallet master key. How could a replayer recreate that?

  • antiochp: If I send you funds from output a to output be (your output). And a is ever recreated then that tx can be replayed. So alice can send my a a 2nd time and trick me into thinking I received funds, when it can be sent to you via replay.
  • yeastplume: Ah okay, got it.
  • tromp: It can be replayed before you restore your wallet. So when you restore, you find be in utxo, but you alread spent be -> c earlier. I mean that's one of the problematic cases. There's others.

• phyro: Yes. If you get to a point in the transaction graph that already happened you can theoretically replay the subgraph that happened afterwards If you know the right values.

• antiochp: Restore is related because a full restore leaves your wallet blind to this. But its not caused by the restore.

  • 👍: yeastplume, phyro

• yeastplume: Okay, will be really good to have all of this summarized.

6. v5.0.0 related

• yeastplume: I guess the previous conversation counts as beyond v5.0.0 related.

7. Other questions

None.

Meeting adjourned.