-
Notifications
You must be signed in to change notification settings - Fork 331
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* 02-09-21 meeting notes * formatting / spacing
- Loading branch information
Showing
2 changed files
with
161 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,159 @@ | ||
| **Table of Contents:** | ||
|
|
||
| - [Summary](#summary) | ||
| - [Editors Meeting Flow](#editors-meeting-flow) | ||
| - [February 9 2021 notes](#february-9-2021-notes) | ||
| * [Triage](#triage) | ||
| + [PR15 - Extended Metadata](#Extended-Metadata) | ||
| * [Last Check](#last-check) | ||
| + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format) | ||
| + [PR61 - Update to CIP-0013](#Update-to-CIP-0013) | ||
| * [Review](#review) | ||
| + [PR62 - Update to CIP-0010](#Update-to-CIP-0010) | ||
| + [PR57 - Key Serialization formats](#Key-Serialization-formats) | ||
| * [Discussions](#discussions) | ||
| * [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/9/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 9 2021 notes | ||
| **Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic. | ||
|
|
||
| ### Triage | ||
| #### Extended Metadata | ||
| ([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006) | ||
| **Frederic** - Work (and new commit) has happened since the last time, specific to the points raised for the PR. | ||
| **Markus** - (PR Author) - It took a long time, but I tried to address all comments - I reduced the proposals to a min verision of the Json schema. Although it might not fit all expectations - it should give some initial extended metadata and I hope we can merge and bring it to an actual proposal. | ||
| **Duncan** - I looked at it two weeks ago, what has changed? | ||
| **M** - There was a request to make it clear that this was stakepool metadata not on-chain metadata. I added explainer for the Cardano CLI used to generate signatures. What is missing here is what prefix should be used for the the extverification key: I don't thing we should define a special prefix just for this - Any thoughts? Should it be Bech32 format and if yes what prefix? I looked at other prefixes and didn't know if I should ppropose a specific/proper one for metadata or use ad-hoc.. | ||
| **D** - I would follow the style of the CIP that logs all existing Bech32 prefixes... (CIP-0005) | ||
| **M** - I need a specific prefix for this one though. | ||
| **D** - What is the ExtV key, is it just an ordinary verifciation key? | ||
| **M** - Yea. I don't believe it should be anything special. | ||
| **D** - If you look at CIP 5 (which keeps track of the Bech32 prefixes), the style we use (to log all bech32 prefixes) is by purpose, not by format... pool operator verificationkey is a good example, ... | ||
| **M** - So you believe it's worth adding something like poolEVK or other | ||
| **D** - PoolMetada or PoolVK.... | ||
| **M** - I'll try to add it to CIP 5. | ||
| **D** - just add it to your current PR, we can update CIP5 accordingly afterwards if that goes through. | ||
| **M** - I added the Json schema for this minimal version. What is missing is I want to change the PR Title, and since I am not the original Author... | ||
| **D** - I can change it right now, what to? | ||
| **M** - "CIP-0006 Pool Operator Extended Metadata". | ||
| **D** - Done. | ||
| **M** - Not sure if merged now it'll attract more people... Portals like PoolTool are able to implement it, and I hope SPOs start using this format. I addressed most comments, the only left was really the prefix thing. For me that should be it, but open to any questions or comments. There is also an example in there, in the interest of implementers, to see how it works. The Json schema is also pretty restricted, with min/max lengths, description of what fields should contain, logo as a URL to a file, with limit on File Size probably on the service-consuming application like PoolTool to decide how they want to handle a 30mb logo... | ||
| **D** - In the on-chain metadata, you got 'ExtVKey', did you intend that to be a 'raw verification key hash' or the actual verification key? | ||
| **M** - From the 3 new files, the public key for verification... The ExtVKey is what is generated with the new prefix... PoolMDVKey. It is put in the main metadata, a source of public information source so 3rd party applications can use it to link to verify. It's the actual key (not the hash). It's used to verify the signature that is in the main metadata file. | ||
| **D** - Do we describe anywhere what those verification steps are? It should be spelled out explicitely. | ||
| **M** - In the document, it says "The Operator first has to extend a data Json file and a data signature created by this CLI commands, and how it has to be published and the ExtVkey as field in the main metadata file... This is what he has to do one time to setup the extended metadata for that pool, and from there he can do with the CLI from there. | ||
| **D** - Because this is security-sensitive, let's be explicit: it should be unambiguous how to verify the content of the extended metadata. | ||
| "What is the format of the ExtV key / what is its content?" i.e. it's exactly a 32 byte ed25519 verification key. "What's the data we expect to find at the end of the extSig URL?" i.e. it is a 64 byte ed25519 signature. "How do we verify one?" through ordinary ed25519 verification using the known public key that's part of the normal metadata against (..) the data url we find at the end of the data signature url. What software implementing this specification needs to do. | ||
| **M** - I don't have the CLI command at the moment. | ||
| **D** - This isn't about the CLI but rather as to what needs to be done for the applications wanting to comply by this specification. Would have no problem merging once that is in. | ||
| => to Last Check (to be merged next meeting) | ||
|
|
||
| ### Last Check | ||
| #### Catalyst Registration transaction metadata format | ||
| ([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014) | ||
| **Sebastien** - I had the Catalyst team try and review this with the time they had, and got thumbs up emojis. Again that's not super indicative, but I got Samuel to review it and he said it was fine and added an extra part re: Fund3, as 3 will work slightly different from Fund2. There was one point still unresolved about the addition of a new key: "61286". It's still missing from this CIP, which is assumedly OK: it can be added at a later point. Tentatively reserved the number inside CIP10. Once we get a better format description of the reward payout (which is different from the registration payout anyways) we should be fine - this shouldn't block the merging of this CIP. | ||
| **F** - Minor comment re: the difference of the sidechain vs mainchain (..) | ||
| **S** - Agree to an extend, but good enough to merge as-is. | ||
| => Merge **NOW** | ||
|
|
||
| #### Update to CIP-0013 | ||
| ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013) | ||
| **F** - This is an update to CIP-0013 | ||
| **S** - Nicolas made a competing separate PR (63?) to this one earlier today. PR61's author commented on Nico's PR, there hasn't been a clear resolution at this point, let's let both CIP authors agree on which standard to use from here. | ||
| => To be reviewed the following meeting | ||
|
|
||
| ### Review | ||
| #### Update to CIP-0010 | ||
| ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010) | ||
| **Marek** - We are using the CIP10 in our scripts and were looking for a way to make it a bit easier for scripting, because parsing the markdown is challenging. This request here is to move it from human-readable to machine-readable. One suggestion from last meeting was to not keep two versions to prevent inconsistencies. I did that and moved everything to the json itself (except for the reserved values). | ||
| **S** - What we can do is merge the metadata registration CIP first, then rebase this one and add the missing parts to it (the metadata registration CIP modifies CIP10 as well.) I think this is fine to merge. | ||
| **D** - Approved this PR, also noted that we must figure out the order of the PR for the conversion. | ||
| => Moved to Last Check (to be merged in two weeks) | ||
|
|
||
| #### Key Serialization Formats | ||
| ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP) | ||
| **F** - Luke was working on this, not sure if someone have been able to hop on this. | ||
| **D** - Others have been commenting and Luke has done some updates.. I haven't gotten around to looking at it recently. | ||
| **S** - Not familiar enough either. | ||
| => Move to REVIEW for next meeting. | ||
|
|
||
|
|
||
| ### Discussions | ||
| #### CIP7 - Curve Proposal parameter discussion | ||
| **Colin** - Hi all, I am following up on 'a0' from CIP7 - I have been speaking with Catalina and Shawn McMurdo. The actual spec was not one that research was comfortable with, they came back with a counter proposal that I talked Shawn through (and he was happy with that). Should this be an update to this CIP? | ||
| **D** - If it's more than a small tweak, it should be a separate CIP. | ||
| **C** - OK. It's a different approach: To use a flat curve pledge benefit entirely, removing the scaling. | ||
| **D** - It would be nice to include some of the supporting research, from you, Lars and the folks who have dug into this - good to include or reference if feasible. | ||
| **C** - Should be able to add in there. | ||
|
|
||
| #### PR64 - User-facing Asset Fingerprint - tentative CIP-0014 | ||
| **D** - There's been lots of discussion happening on this PR already. This is one that Matthias is proposing but this is about the upcoming multiasset functionality and how we present assets to users. The basic suggestion is that despite the underlying solution that there is a policy hash, up to 32 bit hash for an asset per a single policy, Matthias suggestion here is - although the asset sub-identifier can in principle contain user element - we should make one opaque identifier and make it bech32. There are arguments wether it should be a hash or other: those identifers should be a non-readable blob. People in there are arguing about the details. This is related to the Metadata registry. This here is about how you display the information when you don't have the registry - Particularly good to get Sebastien to look into it. | ||
| **S** - I looked at the discussions and all pts I would have raised appear to have been raised... | ||
|
|
||
|
|
||
| ### Close | ||
| **On Hold** ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013) | ||
| => Merge **NOW**: [PR58 - "Catalyst Registration transaction metadata format"](https://github.com/cardano-foundation/CIPs/pull/58) ('CIP-0015') | ||
| => Review next meeting: [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’) | ||
| => _Last Check,_ Merge in two weeks: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) (Update to CIP-0010) | ||
| => _Last Check,_ Merge in two weeks: [PR15 - "Stake Pool Extended Metadata"](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) | ||
|
|
||
|
|
||
| --- | ||
| ## 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 | | ||
| | 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 stake pool operator 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) | ||
|
|
||
|
|
||
|
|
||
|
|
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