Skip to content

Latest commit

 

History

History
253 lines (203 loc) · 17.5 KB

20200512-meeting-development.md

File metadata and controls

253 lines (203 loc) · 17.5 KB
Raw

Meeting Notes: Development, May 12 2020

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

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

Agenda points & Actions

1. Retrospective

  • yeastplume: So a quick reminisce: We've mostly been finishing up 4.0.0 definitions and working on their implementations, my part has mostly been on compact slates and testing the implementation of slatepacks. I'll let everyone else sound off on the bits they've been doing, as there's a bit too much for me to keep track of in my head right this moment, and I don't want to forget anyone's contributions.

  • antiochp: Nrd kernel RFC is almost done (some minor feedback to address) and we have corresponding pr(s) up for some of the impl work (done in parallel).

    • 🚀: yeastplume, lehnberg, joltz, hashmap, mably

  • tromp: I've only written a cuckarooz29 simpleminer so far. Which sufficed to verify the expected #solutions as being 1/84. Stared work on a cuda miner. Will be quite a bit slower than cuckaroom29.

    • 📉: antiochp
    • 🐣: lehnberg, joltz, hashmap

  • hashmap: Some storage improvements, in particular introducing a saner db schema which as a side effect allows us to have significantly less heap allocations.

    • 👍: antiochp, yeastplume, lehnberg, joltz, mably

  • lehnberg: And @joltz has been knee-deep in transaction building standards.

  • yeastplume: Awesome all around!

2. Agenda review

The proposed agenda was accepted, with the 5.0.0 placeholder struck.

3. Action point follow ups from previous meetings

3.1 Soft-fork discussion: initiated in a permanent place?

Actioned.

3.2 http(s) deprecation discussion: communicated properly to wider community?

Actioned.

4. Slatepack proposal

  • yeastplume: I'm happy with the direction this proposal is going.

  • joltz: Quick tl;dr for anyone: Slatepack is a workflow-based approach to transactions (as opposed to the existing open-ended "provide choices and hope for wise decisions" method-based approach). It combines the tor method and proposed armored slate method into a unified privacy-preserving workflow that should allow any grin users or services to successfully transact.

    • 🚀: antiochp, mably

  • tromp: Is slatepack agnostic to including multi-sig inputs&outputs?

    • joltz: It should not have any opinions there as designed.
    • tromp: Excellent :)

  • antiochp: So workflow in an abstract way, not a prescribed workflow?

    • joltz: It is a prescribed workflow to follow the 'slatepack standard'. Of course you can still manually use non-slatepack workflows.
    • antiochp: Just to @tromp's point - multiparty/multisig would involve initial round(s) for communicating nonce values.
    • yeastplume: Right, at the moment the workflow is optimised for single sender/recipient.
    • joltz: The workflow is more about an order of transport methods to attempt as opposed to exact steps for each round of transport.
    • antiochp: Cool - that makes sense 👍
    • yeastplume: Yes, it it just a manner of packing the slate for transport with metadata. Multisig will be an alternate flow, not yet defined.
      • 👍: joltz
    • joltz: It is just focused around transporting the slates, not the contents.

  • yeastplume: It's very important that everyone reads, absorbs, and comes back with whatever feedback they have on it. Cause if we deprecate https, that's it. This is how transactions are done.

  • joltz: Yes just wanted to put it out there again for folks to have time to digest. We may be stuck with it for a while so really want to make sure we can live with it.

  • lehnberg: My high level take on workflow:

    1. Send Amount of grin (to optionally provided Address)
    2. A) if Address: Encrypt slate and try Sending via tor
      • if tor fails: Present Encrypted slatepack string to share manually
    3. B) if no Address: Present unencrypted slatepack string to share manually.

    (address here also works as encryption key).

  • yeastplume: It's anticipated that this flow would be extended for multisig.

  • joltz: So workflow is really just: 1. Try to build over tor, 2. Exchange ascii armor if 1 fails.

  • tromp: For let's say 3-party txs, is slatepack expected to be passed aound from a->b->c, or could a send simultaneously to be and c and combine the return slates for a similar 2nd round?

    • joltz: If method 1 fails, yes it would need to manually be passed around.
    • tromp: That is, is it designed for round robin?
    • joltz: So the multiparty workflow would need to be established for how it is handled in both tor and for ascii armor slates. But that shouldn't change the overall slatepack workflow of: Try to first then fall back to ascii armor.
    • tromp: Round robin is simpler, but could be slower if both be and c take their time to pass slate back/on.
    • antiochp: I see any solution ending up pretty gnarly for 3 or more participants.
    • yeastplume: Right, it's not as if bitcoin multisig is particularly pretty at the moment either.
    • joltz: The hope is that it shouldn't be any more complex to design this for slatepack than existing methods since slatepack is just instructions for an order to attempt existing methods. But may require some extra engineering since one party might have a tor failure in the middle of building.
    • tromp: Ok, let's assume focus on 2-party for now while keeping n-party round robin generality in mind.

  • lehnberg: A lot of the usability question marks around the proposed approach will depend on how reliable tor will be for usage in this context, i.e. Not only how often both parties will use tor and be accessible, But also how often they will be synchronously online.

    The copy/pasting of an armored slatepack string is fairly robust as a fall-back option, I can't imagine many situations where it would fail. But in complex use cases it can be quite arduous to manually copy paste/strings back and forth.

  • lehnberg: @joltz / @yeastplume assuming the RFC matures fast, how much of slatepack can be included into 4.0.0? Or like, what's a reasonable mvp?

    • yeastplume: I think all of it, including encryption, why not?
    • lehnberg: Oh that would be amazing. That would give us a full six month period + another hard fork to fix any flaws. That's really great.
    • joltz: Yeast went into beast mode and much of this already seems implemented in a pr.
      • lehnberg: Beastplume.
        • 😶: antiochp
        • 😁: joltz
        • 👹: lehnberg, quentinlesceller
        • 😂: xiaojay
    • yeastplume: Sounds like a rival tribe.

  • yeastplume: Anyhow, will get that all coded according to the rfc, tweak, refine as much as we can before 4.0.0 then see how it goes.

    • joltz: Will you communicate with me any areas that can be cleared up from implementation perspective? As they come up.
    • yeastplume: Definitely, will likely have a set of changes once I'm done the first round of implementation.
      • 👍: joltz

5. Decision: Deprecate http(s)

  • yeastplume: I'm in favour of this provided:

    1. slatepack proves to at least be better than what we have now
    2. lock-free transactions are implemented soon after 4.0.0 and is proven to work.

  • joltz: The timeline is include warnings about deprecation in 4.0.0 and fully deprecate in 5.0.0?

    • yeastplume: Yes.

  • yeastplume: And also, that we're prepared for it with some recommended practices for exchanges on why we made these changes and how to migrate.

  • lehnberg: I'm definitely in favour of including a deprecation announcement message as part of 4.0.0. We can always retract if slatepack fails to be the savior We have been wating for.

    • joltz: Yes we are not forced into a corner we can't get out of until 5.0.0.

  • tromp: In addition to warning, can we require a flag --unsafe for continued http operation in 4.0.0?

    • 👍: joltz
    • yeastplume: For http, sure.
    • quentinlesceller: Can we just put a warning and not break anything for v4.0.0?
      • lehnberg: Yeah I guess any http automated flows might be disrupted by --unsafe. Yeah I'd be in favour of not breaking anything.
        • quentinlesceller: Yeah.
      • tromp: The idea is to start introducing small pain points.
      • lehnberg: Would it make a difference if local network was not requiring --unsafe? Or is that still not good enough?
      • quentinlesceller: No unsafe flag for now just a big warning would be enough imo.
      • lehnberg: Guess might be hard to determine what's local here.

  • quentinlesceller: With that in mind I agree to go through the http depreciation route as @yeastplume mentioned.

    • antiochp: 👍

  • yeastplume: Think this is consensus?

  • joltz: 👍 We can blame me if this doesn't go well. 🙃

  • yeastplume: Carried and no-further can kicking.

    • 🥫: lehnberg

  • yeastplume: For anyone on Exchanges who might be watching, we feel your pain, but believe this is better for the long term-health of grin. Exchanges should not be requiring clients to run http(s) listeners to withdraw funds, and we're coming up with a solution to make the locking of outputs in a wallet far less painful, which I think is a large reason why Exchanges may have decided only to implement the only synchronous method available.

  • joltz: Yes, one of the major goals is reducing required efforts from engineering and support teams. I want support tickets around tx trouble to be 0!

  • lehnberg: Yes, the wider ecosystem will benefit from having one way of talking to each other, one that doesn't rely on single point of failures. It would have been great to have had all this figured out before mainnet launched, but i believe the solution has become more informed after seeing usage in the wild.

    • 👍: yeastplume, joltz

6. Status of Grin v4.0.0

  • yeastplume: I want to break protocol entirely and say I think we need another p2 wallet issue, which is ensure 4.0.0 offset selection is future-compatible with lock-free transactions. If we want a chance at having lock-free transactions in the wild and tested for 5.0.0, this needs to be in place. It's not huge, It just means that we need to standardize on when the offset is chosen (at the beginning of signing round 2) instead of the current whoever's in first method. No issue created just yet. It's still bubbling. Also ensure the offset isn't applied to anyone's blinding factors as it currently is, instead of being passed around.

  • lehnberg: Is this consensus breaking? I'm worried we'll rush and miss something important and break transactions or make them unsafe or something.

  • yeastplume: No, when transacting with v3 slates, it will use the old method. When v4, it will use the updated offset selection. And the period whereby v3 will need to be supported will be short.

  • tromp: I fully support improved offset selection.

  • lehnberg: Will @tromp be available to sanity check the approach?

  • yeastplume: Yes he will.

    • 🚀: lehnberg

  • yeastplume: He will likely in the same place he is now for quite some time to come.

  • lehnberg: Okay, adding improved offset selection. Unless there are objections?

    • 👍: joltz, yeastplume, tromp, antiochp, mably

  • lehnberg: Shall we go line by line on rest?

    • yeastplume: Sure.

  • lehnberg: Cuckaroo tweak | @tromp I presume is on track.

    • tromp: Cuckarooz is not finished, still needs cuda impl (not so easy) and grin-miner impl (easy).Hope to have them done by end of month.

  • lehnberg: Compact slates | @yeastplume | mimblewimble/grin-wallet#317 mimblewimble/grin-rfcs#49. @yeastplume asked for reviews yesterday.

    • yeastplume: Yes, apologies for the size of it.
    • lehnberg: Any ideas on how we could test this?
    • yeastplume: You should just be able to check out the branch (or pr) and work away wIth It as usual. It should also be fully compatible wIth v3 wallets.
    • lehnberg: So what should we try to test here? Some transaction building between us? Anything else? Anything specific?
    • yeastplume: Nothing specific. The only real effect of the change is the compact the slate and workflow, but there shouldn't be much apparent to users just yet. So the usual transacting and transacting with older wallet should suffice. The slatepack changes will be more visible, that will involve command-line changes to how slates are sent.
    • quentinlesceller: Will have a look but it will takes a while to review.
    • yeastplume: Sure, understood.

  • lehnberg: Parallell ibd, @jaspervdm is not here but passed on that it was on track.

    • 👍: antiochp

  • lehnberg: Deprecate node api v1 | @quentinlesceller. That's merged I see.

    • quentinlesceller: 👍

  • lehnberg: Relative kernel locks | @antiochp.

    • antiochp: Will do final edits to RFC later today. And initial pr up for review - mimblewimble/grin#3303.
    • lehnberg: Is todo here mimblewimble/grin#3288 up to date?
      • 👀: antiochp
    • antiochp: Yes, been trying to keep that up to date.
    • lehnberg: Very nice.

  • lehnberg: Slate serialisation | @j01tz, @yeastplume armored slates | @j01tz, @yeastplume

    These should be merged and updated into a slatepack item, yes?

    • joltz: Correct 👍
    • yeastplume: Yes, I think so. Which is underway.
    • lehnberg: Guess we make it p1? Okay leave with me will update after meeting.

  • lehnberg: Okay and then we have announce deprecation for running http listener for external addresses? | @yeastplume, which we said is no longer blocked.

    • yeastplume: This is as good as announced.
    • lehnberg: So it's just a matter of adding that message I guess at this stage?
    • yeastplume: Pretty much. I could also make it play a very annoying sound every time you launch it.
      • 😁: joltz, quentinlesceller

  • lehnberg: Beta June 02. We think that's realistic? 3 weeks from now.

    • yeastplume: Think so.
    • joltz: Beastplume. 💪
      • 👾: quentinlesceller

7. Spring cleaning of grin PRs

  • quentinlesceller: There are 23 open prs on the grin repo. Most of them are valid and just needs review.

    • lehnberg: Do we want to add that to the mix pre 4.0.0 releasing?
    • antiochp: What @lehnberg said. Some may be good to go, but maybe not "now".
    • quentinlesceller: Okay. Can we identify the prs that can wait and those that can be merge for 4.0.0? I guess that would drag the meeting for way too long.
    • quentinlesceller: I'm going to compute a list and post it in node dev this afternoon.
      • 👍: antiochp
    • quentinlesceller: On my end this one mimblewimble/grin#3315, mimblewimble/grin#3323 (safe to merge).
    • quentinlesceller: mimblewimble/grin#3319 is safe to merge (I need to review it though).
    • lehnberg: 3315 is approved by hashmap already.
    • quentinlesceller: Yep wanted @jaspervdm review since he wrote that code. I need to test it with some other miners (already tested with grin-miner).
    • quentinlesceller: After that I'll merge. I'll come up with a list after in @grincoin.teams.node_dev.
      • 👍: lehnberg

  • lehnberg: But yeah I guess question is if these might as well could go into a 4.0.1 or 4.1.0. As any change, big or small, will add risk. And we're already looking tight and will have a lot of testing to get done by hf3.

    • quentinlesceller: Yes.

8. Releasing: Crates.io

  • quentinlesceller: So this is just a matter of pushing grin and grin-wallet v3.1.1 crates.

    • yeastplume: Right, I usually do that on a major release, but missed it for 3.1.1. So will take an action.

  • quentinlesceller: Basically I think we need a Release checklist like:

    1. Correct tagging of Grin in cargo.toml
2. Grin crates.io Release
3. Git tag Grin and push tag to trigger ci
4. Correct tagging of Grin-wallet in cargo.toml
5. Grin-wallet crates.io Release
6. Git tag Grin-wallet and push tag to trigger ci
7. Brew Update Grin and Grin-wallet (Brew bump-formula-pr)
8. Update packaging repo and Update snapcraft version. Release snap craft
9. Update website binaries and version.

    Not sure where it should be and whether we can/should automate it.

    • 👍: joltz, mably

  • yeastplume: We should definitely have a checklist for releases. I think parts of it can be automated, others might not be worth the pain, but there should be a documented process. That can be followed by anyone.

    • 👍: quentinlesceller

  • quentinlesceller: Where do you think it should be documented?

    • yeastplume: I think somewhere within grin-pm should be fine. Then we can have a release checklist for each release.
    • quentinlesceller: Okay I'll do it.
      • 🚀: joltz
    • yeastplume: Great!

9. Other questions

None.

Meeting adjourned.