Skip to content

Latest commit

 

History

History
202 lines (183 loc) · 19.1 KB

20200714-meeting-governance.md

File metadata and controls

202 lines (183 loc) · 19.1 KB
Raw

Meeting Notes: Governance, Jul 14 2020

Development meeting held @ 3PM UTC in grincoin#general 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
  • johndavies24
  • joltz
  • lehnberg
  • paouky
  • phyro
  • quentinlesceller
  • tromp
  • yeastplume

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

Agenda points & Actions

1. Agenda review

The proposed agenda was reviewed and accepted, with the addition of a "Play/replay working group" added to the "RFC & Sub-teams" point.

2. Action point follow ups from previous meeting

2.1 Funding requests processed?

Actioned.

2.2 Spending logs updated?

3. Documentation progress

  • lehnberg: I've not had a chance to complete the wiki audit myself, been slow progress on my front.
  • quentinlesceller: Documentation very little progress for the past week getting ready for v4. However after trying extensively readthedocs I think it's a too big burden to maintain compared to other simple markdown solutions.
  • lehnberg: Mm... I defo see where you're coming from.
  • quentinlesceller: That what stopped me mostly.
  • lehnberg: I think I need to look more at what other projects are doing.
  • quentinlesceller: There is basically sphinx and mkdocs.
  • lehnberg: There's defo friction around readthedocs.
  • lehnberg: Btw, is there a reason why we wouldn't want to have the rust one?
    • quentinlesceller: @lehnberg like the rust book https://doc.rust-lang.org/book/ch01-01-installation.html?
      • lehnberg: Yes. It's pure-rust docs implementation, sec... https://github.com/rust-lang/mdBook
      • paouky: Looks good.
      • quentinlesceller: Yeah that can be nice too. I think as long as we are going with markdown and start writing stuff we can quickly switch.
      • lehnberg: "pure" rust may have been a slight exagerration. Yup 👍 anyone interested is welcome to come and talk about it in #dev or #general.
  • quentinlesceller: Just I don't think we should start writing the whole doc in the language used by sphinx.
  • quentinlesceller: Anyway this is definitely on my short term todo but was a bit discouraged by the mess that sphinx is ^^
  • lehnberg: I can't blame you.

4. Code of conduct progress

  • lehnberg: Progress so far is non-existent. Will look at it post 4.0.0, there's a bunch of other more important stuff right now imo.
  • paouky: Maybe I can take it up. What does it entail remind me?
  • lehnberg: mimblewimble#309 specs it out quite well I think.
  • paouky: Got it. I'll see what I can do.
  • lehnberg: Great. Feel free to discuss in issue 👍

5. RFC & sub-teams update

5.1 General

5.2 Sub-teams

No update.

5.3 Play/Replay working group

  • lehnberg: Given the very active discussion we've been having about play/replay and variations. Recently. And the two "branches" of possible solution, one going towards consensus layer mitigation, the other going towards wallet-level mitigation. Let's put together a working group consisting of interested individuals that can hash this out and come up with a proposal (in the form of an RFC?) that we can then make a decision about.

  • quentinlesceller: Agree.

  • antiochp: I suspect reconciling two disparate solutions like this will be hard? Not entirely sure how a single RFC can emerge?

  • lehnberg: Good point. Maybe a single RFC would be premature. Perhaps instead an "information document" should be the deliverable. That outlines the issue, the known possible attacks we've identified so far, and potential mitigation strategies, alongside outline of their respective pros/cons. And, ideally the working group would based on that document, comes with a (subjective) recommendation, like:

    "we the working group believe we should go with x, because y, and z".

    And if that's not possible, then at least there could be something like:

    "the working group is split on this issue. Some think we should go with x, because y and z. Others think that a is more suitable, because b, and c."

  • antiochp: This is an interesting situation because I think this is the first time we have encountered a "problem" with two possible/potential competing solutions. Previous (vigorous) debates have been limited to "do we do x or not". Rather than "do we do x or y".

  • paouky: The only reason I see for a decision to be made is if somebody trustworthy and capable (who didn't participate yet) joins one side of the argument.

    • lehnberg: I'd be disappointed if we'd be unable to write a document that's unbiased on various positions, despite having our own subject personal opinions about what the right decision is.

  • antiochp: The "pro consensus change" camp has a big incentive to resolve this prior to hf4.

    • 👆: johndavies24

  • tromp: There's also the closely related RFC for allowing duplicate outputs.

    • lehnberg: Remind me again what the situation is with this. Is there a clear opinion for/against at this stage? Is it all contingent on approaches with play/replay?
    • tromp: The situation is that forbidding duplicate outputs can prevent txs from entering mempool. Which is considered undesirable in different circumstances. One being payment channels, the other being the tx expiry proposal.

  • lehnberg: That's why ideally you have people from "both camps" participating, so that you can agree on a common baseline of truth. If we can't agree on a common truth, then I struggle to see how we're going to make a valid decision.

    • paouky: I see your point, but I am skeptical. Some debates have two sides relying on two different basic assumptions (see bitcoin's block debate) that can't be translated into actual facts.
    • lehnberg: Your skepticism is noted, I hope we can make you positively surprised.

  • joltz: Maybe the working group can produce a "fact-finding" document which would be the basis to build potential rfcs.

    • 👍: quentinlesceller, lehnberg
    • lehnberg: Yes, exactly.

  • antiochp: "core" has veto rights here, right? 😇

    • lehnberg: On facts? Hardly.
    • johndavies24: I do not see the value you get from this statement when we all know it's true and add on top the many comments from many individuals about issues with the core. It makes "competing rfcs" seem like a futile and frustrating exercise that will not be fair or balanced.

  • antiochp: What @paouky said - there is a real risk we are starting from incompatible assumptions with this one.

    • lehnberg: I just don't see what assumptions have to do with facts. One can still outline a bunch of assumptions (that may differ), but they cannot have an impact on facts.

  • antiochp: Bitcoin block size is the canonical example here - facts don't necessarily resolve anything.

  • lehnberg: Are you saying that a 1 page (or 2 page) fact sheet about the various positions of the bitcoin block size debate is not possible to be produced?

  • antiochp: Possible to produce, but next to zero value. "Facts" are also inherently political but that's a whole other thing. (Not saying we are at that level of conflict, but its an example.)

  • lehnberg: Right now, I don't have a clear understanding of the trade/offs of each branch of proposal. It would be useful for me to understand what's good with each, and what cost each comes with. I don't think it's impossible to produce such a document without it being unbiased. I get that some have very strong opinions about what the correct solution is. I'm not one of those people. If someone is very convinced which way is the right one, it should be straight forward to outline the pros/cons with the approach. Am I the only one who would value such a document? If so maybe it's better I write it for myself instead.

  • paouky: It would definitely be valuable for people like you and me who don't understand entirely the whole situation and proposals. But it won't do much to convince either side I am afraid.

    • lehnberg: That's fine! That's not its purpose.

  • paouky: I agree its inevitable that whatever is decided, somebody will be against it.

  • joltz: It would be challenging to produce of both camps have already made up their mind unfortunately. I think part of the problem is that, at least for me, regardless of the details of the particular situation, a consensus change should always be the last possible resort. There is some nuance There that can be hard to get at with a "fact-finding" doc as far as how to convey this risk concisely and accurately for the given circumstances without spending a ton of effort.

    • johndavies24: I appreciate this sentiment, that consensus change should be the last resort. I would argue that the consensus is flawed and allows for behavior that does not exist in the industry. But more objectively, I would ask how one weighs the importance of fund/balance security and whether or not security of funds should be hardened in consensus rules? it is not as if our consensus rules are set and we now have to decide whether or not to change them, we are in a stage where we're literally expected to change consensus rules and we've changed them for far less reasons.

  • lehnberg: Well, the whole point of scheduled hard forks is to make consensus changes if required. How else are we going to figure out whether one is deemed required?

    • 👆: johndavies24

  • tromp: Some people are strongly opposed to having wallets offering the option to sweep outputs.

  • antiochp: Well if the problem can be solved without a consensus change then by definition it is not required (regardless of pros/cons of either approach).

  • joltz: Unfortunately "requirement" is subjective and we will get arguments for both.

  • lehnberg: Okay perhaps it's worth taking a step back here. Is there support for having a working group formed related to this topic? [...] Okay, if I interpret 2 minutes of silence as "no, there is no support", then... How are we supposed to reach a decision on this subject?

    • paouky: More people need to voice their opinion, so that one method seems to be of wider consensus. Then you just implement the contentious change.

  • quentinlesceller: Imo yes to produce a document outlining the problem and the possible solutions.

    • 👍: phyro

  • antiochp: I think a lot of people involved only feel there is a single solution here, one or the other.

    • lehnberg: Great. Can we get those two solutions on paper?.

  • phyro: I think the problem and attacks need some further research.

  • lehnberg: How is voicing an opinion helping if we can't even frame the issue properly?

  • phyro: There have been many new cases found in just the last month. In order to really capture the surface well and know what the best solution is, we might want to first understand the whole area very well.

  • paouky: It should be framed properly. I was just describing how a decision will be made eventually, even if its contentious.

    • 👍: lehnberg

  • lehnberg: Okay, so how do we move forward?

  • joltz: What about an RFC for each approach? Then they can both be hardened for review by rest of the community?

    • 👍: paouky, phyro

  • tromp: That seems best.

  • antiochp: I was going to suggest something similar - these are competing rfcs.

  • tromp: If an RFC makes a claim you disagree with, then you can open issue on that.

    • 👍: phyro

  • antiochp: Competing being too strong a word but also somewhat true. Conflicting rfcs.

  • joltz: Yes, only one could be accepted.

  • lehnberg: That's maybe great for both camps, but I think it's a shame to make it into a competition basically. Pitting one RFC and group of people against the other.

  • antiochp: Its how all of this has always worked - this is just the first explicit instance of it.

    • lehnberg: Yes, I get that some people have firm opinions, but I think there's also a group of people that do not have, and now have to "pick a side". It's exactly the type of thing I would want to avoid when it comes to making a decision.

  • joltz: Fwiw I will be contributing to both to make them as good as possible so we end up with the best possible option.

    • 👍: phyro, antiochp

  • tromp: Well, in the worst case, you end up with a fork.

  • lehnberg: And may do so prematurely.

  • antiochp: Yeah that's fair.

  • phyro: I think it's fine if some people say they are not satisfied with any of the presented solutions.

  • lehnberg: It's like calling a referendum in a country, it's not the best way to govern.

  • antiochp: Oof.

  • lehnberg: Seriously. If we're honest about trying to make the best decision. I'd expect us to work on outlining the pros/cons of each proposal.

  • joltz: Doesn't RFC provide the structure for that though?

    • lehnberg: No, it makes it really easy to spend time on the RFC you like the most. Rather than some spending time polishing one, others the other, and then we argue about which one is superior.

  • joltz: I would hope everyone would spend good faith effort on both but I guess that is not realistic.

    • johndavies24: I wrote a biased summary yesterday and learned/finally understood more points since then and have acknowledged the wallet solutions seem to cover the risks for the most part. I will write up an unbiased document and share it with tromp and antioch before everyone else to make sure it is fair.

  • lehnberg: Ignoring (at best) or sniping (at worst) the other. If you force these two groups to get into a "room" and try to agree on one document, you kind of force people to hear both sides of the story.

    • antiochp: I'd argue that's not an effective way to govern either.

  • phyro: Agree, it would seem fair to try to 'up' the other proposals as well.

  • lehnberg: Look, in the end, it's going to be a core decision. Correct?

  • lehnberg: How so? Depends I guess on what the deliverable is.

  • tromp: Can an RFC assume that duplicate outputs will be allowed? e.g. so as to simplify the example scenarios, or not having to conditionalize everything?

    • phyro: I'd suggest that in this case, there is a Duplicate outputs RFC and this RFC references it under "requires: Duplicate outputs" or smth.

  • antiochp: Yes, I see no reason not to make assumptions like this.

  • tromp: They were one of kurt's proposed rules.

  • antiochp: Making a contentious assumption would be different.

  • phyro: Duplicate outputs should also be challenged as part of it and would hence be nice for them to have its own rfc, otherwise you can't challenge this assumption it builds on. 🤷‍♂️

  • paouky: Damn this is complicated. Where is ignotus.

  • phyro: E.g. What kind of new replay attacks are possible with duplicate outputs.

  • tromp: Or how does a wallet represent duped outputs?

    • 👍: phyro

  • phyro: I'm confused what duplicate outputs even mean.

  • tromp: Having two utxo with identical commitment. At the same time.

  • phyro: Yeah but, I'd wonder... does a->a become valid? Does it not require a kernel?

  • tromp: Inputs must always be disjoint from outputs. I.e. cannot have same commitment.

  • antiochp: Let me clarify what I meant - I would assume there is going to be a "duplicate outputs" RFC and pending this, it is reasonable to make assumptions based on this. If we were to discover a compelling reason not to support duplicate outputs then this would impact subsequent work. (but we assume this is unlikely given what we know today).

  • phyro: That sounds good to me as long as there is a place to ask questions 👍

  • antiochp: As a counter example I would not think it wise to make assumptions based on us moving to bls signatures.

  • lehnberg: So coming back to the topic about the working group, obviously anyone is free to produce any RFC and submit it. There's been some show of support for having a working group on the subject, is there anyone against having it? Still not hearing anyone against having such a working group.

  • paouky: Who's on the other side of the argument right now? John and kurt? David as well?

    • 👋: phyro

  • paouky: Other side as opposed to tromp and antioch it seems.

  • lehnberg: Does it matter at this stage? I could be on the other side if it helps.

  • antiochp: Boo.

    • 😂: phyro

  • paouky: It matters to me, I want to know haha.

  • antiochp: Be right back - I'm being accused of trolling people on the forum.

    • 😂: paouky

  • phyro: I don't think this really matters as long as there are arguments laid out of both possibilities in the end.

    • paouky: True I suppose.

  • joltz: For me I thonk it is pretty obvious: Why potentially damage the security model when we have not been able to show That we need to risk it? That being said, we only have one more chance to make a consensus change like this and we want to be 100% sure we won't have to end up making a consensus change at some point anyway. So I think we still don't have all of the facts and information we need to say with 100% confidence that we know a set of wallet rules that will mitigate all possible issues. In the same way we are not ready to say a consensus change will mitigate all possible issues without creating new ones.

    • 👍: phyro

  • lehnberg: We have a #wg_moderation working group that's completely dead, so maybe we shouldn't set up a dedicated channel for it. Maybe I just call myself a member of this working group, and anyone who wants to can join in and we can work on some kind of fact sheet.

    • 👍: tromp, antiochp, phyro

  • antiochp: I'd argue this is not about being fair and balanced and "both sides", its about objectively evaluating two different approaches.

    • lehnberg: This I agree with.

  • lehnberg: But being objective imo is being balanced.

  • phyro: While I think I understand the rationale for consensus changing implementation, I'm afraid that rushing consensus changes could make us forget something even if it's something as simple as unique kernels. Let's not forget that replay attacks are actually really obvious and they seem to have been missed by everyone.

  • antiochp: And maybe those two different approaches need to be kept distinct and separate (just an argument against trying to produce a single doc).

  • phyro: I feel I need to clarify that my point is that crypto is hard, not that people are blind lol.

  • antiochp: To be fair I think it says somewhere in our docs "don't reuse outputs as they are at risk of replay". Which does not cover the entire "replay attack" but is close. Pretty sure igno put that in there early.

  • phyro: Ah, my bad!

  • tromp: Should also say: Beware of others reusing outputs on you:)

    • 😂: phyro

  • antiochp: That's the "new" part we missed I think...

6. Other questions

None.

Meeting adjourned.