Skip to content

Latest commit

 

History

History
112 lines (69 loc) · 6.1 KB

20190917-meeting-development.md

File metadata and controls

112 lines (69 loc) · 6.1 KB
Raw

Meeting Notes: Development, Sep 17 2019

Development meeting held @ 3PM UTC in grin/Dev channel on Gitter, full chat transcript here. 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
  • davidburkett
  • energyburn
  • georgieva_val_twitter
  • hashmap
  • jaspervdm
  • j01tz
  • lehnberg
  • quentinlesceller
  • tromp
  • yeastplume

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

Agenda points & Actions

1. Retrospective

  • yeastplume: I believe most of the work the past couple of weeks has been about the upcoming 2.1.0 release.

    On my side, it's been completing the wallet lifecycle APIs, several bug fixes around the node/wallet API secrets and confirming transactions by kernel in certain cases, which was causing an issue with transactions not confirming when there were no change outputs, that is nearly ready for review as well: mimblewimble/grin-wallet#220

    Just need to update the comments, but once that's in that's all we had for 2.1.0 done on the wallet side. Aside from the BIP39 entropy issue, which I don't think we're going to do anything about, other than say we considered it and decided against action.

    On the node side @antiochp has been at work on implementing variable sized kernels.

    • antiochp: Yes, it's broken out into 3 separate issues here:

      With PRs in various stages on completion for each. P2p and db stuff is relatively straightforward, the txhashset.zip changes are a bit more involved. This first one is ready for review - mimblewimble/grin#3034.

      Tl;dr: we're changing the binary serialization of kernels for more flexibility (and to save some space).

2. Agenda review

Proposed agenda accepted.

3. Action point follow-up

Initial HF2 comms has gone out: https://forum.grin.mw/t/grin-v3-0-0-upgrade-jan-2020/6036

4. Security

4.1 Audit status

  • j01tz: I got a reply about 5 minutes ago from Coinspect, apparently the last issue is now fixed!
    • lehnberg: Great!

4.2 Canaries

  • j01tz: Regarding canaries, the security RFC set it up as a canary for the security disclosure process (with only signatures from disclosure contacts). There was discussion about adding more core members to the canary and making it more of a project-wide canary as opposed to a security disclosure canary. This has some tradeoffs that may be worth discussing.
    • lehnberg: I might be just making things more complicated for no reason by suggesting a project wide canary. What’s the purpose of the security-disclosure-contact-only canary? To ensure that nobody discloses responsibly to a compromised contact?
    • j01tz: Disclosure contact only canary is more manageable and concentrated on a critical area. I think we would have biggest impact there with least risk the risk being a missed signature or changed message spreading FUD.
    • lehnberg: Anyone who thinks it’s a bad idea that we only do disclosure contact canaries?

Meeting did not object.

Decision: Removing Ignotus from security disclosure contacts
  • j01tz: Though that does bring up Ignotus, he won't be able to sign.
    • lehnberg: Should we remove Ignotus from the disclosure contacts?

Decision carried, with explicit support from DavidBurkett, antiochp, lehnberg, j01tz, yeastplume, quentinlesceller.

5. Status of open RFCs

5.1 Transacting via Tor Hidden Services

mimblewimble/grin-rfcs#24

  • yeastplume: I'm only just really turning my fuller attention now to the transaction exchange issue. I think we had vague notions of providing tor as an option via configuration of docker images to do the heavy setup, but that was years ago.
  • antiochp: I think we need to resolve the tor vs i2p question - it makes little sense to be using both, or proposing to use both. But maybe we do that by spiking a couple of different impls and playing around with them for a bit.
    • DavidBurkett: Not true. They each have their advantages and disadvantages. Tor is more suitable for wallets. I2p is more suitable for long-term connections, like nodes. Using tor for the node is harmful to Tor. Using i2p for the wallet is harmful to i2p.
    • antiochp: Totally understand you believe we should use both but there is a cost to doing that. We need to minimize dependencies in the long run, not add huge overlaps. I guess I'm not clear on why tor hidden services for long running nodes would be harmful to the tor network, but probably best discussed offline (from this meeting).
    • DavidBurkett: Slows down the tor network since all traffic has to go through exit nodes. But, yes offline works.

6. Release planning

7. Other questions

None.

Meeting adjourned.