-
Notifications
You must be signed in to change notification settings - Fork 334
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
- Loading branch information
Showing
2 changed files
with
173 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,171 @@ | ||
| **Table of Contents:** | ||
|
|
||
| - [Summary](#summary) | ||
| - [Editors Meeting Flow](#editors-meeting-flow) | ||
| - [February 23 2021 notes](#february-23-2021-notes) | ||
| * [Triage](#triage) | ||
| * [Last Check](#last-check) | ||
| + [PR15 - Extended Metadata](#Extended-Metadata) | ||
| + [PR62 - Update to CIP-0010](#Update-to-CIP-0010) | ||
| * [Review](#review) | ||
| + [PR61 - Update to CIP-0013](#Update-to-CIP-0013) | ||
| + [PR57 - Key Serialization formats](#Key-Serialization-formats) | ||
| + [PR66 - Fair Min Fees](#Fair-Min-Fees) | ||
| * [Discussions](#discussions) | ||
| + [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings) | ||
| + [PR64 - User-Facing Asset Fingerprint](#User-Facing-Asset-Fingerprint) | ||
| * [Close](#close) | ||
| - [Extra](#extra) | ||
| * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status) | ||
| * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram) | ||
| * [Understanding CIPs further](#understanding-cips-further) | ||
| ## Summary | ||
|
|
||
| Rough writeup of 2/23/21 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. | ||
| <sub>_Notes might contain errors or miss pieces - call out issues as needed_ | ||
| </sub> | ||
| Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/cips-biweekly) and [summarized](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. | ||
|
|
||
|
|
||
| ## Editors Meeting Flow | ||
| - [x] **Triage/Review**: Some CIPs might fall out of grace or not get updated, a CIP that hasn’t seen activity for 3 months should be checked on, and appropriate action taken. Ex: did any of the recent changes obsolete current CIPs? Consider ‘Active’ -> ‘Obsolete’ transitions.. | ||
| - [x] **Last Check**: Review of the PRIOR meetings Decisions - if no objection, apply change (effectively a two week lag from decision to action, as a grace period) | ||
| - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews) | ||
| PR -> ‘Draft’: Needs format + approval. | ||
| ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation. | ||
| ‘Proposed’ -> ‘Active’: Objective criteria as laid out observed, and consensus agreeing. | ||
| - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. | ||
| - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. | ||
|
|
||
| ## February 23 2021 notes | ||
| **Attending Editors**: Matthias, Sebastien, Duncan, Frederic | ||
|
|
||
| ### Triage | ||
| n/a | ||
|
|
||
| ### Last Check | ||
| #### Extended Metadata | ||
| ([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006) | ||
| **Frederic** - I think this was good to go but there were some questions to be answered. | ||
| **Matthias** - We agreed to merge this as a draft, it being tweakable afterwards - fields and others can be on a separate PR or management... | ||
| **Sebastien** - Good to go. | ||
| => Merge **NOW** | ||
|
|
||
| #### Update to CIP-0010 | ||
| ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010) | ||
| **S** - The main thing with this one was dealing with the merge conflicts. I think that's done. | ||
| **F** - This needed to be rebased. | ||
| **S** - Good to be merged pending a rebase. | ||
| **M** - I skimmed through this but nothing major blocking. | ||
| => Merging **NOW** / when rebased | ||
|
|
||
| ### Review | ||
| #### Update to CIP-0013 | ||
| ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013) | ||
| **F** - The separate competing [PR65](https://github.com/cardano-foundation/CIPs/pull/65)) is conflicting with this one.[PR61](https://github.com/cardano-foundation/CIPs/pull/61). | ||
| **Robert** - I was hoping that Nicolas would join us to discuss what he meant on how to resolve a conflict by using the stakepools as values rather than keys in a way that avoided an incompatibility between the UIR as he wanted to do it and expanding these links to multiple stake pools - he hasn't explained fully how it would work, and we're waiting to hear from him. Nicolas hasn't come back yet with a way to avoid that incompatibility. I do not believe there is a way of solving this imcompatibility. And really the best way to represent this all is a set of ordered pairs. And that's already the URIs with one value per discreet element: it makes sense for the pool names to be the keys and their portions to be the values. Since right now we have single pool links, none of them have values and there is only one of them, the suggestions he made weren't thinking about how it might expand for multiple pools. I was hoping the ideas could be simple enough to be explainable over github. This proposal was greenlighted a few weeks ago, and I would like to move this ahead if ok. This one is the most efficient representation that is least capacity for misinterpretation (and is easiest to parse and handle pathological cases). Not using ordered pairs would mean more complicated n-tuples.. you'd have a lot of complicated schemes. I feel Nico was trying to avoid headaches for the devs. | ||
| **S** - Nico cant join from time and due to load - but am sympathetic with his idea. Still I understand that tuples are a miss as well. Honestly either way is sub-par. The stakepool name as key does not make particular sense, but it's the easiest to implement as a shorthand. I know Nico feels reasonably strongly, I understand what he wants to do. For the 'stake' vs. 'delegate', I think Nico is right that we should use 'delegate' instead of 'stake'. It's only a few char diffs so 'delegate' is likley the most accurate. | ||
| **R** - So the way you would justify that for Stake pool links that aren't immediately used for delegation would be that you are "considering" delegating with them? | ||
| **S** - Yes. | ||
| **R** - What when Oracle pools come along? Won't people ask "why are Oracle pools called Oracles but Stake pools will be called delegate?" This might be another case where right now no convention might be ideal. | ||
| **S** - I don't see how Stake would be more accurate in either situation. | ||
| **M** - Isn't stakepool the most accurate? | ||
| **R** - That's what I have been saying, and is what I have been loading in the PR comments. I think the marketing ppl wants that their process suggest delegated POS - but we're talking about a different process here - this is a machine talking to another machine here. | ||
| **S** - I don't think that "Stake" is particularly accurate or representative. Rather Stake Pool... | ||
| **R** - I mainly feel strongly about the first discussion - switching value and pair. I'm happy to give way. | ||
| **F** - All for competing proposals - I feel this should be setup as last-check. The process of CIP review should be able to handle CIPs that some disagree with. | ||
| **S** - Fine with it - Just concerned about the commentorial explosion of "variations" of this... Although that might be unfortunate it might be unavoidable. We can deal with it then still. | ||
| **F** - This should probably be good to raise through the SPO Digest. | ||
| **R** - Great idea, but ba thing to wait for: the ammount of appathy for the relevance this has, has been astonishing. Let's not wait on feedback. As to PR65 - the [diff](https://github.com/nicarq/CIPs/commit/dd07c91017fec32700d94d65670565ffa076cd3a) is only a few lines and really not expanding. | ||
| **S** - If we merge both at the same time, there's a single URI scheme with tickername as the key - I am not sure it will matter as I don't think people are rushing to implement this anyways. Prpobably in the Yoroi extension mobile we will probably implement whatever Nicolas will be prefering. So the decision does not directly impact us. I say let's move both proposals in two weeks and we can adjust as needed. TLDR - mark both for merging. | ||
| => Moved to Last Check (to be merged in two weeks) (+ PR65 to last check concurently). | ||
|
|
||
| #### Key Serialization Formats | ||
| ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016) | ||
| **M** - This comes from discussions we had with Luke some time ago. We have basically many tools that operate on keys and they all have their own format of keys. Even more tools if you also consider Jormagandr at the time. I think it was just an attempt to come up with an increment on how to serialize the various parts of keys. Basically 'private keys' are a bunch of bytes, but when you start using extended private keys for hierarchical derivations as we do in wallet, there are other parts to keys such as the chaincode, which explains how you should serialize these things together... So Chaincode and private key instead of just private key. This here is capturing what is currently done and putting it in a CIP so that other ppl can reference it or reuse it. | ||
| **S** - I read through and it is fine. There is however a long comment in there that hasn't been addressed. | ||
| **M** - That comment is mostly about CIP5 though a bit irrelevant to the proposal maybe. | ||
| **S** - If you could write down what you just said, it would be stisfactory. (**M** We should definately address it). | ||
| **D** - Is this about BECH32 prefix hould be those sort of physical things or they should be about roles? | ||
| => Moved to Last Check (pending a comment reply by **M**) | ||
|
|
||
|
|
||
| #### Fair Min Fees | ||
| ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - potential CIP-0017) | ||
| **F** - This is about Minimum fixed pool fees. | ||
| **S** - I thing the same people that looked into the Curved pledge pool feel would be needed here since it changes profitability and so on... (Colin / Kevin) | ||
| **D** - This is a veery technical one and changing the fee changes some attacks on the system. There needs careful analysis by the right individual. | ||
| => Flag to relevant individuals and align a review with their help | ||
|
|
||
|
|
||
| ### Discussions | ||
| #### Non Centralizing Rankings | ||
| ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - potential CIP-0018) | ||
| **R** - I didn't want to see this die - as I understand it, and I am not the one who has compared and contrasted the ranking equations, this is incorporating an exponentially decaying average of pool results and with their potential as it already exists in the ranking algorithm, which would produce a mixture of Large and small pools at the top of the ranks. As someone whose pool has been struggling to survive, this could breakup the aggregation of stake within the longtime inertially saturated pools. Some people don't see it as a problem, some people conceived it as a nash equilibrium. I think the conception of a nash equilibrium might actually be working against Cardano rather than for it. I think I laid that out much in the comment, but this reflects the general apathy mentionned earlier: The pools, particularly the small pools, might feel there is a wall between the developers and the pools themnselves. And the smaller pools opinions should be included in those conversations. So maybe this would be a good proposal to bring up for SPO Digest. | ||
| **D** - My opinion is that often people make the request to the wrong place. I hear your complaints but the change needed is to the actual infrastructure. Not shooting the messengers, but rather requesting/campaigning for changing to the actual incentives of the system. This is what that CIP was actually doing. Shawn also wrote a separate CIP about actually changing the incentives (Curve Pledge) and it may make sense of reevaluating wether the ranking actually reflect the proper underlying incentives of the system. That's worth evaluating, but the bigger issues such as "what is the value of k" the complaints ought to be there... Specificlally on the ranking that is very relevant to consider that the expectation of k winners and we are not certain of who the winners will be - we shouldn't have a cliff edge at k, we should probably have a slopeoff. This CIP here tries to get rid of the assumption that there is k successfull pools. Which doesn't do anything to the underlying incentives. And the mathematics shows that this is what happens with the math setup. If we want 1000 SP then we need to set k as 1000. Suggest dirrecting the energy in the right place. | ||
| **R** - What I think we need is a smooth edge, not a cliff edge at k. | ||
| **D** - I agree with you. It would be perfectly reasonable to have one such CIP written. I was holding off on having conversations with Researchers... I haven't actually dug into the actual propopasals from thinking about removing the assumpitons. .. But yes, changing about which the k winners are and a smooth distribution in some grounded way.. | ||
| **R** - It should derive from the system itself. | ||
| **D** - Can we check in with Shawn and see if he wants to retire it or continue it in this current form? | ||
| => Flag to relevant individuals (Shawn, Researchers) add to review for next meeting. | ||
|
|
||
| #### User-Facing Asset Fingerprint | ||
| ([PR64](https://github.com/cardano-foundation/CIPs/pull/64) - potential CIP-0014) | ||
| **S** - This is already implemented in Cardano wallet and will be included in the March 1st HF. I would prefer this be merged sooner than later. I have read throuh and there doesn't seem to be strong opposition to it despite the one way nature of it. Looks like we will be implementing this in Deadalus and Yoroi also. | ||
| **M** - There are also a few SPOs waiting on that also. | ||
| **S** - The only concern was about using the Bech32 vs Bech32m - the newly modified bech32... | ||
| **M** - I think bech32 is just fine since we have been using it everywhere. And if we want to change it to bech32m it should be a more hollistic approach. | ||
| **D** - I agree if we can. What was the major change to that PR? The digest length down to 20? | ||
| **M** - Yes, and the fingerprint is not an input format, only meant for users, not machines. I tried to make it clear that for uniqueness you really want to use policyID. I also added test vectors - I feel this is a rather complete CIP as-is. | ||
| => Moving to Last Check | ||
|
|
||
|
|
||
|
|
||
| ### Close | ||
| => Merge **NOW**: [PR15 - "Stake Pool Extended Metadata"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) | ||
| => Merge **NOW**: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) Update to CIP-0010 | ||
| => Review next meeting: [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’) | ||
| => Review next meeting: [PR66 - "Fair Min Fees"](https://github.com/cardano-foundation/CIPs/pull/66) (tentative 'CIP-0017') | ||
| => _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013 | ||
| => _Last Check,_ Merge in two weeks: [PR65 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/65) - Update to CIP-0013 | ||
| => _Last Check,_ Merge in two weeks: [PR64 - User-facing asset fingerprint](https://github.com/cardano-foundation/CIPs/pull/64) - (tentative ‘CIP-0014') | ||
|
|
||
|
|
||
| --- | ||
| ## Extra | ||
|
|
||
| ### Current CIPs in the CIP repository and their status | ||
|
|
||
| |# |Title | Status | | ||
| | ----------------- |:----------------|:-------------------- | | ||
| | 1 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001) | Active | | ||
| | 2 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | ||
| | 3 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003) | Draft | | ||
| | 4 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004) | Draft | | ||
| | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | Draft | | ||
| | 6 | [Stake Pool Extended Metadata](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0006) | Draft | | ||
| | 7 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007) | Draft | | ||
| | 8 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008) | Draft | | ||
| | 9 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) | Draft | | ||
| | 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | Draft | | ||
| | 11 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011) | Draft | | ||
| | 12 | [On-chain SPO-to-delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) | Draft | | ||
| | 13 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) | Draft | | ||
| | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | ||
| | 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | Draft | | ||
| | 1853 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853) | Draft | | ||
|
|
||
| :bulb: - For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001). | ||
|
|
||
|
|
||
| ### CIP creation process as a Sequence Diagram | ||
| _"Alice has a Cardano idea she'd like to build more formally":_ | ||
|  | ||
|
|
||
| ### Understanding CIPs further | ||
| [](https://www.youtube.com/watch?v=q7U10EfqXJw) | ||
| [](https://www.youtube.com/watch?v=dnw7k7VKVyo) | ||
|
|
||
|
|
||
|
|
||
|
|
Oops, something went wrong.