Repository: cardano-foundation/CIPs Branch: master Commit: 5c29bb73d8ae Files: 430 Total size: 5.1 MB Directory structure: gitextract_2tm41wvl/ ├── .gitattributes ├── .github/ │ ├── CIP-TEMPLATE.md │ ├── CPS-TEMPLATE.md │ ├── CPS-VALIDATION.md │ ├── schemas/ │ │ └── cps-header.schema.json │ ├── scripts/ │ │ └── validate-cps.py │ └── workflows/ │ ├── cip10-validation.yaml │ └── cps-validation.yaml ├── BiweeklyMeetings/ │ ├── 2020-07-01.md │ ├── 2020-07-15.md │ ├── 2020-08-04.md │ ├── 2020-08-11.md │ ├── 2020-08-25.md │ ├── 2020-09-08.md │ ├── 2020-09-22.md │ ├── 2020-10-06.md │ ├── 2020-10-20.md │ ├── 2020-11-03.md │ ├── 2020-11-17.md │ ├── 2020-12-08.md │ ├── 2021-01-12.md │ ├── 2021-01-26.md │ ├── 2021-02-09.md │ ├── 2021-02-23.md │ ├── 2021-03-16.md │ ├── 2021-03-30.md │ ├── 2021-04-13.md │ ├── 2021-04-27.md │ ├── 2021-05-11.md │ ├── 2021-05-25.md │ ├── 2021-06-08.md │ ├── 2021-06-29.md │ ├── 2021-07-20.md │ ├── 2021-08-03.md │ ├── 2021-08-17.md │ ├── 2021-09-07.md │ ├── 2021-09-21.md │ ├── 2021-10-05.md │ ├── 2021-10-19.md │ ├── 2021-11-09.md │ ├── 2021-11-23.md │ ├── 2021-12-07.md │ ├── 2021-12-21.md │ ├── 2022-01-11.md │ ├── 2022-01-25.md │ ├── 2022-02-15.md │ ├── 2022-03-01.md │ ├── 2022-03-15.md │ ├── 2022-04-05.md │ ├── 2022-04-12.md │ ├── 2022-05-10.md │ ├── 2022-05-24.md │ ├── 2022-06-07.md │ ├── 2022-06-28.md │ ├── 2022-07-05.md │ ├── 2022-07-19.md │ ├── 2022-08-02.md │ ├── 2022-08-16.md │ └── 2022-09-06.md ├── CIP-0001/ │ ├── CIP-0001.md │ └── README.md ├── CIP-0002/ │ ├── CIP-0002.md │ └── README.md ├── CIP-0003/ │ ├── Byron.md │ ├── CIP-0003.md │ ├── Icarus.md │ ├── Ledger_BitBox02.md │ └── README.md ├── CIP-0004/ │ ├── CIP-0004.md │ └── README.md ├── CIP-0005/ │ ├── CIP-0005.md │ └── README.md ├── CIP-0006/ │ ├── CIP-0006.md │ ├── README.md │ └── schema.json ├── CIP-0007/ │ ├── CIP-0007.md │ ├── README.md │ └── rewards.php ├── CIP-0008/ │ ├── CIP-0008.md │ └── README.md ├── CIP-0009/ │ ├── CIP-0009.md │ └── README.md ├── CIP-0010/ │ ├── CIP-0010.md │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0011/ │ ├── CIP-0011.md │ └── README.md ├── CIP-0012/ │ ├── CIP-0012.md │ ├── README.md │ └── schema.json ├── CIP-0013/ │ ├── CIP-0013.md │ └── README.md ├── CIP-0014/ │ ├── CIP-0014.md │ └── README.md ├── CIP-0015/ │ ├── CIP-0015.md │ ├── README.md │ ├── schema.cddl │ └── test-vector.md ├── CIP-0016/ │ ├── CIP-0016.md │ └── README.md ├── CIP-0017/ │ ├── CIP-0017.json │ ├── CIP-0017.md │ └── README.md ├── CIP-0018/ │ ├── CIP-0018.md │ └── README.md ├── CIP-0019/ │ ├── CIP-0019-byron-addresses.cddl │ ├── CIP-0019-cardano-addresses.abnf │ ├── CIP-0019.md │ └── README.md ├── CIP-0020/ │ ├── CIP-0020.md │ └── README.md ├── CIP-0021/ │ ├── CIP-0021.md │ └── README.md ├── CIP-0022/ │ ├── CIP-0022.md │ └── README.md ├── CIP-0023/ │ ├── CIP-0023.md │ ├── README.md │ └── minfees.php ├── CIP-0024/ │ ├── CIP-0024.md │ └── README.md ├── CIP-0025/ │ ├── CIP-0025.md │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0026/ │ ├── README.md │ └── schema.json ├── CIP-0027/ │ ├── CIP-0027.md │ └── README.md ├── CIP-0028/ │ └── README.md ├── CIP-0029/ │ ├── CIP-0029.md │ ├── README.md │ ├── phase-1-monetary-scripts.cddl │ └── phase-1-monetary-scripts.json ├── CIP-0030/ │ ├── README.md │ └── extensions-register.md ├── CIP-0031/ │ └── README.md ├── CIP-0032/ │ └── README.md ├── CIP-0033/ │ └── README.md ├── CIP-0034/ │ ├── README.md │ ├── registry.json │ └── schema.json ├── CIP-0035/ │ └── README.md ├── CIP-0036/ │ ├── README.md │ ├── schema.cddl │ └── test-vector.md ├── CIP-0037/ │ └── README.md ├── CIP-0040/ │ └── README.md ├── CIP-0042/ │ └── README.md ├── CIP-0045/ │ └── README.md ├── CIP-0049/ │ └── README.md ├── CIP-0050/ │ └── README.md ├── CIP-0052/ │ ├── README.md │ └── Tx-spec.md ├── CIP-0054/ │ └── README.md ├── CIP-0055/ │ └── README.md ├── CIP-0057/ │ ├── README.md │ └── schemas/ │ ├── README.md │ ├── plutus-blueprint-argument.json │ ├── plutus-blueprint-parameter.json │ ├── plutus-blueprint.json │ ├── plutus-builtin.json │ └── plutus-data.json ├── CIP-0058/ │ └── README.md ├── CIP-0059/ │ ├── README.md │ └── feature-table.md ├── CIP-0060/ │ ├── README.md │ └── cddl/ │ ├── version-1.cddl │ ├── version-2.cddl │ └── version-3.cddl ├── CIP-0067/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0068/ │ ├── README.md │ ├── extension_boilerplate.md │ └── ref_impl/ │ ├── README.md │ ├── offchain.ts │ └── onchain.hs ├── CIP-0069/ │ └── README.md ├── CIP-0071/ │ ├── README.md │ └── example/ │ ├── voting.html │ └── voting.js ├── CIP-0072/ │ ├── README.md │ ├── version_2.0.0_offchain.json │ ├── version_2.0.0_onchain.cddl │ └── version_2.0.0_onchain.json ├── CIP-0074/ │ └── README.md ├── CIP-0075/ │ ├── FairStakepoolRewards.xlsx │ ├── README.md │ └── UnsaturatedPledgeBenefitPenalty.xlsx ├── CIP-0080/ │ └── README.md ├── CIP-0082/ │ ├── ImprovedRewardsSchemeParameters.xlsx │ └── README.md ├── CIP-0083/ │ ├── README.md │ ├── codesamples/ │ │ ├── democode-BASH.sh │ │ ├── democode-NODEJS.js │ │ ├── democode-PHP.php │ │ ├── democode-WEB.js │ │ ├── encrypted-message-metadata.json │ │ └── normal-message-metadata.json │ └── format.cddl ├── CIP-0084/ │ └── README.md ├── CIP-0085/ │ └── README.md ├── CIP-0086/ │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0088/ │ ├── CIPs/ │ │ ├── 0025/ │ │ │ ├── CIP25_v1.cddl │ │ │ ├── CIP25_v1.json │ │ │ ├── CIP25_v1.schema.json │ │ │ └── README.md │ │ ├── 0026/ │ │ │ ├── CIP26_v1.cddl │ │ │ ├── CIP26_v1.json │ │ │ ├── CIP26_v1.schema.json │ │ │ └── README.md │ │ ├── 0027/ │ │ │ ├── CIP27_v1.cddl │ │ │ ├── CIP27_v1.json │ │ │ ├── CIP27_v1.schema.json │ │ │ └── README.md │ │ ├── 0048/ │ │ │ ├── CIP48_v1.cddl │ │ │ └── README.md │ │ ├── 0060/ │ │ │ ├── CIP60_v1.cddl │ │ │ └── README.md │ │ ├── 0068/ │ │ │ ├── CIP68_v1.cddl │ │ │ ├── CIP68_v1.json │ │ │ ├── CIP68_v1.schema.json │ │ │ └── README.md │ │ ├── 0086/ │ │ │ ├── CIP86_v1.cddl │ │ │ └── README.md │ │ ├── README.md │ │ ├── common/ │ │ │ ├── CIP88_Master_v1.cddl │ │ │ ├── CIP88_Master_v2.cddl │ │ │ ├── CIP88_Master_v2.example.json │ │ │ ├── README.md │ │ │ ├── Token-Project-Details_v1.md │ │ │ ├── token-project-details_v1.cddl │ │ │ ├── token-project-details_v1.schema.json │ │ │ └── uri-array.schema.json │ │ └── template/ │ │ ├── CIPXXXX_v1.cddl │ │ ├── CIPXXXX_v1.json │ │ ├── CIPXXXX_v1.schema.json │ │ └── README.md │ └── README.md ├── CIP-0089/ │ └── README.md ├── CIP-0091/ │ └── README.md ├── CIP-0093/ │ ├── README.md │ └── json/ │ └── payload-schema-v1.json ├── CIP-0094/ │ └── README.md ├── CIP-0095/ │ └── README.md ├── CIP-0099/ │ └── README.md ├── CIP-0100/ │ ├── README.md │ ├── cip-0100.common.jsonld │ ├── cip-0100.common.schema.json │ ├── example.body.json │ ├── example.body.nq │ ├── example.json │ └── test-vector.md ├── CIP-0101/ │ └── README.md ├── CIP-0102/ │ └── README.md ├── CIP-0103/ │ └── README.md ├── CIP-0104/ │ └── README.md ├── CIP-0105/ │ ├── README.md │ ├── test-vectors/ │ │ ├── test-vector-1.md │ │ ├── test-vector-2.md │ │ ├── test-vector-3.md │ │ └── test-vector-4.md │ └── test-vectors.md ├── CIP-0106/ │ └── README.md ├── CIP-0107/ │ └── README.md ├── CIP-0108/ │ ├── README.md │ ├── cip-0108.common.jsonld │ ├── cip-0108.common.schema.json │ ├── examples/ │ │ ├── no-confidence.body.jsonld │ │ ├── no-confidence.body.nq │ │ ├── no-confidence.jsonld │ │ ├── treasury-withdrawal.body.jsonld │ │ ├── treasury-withdrawal.body.nq │ │ └── treasury-withdrawal.jsonld │ └── test-vector.md ├── CIP-0109/ │ └── README.md ├── CIP-0110/ │ └── README.md ├── CIP-0112/ │ └── README.md ├── CIP-0114/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0115/ │ └── README.md ├── CIP-0116/ │ ├── README.md │ ├── cardano-babbage.json │ ├── cardano-conway.json │ └── changelog.md ├── CIP-0117/ │ └── README.md ├── CIP-0118/ │ └── README.md ├── CIP-0119/ │ ├── README.md │ ├── cip-0119.common.jsonld │ ├── cip-0119.common.schema.json │ ├── examples/ │ │ └── drep.jsonld │ └── test-vector.md ├── CIP-0120/ │ ├── README.md │ ├── examples/ │ │ ├── malicious-consitution/ │ │ │ └── cardano-constitution-5.txt │ │ └── ryan-consitution/ │ │ └── cardano-constitution-0.txt │ └── test-vector.md ├── CIP-0121/ │ └── README.md ├── CIP-0122/ │ └── README.md ├── CIP-0123/ │ └── README.md ├── CIP-0124/ │ ├── README.md │ └── cddl/ │ ├── version_1.cddl │ └── version_2.cddl ├── CIP-0127/ │ └── README.md ├── CIP-0128/ │ └── README.md ├── CIP-0129/ │ └── README.md ├── CIP-0132/ │ └── README.md ├── CIP-0133/ │ └── README.md ├── CIP-0134/ │ └── README.md ├── CIP-0135/ │ └── README.md ├── CIP-0136/ │ ├── README.md │ ├── cip-136.common.jsonld │ ├── cip-136.common.schema.json │ ├── examples/ │ │ ├── parameter-change-abstain.body.jsonld │ │ ├── parameter-change-abstain.body.nq │ │ ├── parameter-change-abstain.jsonld │ │ ├── treasury-withdrawal-unconstitutional.body.jsonld │ │ ├── treasury-withdrawal-unconstitutional.body.nq │ │ └── treasury-withdrawal-unconstitutional.jsonld │ └── test-vector.md ├── CIP-0137/ │ └── README.md ├── CIP-0138/ │ └── README.md ├── CIP-0139/ │ ├── Query_Layer_API_Comparison.md │ ├── README.md │ ├── cip-0144.md │ ├── endpoints.md │ ├── json-rpc.json │ ├── open-api.json │ ├── query-layer.json │ └── ts-api.md ├── CIP-0140/ │ ├── .gitignore │ ├── README.md │ ├── flake.nix │ └── peras.agda-lib ├── CIP-0141/ │ └── README.md ├── CIP-0142/ │ └── README.md ├── CIP-0143/ │ └── README.md ├── CIP-0146/ │ └── README.md ├── CIP-0149/ │ └── README.md ├── CIP-0150/ │ ├── README.md │ └── stats.json ├── CIP-0151/ │ ├── CIP88_Master_v2.cddl │ ├── CIP88_Master_v2.example.json │ └── README.md ├── CIP-0152/ │ └── README.md ├── CIP-0153/ │ └── README.md ├── CIP-0155/ │ ├── README.md │ ├── registry.json │ └── registry.schema.json ├── CIP-0156/ │ └── README.md ├── CIP-0158/ │ └── README.md ├── CIP-0159/ │ └── README.md ├── CIP-0160/ │ └── README.md ├── CIP-0161/ │ ├── README.md │ └── graph/ │ ├── NhandNa.py │ ├── extended_error_series_corrected.csv │ ├── scenario-cost-cross-thresholds.py │ ├── scenario_cost_praos_vs_phalanx-full-scenarios.py │ ├── scenario_cost_praos_vs_phalanx.py │ ├── settlement-time-phalanx.py │ ├── settlement-time-praos.py │ ├── settlement-time-without-grinding.py │ └── vdf_benches.py ├── CIP-0162/ │ └── README.md ├── CIP-0163/ │ └── README.md ├── CIP-0164/ │ ├── README.md │ └── SUMMARY.md ├── CIP-0165/ │ ├── README.md │ ├── format/ │ │ ├── format.ksy │ │ └── scls_file.html │ └── namespaces/ │ ├── README.md │ ├── blocks_v0.cddl │ ├── gov_committee_v0.cddl │ ├── gov_constitution_v0.cddl │ ├── gov_pparams_v0.cddl │ ├── gov_proposals_v0.cddl │ ├── nonces_v0.cddl │ ├── pool_stake_v0.cddl │ ├── snapshots_v0.cddl │ └── utxo_v0.cddl ├── CIP-0167/ │ └── README.md ├── CIP-0170/ │ ├── README.md │ ├── example-credential-chain.cesr │ ├── example-revocation-event.cesr │ ├── version_1.cddl │ ├── version_1.json │ └── vlei-cardano-metadata-signer-credential.json ├── CIP-0171/ │ └── README.md ├── CIP-0176/ │ └── README.md ├── CIP-0381/ │ └── README.md ├── CIP-1694/ │ ├── README.fr.md │ └── README.md ├── CIP-1852/ │ ├── CIP-1852.md │ └── README.md ├── CIP-1853/ │ ├── CIP-1853.md │ └── README.md ├── CIP-1854/ │ ├── CIP-1854.md │ └── README.md ├── CIP-1855/ │ ├── CIP-1855.md │ └── README.md ├── CIP-9999/ │ └── README.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING ├── CPS-0003/ │ └── README.md ├── CPS-0005/ │ └── README.md ├── CPS-0007/ │ └── README.md ├── CPS-0008/ │ └── README.md ├── CPS-0009/ │ └── README.md ├── CPS-0010/ │ └── README.md ├── CPS-0011/ │ └── README.md ├── CPS-0012/ │ └── README.md ├── CPS-0013/ │ └── README.md ├── CPS-0014/ │ └── README.md ├── CPS-0016/ │ └── README.md ├── CPS-0017/ │ └── README.md ├── CPS-0018/ │ └── README.md ├── CPS-0020/ │ └── README.md ├── CPS-0021/ │ ├── CPD/ │ │ ├── README.md │ │ └── graph/ │ │ ├── forking_probabilities.py │ │ ├── mixing_probabilities.py │ │ ├── scenario_cost-graph.py │ │ ├── scenario_cpu_graph.py │ │ └── window0_graph.py │ └── README.md ├── CPS-0022/ │ └── README.md ├── LICENSE └── README.md ================================================ FILE CONTENTS ================================================ ================================================ FILE: .gitattributes ================================================ * linguist-vendored *.md linguist-vendored=false ================================================ FILE: .github/CIP-TEMPLATE.md ================================================ --- CIP: ? Title: ? Category: ? Status: Proposed Authors: - John Doe Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/? Created: YYYY-MM-DD License: CC-BY-4.0 --- ## Abstract ## Motivation: why is this CIP necessary? ## Specification ## Rationale: how does this CIP achieve its goals? ## Path to Active ### Acceptance Criteria ### Implementation Plan ## Copyright ================================================ FILE: .github/CPS-TEMPLATE.md ================================================ --- CPS: ? Title: ? Category: ? Status: Open Authors: - John Doe Proposed Solutions: [] Discussions: - Original pull request: https://github.com/cardano-foundation/CIPs/pull/? Created: YYYY-MM-DD License: CC-BY-4.0 --- ## Abstract ## Problem ## Use Cases ## Goals ## Open Questions ## Copyright ================================================ FILE: .github/CPS-VALIDATION.md ================================================ # CPS Validation Rules This document describes all validation rules applied to Cardano Problem Statement (CPS) documents. These validations are to be ran automatically via Github workflow using [`/scripts/validate-cps.py`](./scripts/validate-cps.py). These attempt to codify the guidance described within [CIP-9999 | Cardano Problem Statements](../CIP-9999/README.md). ## File-Level Validations | Validation | Description | | ---------- | ----------- | | File path | Must be in a `CPS-*` directory | | Line endings | Must use UNIX line endings (LF), not Windows (CRLF) or old Mac (CR) | | Frontmatter | Must have valid YAML frontmatter between `---` delimiters | | No H1 headings | H1 (`#`) headings are not allowed in the document body | ## Header Field Validations All 9 fields are **required**, must appear in order, and no extra fields are allowed. | Field | Order | Validation Rules | | ----- | ----- | ---------------- | | **CPS** | 1 | Positive integer (`1`, `42`) or `?`/`??`/etc. for unassigned. No leading zeros. | | **Title** | 2 | 1-100 characters, no backticks (`` ` ``) | | **Category** | 3 | One of: `Meta`, `Wallets`, `Tokens`, `Metadata`, `Tools`, `Plutus`, `Ledger`, `Consensus`, `Network`, `?` | | **Status** | 4 | `Open`, `Solved`, or `Inactive` (optionally with reason, e.g., `Inactive (Superseded)`) | | **Authors** | 5 | Non-empty list, each entry: `Name ` | | **Proposed Solutions** | 6 | List (can be empty), each entry: `Label: URL` | | **Discussions** | 7 | Non-empty list, each entry: `Label: URL` | | **Created** | 8 | Date in `YYYY-MM-DD` format | | **License** | 9 | `CC-BY-4.0` or `Apache-2.0` | ## CIP Label Validation For the **Proposed Solutions** and **Discussions** fields, when an entry label matches the `CIP-NNNN` pattern, extra validation applies: | Rule | Description | | ---- | ----------- | | GitHub URL required | Must be `https://github.com/cardano-foundation/CIPs/...` | | Valid URL types | `/pull/NNN` (PR) or `/tree/{branch}/CIP-NNNN` or `/blob/{branch}/CIP-NNNN` (merged) | | `?` suffix for PRs | `CIP-0030?` required when linking to a pull request (candidate) | | No `?` for merged | `CIP-0030` (without `?`) required when linking to a merged CIP | Non-CIP labels (e.g., `Forum Post`, `Pull Request`) are allowed with any valid URL. ## Required Sections (H2 Headers) The following sections must exist in this order with **exact capitalization**. **No other H2 sections are allowed** except the optional sections listed below. | Order | Section | | ----- | ------- | | 1 | `Abstract` | | 2 | `Problem` | | 3 | `Use Cases` | | 4 | `Goals` | | 5 | `Open Questions` | | 6 | `Copyright` | ## Optional Sections The following sections are allowed with exact capitalization. They **must** appear after `Open Questions` and before `Copyright`: - `References` - `Appendices` - `Acknowledgments` / `Acknowledgements` Optional sections appearing before any required section (other than `Copyright`) will cause validation to fail. ================================================ FILE: .github/schemas/cps-header.schema.json ================================================ { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://github.com/cardano-foundation/CIPs/.github/schemas/cps-header.schema.json", "title": "CPS Header Schema", "description": "JSON Schema for validating YAML frontmatter headers in Cardano Problem Statements (CPSs)", "type": "object", "required": [ "CPS", "Title", "Category", "Status", "Authors", "Proposed Solutions", "Discussions", "Created", "License" ], "properties": { "CPS": { "description": "The CPS number (without leading 0), or one or more '?' before number has been assigned", "oneOf": [ { "type": "string", "pattern": "^\\?+$" }, { "type": "integer", "minimum": 1 }, { "type": "string", "pattern": "^[1-9]\\d*$" } ] }, "Title": { "description": "A succinct and descriptive title. Don't use backticks (`) in titles since they disrupt formatting in other contexts. Must be less than 100 characters.", "type": "string", "minLength": 1, "maxLength": 100, "not": { "pattern": "`" } }, "Category": { "description": "One of the editorially accepted categories covering one area of the ecosystem", "type": "string", "enum": [ "Meta", "Wallets", "Tokens", "Metadata", "Tools", "Plutus", "Ledger", "Consensus", "Network", "?" ] }, "Status": { "description": "Status of the CPS: Open, Solved, or Inactive (with optional reason)", "type": "string", "pattern": "^(Open|Solved|Inactive(?:\\s+\\(.*\\))?)$" }, "Authors": { "description": "A list of authors' real names and email addresses (e.g. John Doe )", "type": "array", "minItems": 1, "items": { "type": "string", "pattern": "^.+\\s+<.+>$", "description": "Author entry in format: Name " } }, "Proposed Solutions": { "description": "A list of CIPs addressing the problem, if any. Can be an empty array []. Each entry is 'Label: URL'. When label is CIP-NNNN, URL must be a GitHub CIPs repo link; use '?' suffix for PRs (candidates).", "type": "array", "items": { "oneOf": [ { "type": "string", "minLength": 1, "pattern": "^.+:\\s+https?://.+$", "description": "Entry in format: 'Label: URL'" }, { "type": "object", "minProperties": 1, "maxProperties": 1, "additionalProperties": { "type": "string", "format": "uri" }, "description": "Dictionary format: {'Label': 'URL'}" } ] } }, "Discussions": { "description": "A list of links where major technical discussions regarding this CPS happened. Must include a link to the pull request that created the CPS. Each entry must have a label followed by a colon and URL. Can be a string 'Label: URL' or a dictionary {'Label': 'URL'}.", "type": "array", "minItems": 1, "items": { "oneOf": [ { "type": "string", "pattern": "^.+:\\s+https?://.+$", "description": "Entry in format: 'Label: URL'" }, { "type": "object", "minProperties": 1, "maxProperties": 1, "additionalProperties": { "type": "string", "format": "uri" }, "description": "Dictionary format: {'Label': 'URL'}" } ] } }, "Created": { "description": "Date created on, in ISO 8601 (YYYY-MM-DD) format", "type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}$", "format": "date" }, "License": { "description": "Abbreviation of an approved license", "type": "string", "enum": [ "CC-BY-4.0", "Apache-2.0" ] } }, "additionalProperties": false } ================================================ FILE: .github/scripts/validate-cps.py ================================================ #!/usr/bin/env python3 """ Validation script for CPS README.md files. Validates YAML headers and required sections. """ import sys import re import json import yaml from pathlib import Path from typing import Dict, List, Set, Tuple, Optional try: import jsonschema except ImportError: print("Error: jsonschema library is required. Install it with: pip install jsonschema", file=sys.stderr) sys.exit(1) # Required fields for CPS headers (in required order) CPS_REQUIRED_FIELDS_ORDER = [ 'CPS', 'Title', 'Category', 'Status', 'Authors', 'Proposed Solutions', 'Discussions', 'Created', 'License' ] CPS_REQUIRED_FIELDS = set(CPS_REQUIRED_FIELDS_ORDER) # Required sections (H2 headers) in required order CPS_REQUIRED_SECTIONS_ORDER = [ 'Abstract', 'Problem', 'Use Cases', 'Goals', 'Open Questions', 'Copyright' ] CPS_REQUIRED_SECTIONS = set(CPS_REQUIRED_SECTIONS_ORDER) # Optional H2 sections (allowed but not required) # These should appear after the required sections, before Copyright CPS_OPTIONAL_SECTIONS = { 'References', 'Appendices', 'Acknowledgments', 'Acknowledgements' } # Load CPS header schema SCHEMA_PATH = Path(__file__).parent.parent / 'schemas' / 'cps-header.schema.json' with open(SCHEMA_PATH, 'r', encoding='utf-8') as f: CPS_HEADER_SCHEMA = json.load(f) def parse_frontmatter(content: str) -> Tuple[Optional[Dict], Optional[str], Optional[List[str]]]: """Parse YAML frontmatter from markdown content. Returns: Tuple of (frontmatter_dict, remaining_content, raw_lines) or (None, content, None) if no frontmatter """ # Check for frontmatter delimiters - must start with --- if not content.startswith('---'): return None, content, None # Find the closing delimiter (--- on its own line) # Split on '\n---\n' or '\n---' at end of content lines = content.split('\n') if lines[0] != '---': return None, content, None # Find the closing --- end_idx = None for i in range(1, len(lines)): if lines[i] == '---': end_idx = i break if end_idx is None: return None, content, None # Extract frontmatter (lines between the two --- markers) frontmatter_lines = lines[1:end_idx] # Preprocess: quote standalone '?' values (YAML interprets '?' as explicit key indicator) processed_lines = [] for line in frontmatter_lines: # Match lines like "CPS: ?" or "Category: ?" and quote the ? if re.match(r'^[A-Za-z][A-Za-z ]*:\s+\?+\s*$', line): line = re.sub(r':\s+(\?+)\s*$', r': "\1"', line) processed_lines.append(line) frontmatter_text = '\n'.join(processed_lines) # Extract remaining content (everything after the closing ---) remaining_lines = lines[end_idx + 1:] remaining_content = '\n'.join(remaining_lines) try: frontmatter = yaml.safe_load(frontmatter_text) if frontmatter is None: return None, content, None return frontmatter, remaining_content, frontmatter_lines except yaml.YAMLError as e: return None, content, None except ValueError as e: # Catches invalid date values that YAML tries to parse (e.g., month 13) return None, content, None def extract_h2_headers(content: str) -> List[str]: """Extract all H2 headers (##) from markdown content.""" h2_pattern = r'^##\s+(.+)$' headers = [] for line in content.split('\n'): match = re.match(h2_pattern, line) if match: headers.append(match.group(1).strip()) return headers def extract_h1_headers(content: str) -> List[str]: """Extract all H1 headers (#) from markdown content.""" h1_pattern = r'^#\s+(.+)$' headers = [] for line in content.split('\n'): match = re.match(h1_pattern, line) if match: headers.append(match.group(1).strip()) return headers def validate_line_endings(file_path: Path) -> List[str]: """Validate that file uses UNIX line endings (LF, not CRLF). Returns: List of error messages (empty if valid) """ errors = [] try: # Read file in binary mode to check line endings with open(file_path, 'rb') as f: content_bytes = f.read() # Check for CRLF (\r\n) - Windows line endings if b'\r\n' in content_bytes: errors.append("File uses Windows line endings (CRLF). Use UNIX line endings (LF) instead.") # Check for standalone \r without \n (old Mac line endings) # Replace CRLF first, then check for remaining CR content_without_crlf = content_bytes.replace(b'\r\n', b'') if b'\r' in content_without_crlf: errors.append("File uses old Mac line endings (CR). Use UNIX line endings (LF) instead.") except Exception as e: errors.append(f"Error checking line endings: {e}") return errors def validate_no_h1_headings(content: str) -> List[str]: """Validate that no H1 headings are present in the document. Returns: List of error messages (empty if valid) """ errors = [] h1_headers = extract_h1_headers(content) if h1_headers: errors.append(f"H1 headings are not allowed. Found: {', '.join(h1_headers)}") return errors def _validate_field_order(frontmatter: Dict) -> List[str]: """Validate that header fields appear in the correct order. Returns: List of error messages (empty if valid) """ errors = [] # Get the actual order of fields in the frontmatter actual_fields = list(frontmatter.keys()) # Filter to only known required fields (ignore any extra fields for order check) actual_required = [f for f in actual_fields if f in CPS_REQUIRED_FIELDS] # Build expected order based on which required fields are present expected_order = [f for f in CPS_REQUIRED_FIELDS_ORDER if f in actual_required] if actual_required != expected_order: errors.append( f"Header fields are not in the correct order. " f"Expected: {', '.join(expected_order)}. " f"Got: {', '.join(actual_required)}" ) return errors def validate_header(frontmatter: Dict) -> List[str]: """Validate the YAML frontmatter header for CPSs. Returns: List of error messages (empty if valid) """ errors = [] # Validate field order errors.extend(_validate_field_order(frontmatter)) # Validate header fields using JSON Schema try: # Convert date objects to strings for schema validation # JSON Schema expects dates as strings, but PyYAML may parse them as date objects # Also normalize dictionary entries in lists to strings (YAML parses "Label: URL" as dict) frontmatter_for_schema = {} for key, value in frontmatter.items(): if key == 'Created' and hasattr(value, 'isoformat'): # Handle date objects from PyYAML (datetime.date or datetime.datetime) frontmatter_for_schema[key] = value.isoformat() elif key in ('Proposed Solutions', 'Discussions') and isinstance(value, list): # Convert dictionary entries to string format "Label: URL" normalized_list = [] for item in value: if isinstance(item, dict): # Convert dict like {'Label': 'URL'} to string 'Label: URL' if len(item) == 1: label, url = next(iter(item.items())) normalized_list.append(f"{label}: {url}") else: # Multiple keys - join them normalized_list.append(": ".join(f"{k}: {v}" for k, v in item.items())) elif isinstance(item, str): normalized_list.append(item) else: normalized_list.append(str(item)) frontmatter_for_schema[key] = normalized_list else: frontmatter_for_schema[key] = value jsonschema.validate(instance=frontmatter_for_schema, schema=CPS_HEADER_SCHEMA) except jsonschema.ValidationError as e: # Format JSON Schema validation errors in a user-friendly way error_path = '.'.join(str(p) for p in e.path) if e.path else 'root' errors.append(f"Header validation error at '{error_path}': {e.message}") except jsonschema.SchemaError as e: errors.append(f"Schema error: {e.message}") # Validate CIP label semantic rules (label/URL relationship) if 'Proposed Solutions' in frontmatter: errors.extend(_validate_cip_label_entries(frontmatter['Proposed Solutions'], 'Proposed Solutions')) if 'Discussions' in frontmatter: errors.extend(_validate_cip_label_entries(frontmatter['Discussions'], 'Discussions')) return errors def _validate_cip_label_entries(entries: list, field_name: str) -> List[str]: """Validate semantic rules for entries with CIP labels. When a label matches CIP-NNNN pattern: - URL must be a GitHub CIPs repository link (PR or merged CIP) - Pull request URLs require '?' suffix on the CIP number (candidate) - Merged CIP URLs must NOT have '?' suffix Other labels are allowed with any valid URL. Args: entries: List of label-URL entries field_name: Name of the field for error messages Returns: List of error messages (empty if valid) """ errors = [] if not isinstance(entries, list): return errors cip_label_pattern = re.compile(r'^(CIP-\d+)(\?)?$') pr_pattern = re.compile(r'https://github\.com/cardano-foundation/CIPs/pull/\d+') merged_pattern = re.compile(r'https://github\.com/cardano-foundation/CIPs/(tree|blob)/[^/]+/CIP-\d+') github_cips_pattern = re.compile(r'^https://github\.com/cardano-foundation/CIPs/(pull/\d+|tree/[^/]+/CIP-\d+|blob/[^/]+/CIP-\d+)') for i, entry in enumerate(entries): # Normalize to label and URL if isinstance(entry, dict) and len(entry) == 1: label, url = next(iter(entry.items())) elif isinstance(entry, str): # Parse "Label: URL" format match = re.match(r'^([^:]+):\s+(.+)$', entry) if not match: continue label, url = match.groups() else: continue label = label.strip() url = url.strip() # Check if label matches CIP pattern - only then apply extra validation label_match = cip_label_pattern.match(label) if not label_match: continue # Non-CIP labels are allowed with any URL cip_number = label_match.group(1) has_question_mark = label_match.group(2) == '?' # For CIP labels, URL must be a GitHub CIPs repository link if not github_cips_pattern.match(url): errors.append( f"'{field_name}' entry {i+1}: CIP label '{label}' requires a GitHub CIPs repository URL " f"(pull request or merged CIP). Got: {url}" ) continue is_pr = pr_pattern.search(url) is not None is_merged = merged_pattern.search(url) is not None if is_pr and not has_question_mark: errors.append( f"'{field_name}' entry {i+1}: Pull request URL requires '?' suffix on CIP number " f"(use '{cip_number}?' instead of '{cip_number}' to indicate candidate status)" ) elif is_merged and has_question_mark: errors.append( f"'{field_name}' entry {i+1}: Merged CIP should not have '?' suffix " f"(use '{cip_number}' instead of '{cip_number}?' since this CIP is merged)" ) return errors def validate_sections(content: str) -> List[str]: """Validate required sections exist at H2 level for CPSs. Returns: List of error messages (empty if valid) """ errors = [] h2_headers = extract_h2_headers(content) found_sections = set(h2_headers) # Normalize headers to lowercase for case-insensitive comparison found_sections_lower = {h.lower() for h in found_sections} required_sections_lower = {h.lower() for h in CPS_REQUIRED_SECTIONS} optional_sections_lower = {h.lower() for h in CPS_OPTIONAL_SECTIONS} # Check for missing required sections (case-insensitive) missing_sections_lower = required_sections_lower - found_sections_lower if missing_sections_lower: # Map back to original case from required_sections for error message missing_sections = {orig for orig in CPS_REQUIRED_SECTIONS if orig.lower() in missing_sections_lower} errors.append(f"Missing required sections: {', '.join(sorted(missing_sections))}") # Check for unknown sections (not in required or optional) allowed_sections_lower = required_sections_lower | optional_sections_lower for header in h2_headers: if header.lower() not in allowed_sections_lower: errors.append(f"Unknown section: '{header}'. Only required and optional sections are allowed.") # Build a mapping from lowercase to expected capitalization expected_capitalization = {} for section in CPS_REQUIRED_SECTIONS: expected_capitalization[section.lower()] = section for section in CPS_OPTIONAL_SECTIONS: expected_capitalization[section.lower()] = section # Check for incorrect capitalization for header in h2_headers: header_lower = header.lower() if header_lower in expected_capitalization: expected = expected_capitalization[header_lower] if header != expected: errors.append(f"Section '{header}' has incorrect capitalization. Expected: '{expected}'") # Check section order # Map found headers to their canonical names (for order comparison) canonical_headers = [] for header in h2_headers: header_lower = header.lower() if header_lower in expected_capitalization: canonical_headers.append(expected_capitalization[header_lower]) else: canonical_headers.append(header) # Keep unknown headers as-is # Extract just the required sections in the order they appear found_required_order = [h for h in canonical_headers if h in CPS_REQUIRED_SECTIONS] # Build expected order based on which required sections are present expected_required_order = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s in found_required_order] if found_required_order != expected_required_order: errors.append( f"Sections are not in the correct order. " f"Expected: {', '.join(expected_required_order)}. " f"Got: {', '.join(found_required_order)}" ) # Check that optional sections appear only between "Open Questions" and "Copyright" # Optional sections must not appear before any required section except Copyright optional_sections_normalized = {s.lower() for s in CPS_OPTIONAL_SECTIONS} required_before_optional = [s for s in CPS_REQUIRED_SECTIONS_ORDER if s != 'Copyright'] for i, header in enumerate(canonical_headers): header_lower = header.lower() if header_lower in optional_sections_normalized: # This is an optional section - check what comes after it for j in range(i + 1, len(canonical_headers)): following_header = canonical_headers[j] # If a required section (other than Copyright) follows an optional section, that's an error if following_header in required_before_optional: errors.append( f"Optional section '{header}' appears before required section '{following_header}'. " f"Optional sections must appear after 'Open Questions' and before 'Copyright'." ) break return errors def is_cps_file(file_path: Path) -> bool: """Check if file path indicates a CPS document.""" path_str = str(file_path) # Normalize path separators and check for CPS- pattern # Handles both absolute (/CPS-123/) and relative (CPS-123/) paths # Also handles Windows paths (CPS-123\README.md) normalized_path = path_str.replace('\\', '/') # Check for CPS- pattern (with or without leading slash) return bool(re.search(r'(^|/)CPS-', normalized_path, re.IGNORECASE)) def validate_file(file_path: Path) -> Tuple[bool, List[str]]: """Validate a single CPS README.md file. Returns: Tuple of (is_valid, list_of_errors) """ errors = [] # Check if this is a CPS file if not is_cps_file(file_path): return False, [f"File path does not indicate a CPS document: {file_path}"] # Validate line endings (must check raw file bytes) line_ending_errors = validate_line_endings(file_path) errors.extend(line_ending_errors) # Read file content try: content = file_path.read_text(encoding='utf-8') except Exception as e: return False, [f"Error reading file: {e}"] # Parse frontmatter frontmatter, remaining_content, raw_lines = parse_frontmatter(content) if frontmatter is None: errors.append("Missing or invalid YAML frontmatter (must start with '---' and end with '---')") return False, errors # Check for leading zeros in CPS field (YAML loses this information) if raw_lines: for line in raw_lines: if re.match(r'^CPS:\s+0\d+', line): errors.append("CPS number must not have leading zeros") break # Validate header header_errors = validate_header(frontmatter) errors.extend(header_errors) # Validate no H1 headings h1_errors = validate_no_h1_headings(remaining_content) errors.extend(h1_errors) # Validate sections section_errors = validate_sections(remaining_content) errors.extend(section_errors) is_valid = len(errors) == 0 return is_valid, errors def main(): """Main entry point for the validation script.""" if len(sys.argv) < 2: print("Usage: validate-cps.py [file2] ...", file=sys.stderr) sys.exit(1) files_to_validate = [Path(f) for f in sys.argv[1:]] all_valid = True all_errors = [] for file_path in files_to_validate: if not file_path.exists(): print(f"Error: File not found: {file_path}", file=sys.stderr) all_valid = False continue is_valid, errors = validate_file(file_path) if not is_valid: all_valid = False print(f"\nValidation failed for {file_path}:", file=sys.stderr) for error in errors: print(f" - {error}", file=sys.stderr) all_errors.append((file_path, errors)) if not all_valid: print(f"\nValidation failed for {len(all_errors)} file(s)", file=sys.stderr) sys.exit(1) print(f"\nAll {len(files_to_validate)} file(s) passed validation", file=sys.stderr) sys.exit(0) if __name__ == '__main__': main() ================================================ FILE: .github/workflows/cip10-validation.yaml ================================================ name: CIP-10 - Validate Registry JSON on Pull Request on: pull_request: paths: - 'CIP-0010/registry.json' jobs: approve: # Pre-approval step runs-on: ubuntu-latest steps: - name: Approve run: echo For security reasons, all pull requests need to be approved first before running any automated CI. validate-json: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v3 - name: Set up Node.js uses: actions/setup-node@v3 with: node-version: '21' - name: Install dependencies run: npm install ajv-cli - name: Validate JSON against schema run: npx ajv validate -s CIP-0010/registry.schema.json -d CIP-0010/registry.json > /dev/null ================================================ FILE: .github/workflows/cps-validation.yaml ================================================ name: CPS Validation on: pull_request: paths: - 'CPS*/README.md' - 'cps*/README.md' workflow_dispatch: inputs: pr_number: description: 'PR number to validate' required: true type: string jobs: validate: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 with: fetch-depth: 0 - name: Fetch PR branch if: github.event_name == 'workflow_dispatch' run: | git fetch origin pull/${{ github.event.inputs.pr_number }}/head:pr-branch git checkout pr-branch - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: | pip install pyyaml jsonschema - name: Get CPS files to validate id: get-files run: | if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then # Manual run: diff PR branch against master FILES=$(git diff --name-only --diff-filter=ACMR origin/master...HEAD | grep -iE '^CPS-[^/]+/README\.md$' || true) else # PR trigger: diff against base branch FILES=$(git diff --name-only --diff-filter=ACMR HEAD~1 HEAD | grep -iE '^CPS-[^/]+/README\.md$' || true) fi if [ -z "$FILES" ]; then echo "No CPS README.md files to validate" echo "has_files=false" >> $GITHUB_OUTPUT exit 0 fi # Convert newlines to spaces for passing as arguments FILES_SPACE=$(echo "$FILES" | tr '\n' ' ') echo "has_files=true" >> $GITHUB_OUTPUT echo "files=$FILES_SPACE" >> $GITHUB_OUTPUT - name: Validate CPS files if: steps.get-files.outputs.has_files == 'true' run: | FILES="${{ steps.get-files.outputs.files }}" echo "Validating CPS files: $FILES" python3 .github/scripts/validate-cps.py $FILES ================================================ FILE: BiweeklyMeetings/2020-07-01.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [July 1 2020 notes](#july-1-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [CIP2](#cip2) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 7/1/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## July 1 2020 notes **Attending**: (Duncan, Sebastien, Frederic, Matthias) ### Triage - Nothing to review yet! ### Last Check => **Action**: - merge PR (CIP1 copy tweak) ### Review #### CIP2 > (Discussions already took place in that PR comments!) > A few items to change for the current CIP2 PR > Missing the fee - Description is wrong… Should the termination condition incorporate the idea that some inputs might be too small to spend? Or should it be part of the available condition UTXO or Ignored (a choice) Add a query about if the algorithm is clear in presence of a min UTXO output.. (was it considered for Byron?) > Possibly: remove “for Cardano” from the title ### Discussions - Side conversations for how the Wallet work for Shelley key derivations (currently on the Adrestia user guide, might be worth moving to the CIP). - Other Qs regarding transaction Metadata (format allows for wide-range)... - (could/should be freeform?) - Describe a way of versioning metadata? - Need some agreement on namespace else it might lead to confusion. - CIP notes should be merged in post meeting in the CIP Repo - will be fleshed out in the coming week. ### Close - CIP1 Copy tweak PR - to merge asap. - “Coin Selection Algorithms” PR agreed on, to be merged in as CIP2 ‘Draft’ if no issues next meeting (7/15) - Meeting notes (these) to be added to the CIP repo itself for visibility on process. (Close) --- ## 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 | :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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-07-15.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [July 15 2020 notes](#july-15-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [CIP5](#cip5) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 7/15/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## July 15 2020 notes **Attending**: (Duncan, Sebastien, Frederic, ~~Matthias~~) + Eystein (guest) ### Triage - Still issues with the multi-review. - Need to add meeting notes to the repo. - Merge pr (copy tweak on CIP1). ### Last Check => **Action**: - merge pr (CIP2 - “Coin Selection” - DRAFT) ### Review #### CIP5 >**Sebastian** - Happy with all. Need to resolve that Cardano Wallet and possibly CLI uses this list, but Haskell-Shelley Rust codebase doesn’t use this, and uses diff prefixes… and this should be the main issue there. I would have to go in there and fix the prefixes themselves. >**D**: Reviewing the prefixes right now. >**S**: We have diff prefixes for mainnet and testnet. Which is duplicating the header payload. >**D**: It duplicates it but in an error checking way. If you need to render… The bit in the payload tells you that. And if mismatch, then you can address. In some sense, it duplicates and makes it visible to the user that they are dealing with a testnet address. >**Eystein** - would be good to have multiple iteration prefixes per testnet >**D**-> poor form - distinguishing is broken down. Addr is to prevent people from spending real money to testnet .. You don’t have that problem from testnet to testnet. >**S**: “Diff addr type in Shelley” Vs. Jormungandr. The concern is that diff address types might be confusing to ppl. So for Daedalus and Yoroi we decided to only support grp addresses. For Haskell-Shelley, we will have the same issue - so most likely those other addr. types will be hidden behind some flags of sorts. >**D**: That’ll likely be up to the wallet itself to figure out which type to use. >**E**: I don’t care if automated - I can see a usecase for both… >**D**: The distinction between the internal addr struct is just not important to regular users. It’s probably more confusing to highlight those as 10 different combinations.. Of staking, base, ptr… All of these can be by key or by script. Do we want to distinguish clearly? Is that helpful? Can it be actively un-helpful? Because in the end they are all payment addresses. >**S**: I think that would be a mess with users. I am more about enterprise vs. base. Because they all in a sense have their own chain - BIP44 sense? If you generate your addr for a single key. … this has to be displayed differently. (..) >**D**: Privacy in a wallet is the same as BTC or ETC - Under Matthias / Sebastien scheme, it’s easy to see they belong together. You only get privacy at the wallet account level. 3 ways a pmt addr can refer to a stake. And therefore have stake or not: Null (short) Ptr (short) Base (long) >**S**: Since all generated, the wallet will have to render … you’d have diff pages. Ex - a page for external addr page. Would need a way to toggle the rendering - to switch between base and ptr. >**D**: There should be a default - it would never as standard mode for users do null staking.. >**S**: after the initial release the wallet would show default release. >**D**: Wallet should not confuse users by presenting too many options… If easier to display short addr, should be simplified. >**D**: It’s a disc to have with Matthias - for Seb. (+Darko) Should we lump all Txs under one prefix? >**S** - I am not yet convinced about the addr prefix. But not concerned. >**D**: You don’t have to add the addr. if the wallet takes care of it for you. >**S**: Every addr. in Yoroi could display what type it is… would deal with the combinations. Screen space was dedicated for that but could be freed if bech32 impl. >**D**: Not majorly important. ### Discussions - Pool operators are thinking about a “Standardizing” CIP. - Opening up meetings visibility to the public. - Internal requests to consider CIP exploration re: Address management (for 100ks of i.e. exchanges). - Eystein as first guest - Reinvite an option to connect with community (Want to carefully open up meetings to public… at first 1-2 spots, later more). _Eystein had a good talk he did at the Cardano Summit in July - he understands governance / the need for CIPs._ ### Close - **CIP5** as Draft OK to merge - will be iterated on. - **CIP2** Merged delayed till next meeting to round up last Qs. (missing - current minor PR qs - ex: where and how to store meeting notes) (Close) --- ## 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 | :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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-08-04.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [Aug 4 2020 notes](#august-4-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 8/4/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## Aug 4 2020 notes **Attending**: (Duncan, Frederic, ~~Matthias~~, ~~Sebastien~~) + Ben (CF) ### Triage - Merge pr (copy tweak on CIP1) ### Last Check - Merge CIP2 (Draft) - Merge CIP5 (Draft) ### Review N/A ### Discussions *(short discussion centered around new PRs - from the past two weeks - that should move forward as 'Draft' - we shouldn't be trying to have perfect PRs, rather enable reworking as 'Draft')* - Setup a CIP for protocol parameters (Ask Romain? Kevin / Alex) - Review Meeting #2 notes in next meeting to continue threads - Need to upload some version of the notes in the CIP repository for visibility - should CIP 2&5 add License file and readme? ### Close - **CIP1** copy tweaks merged - **CIP2** merged as 'Draft' - **CIP5** merged as 'Draft' (Close) --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-08-11.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 11 2020 notes](#-11-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [CIP5](#cip5) + [CIP4](#cip4) + [CIP3](#cip3) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 8/11/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## August 11 2020 notes **Attending**: (~~Duncan~~, Frederic, Matthias, Sebastien) + Ben (CF) ### Triage N/A ### Last Check N/A ### Review #### CIP5 > **Matthias** - Needs to be finalized a bit more to be moved to “Proposed”. The internals of addresses are not really relevant for users. I don’t see why having diff. prefixes would help. Except for Advanced users. > **M** - It actually *could* go to “Proposed” right now - it doesn’t prevent us from doing updates. The set of problems we are working on is changing, so having revisions on CIP makes sense. The issue of updating a CIP beyond a final setup would be done through an update. > **Sebastien** - it would be nice to have a separate prefix for others… We can modify stuff after once that is settled… and that is fine as we will have to change things. #### CIP4 > **S** - Needs test vectors - should be quick. The Wallet checksum should be merged, it just got shipped. In CIP4 there are 2 versions - the Shelley Account is using the new format - everything is working - we have a javascript inmplemetation. We are hopefully going to release as Yoroi extension. Would be nice to have it merged. My understanding is that both teams are fine - it makes more sense, it’s more secure - it’s a bit more complicated. > **M** - I see you changed a lot more since I looked at it - will try to review it and move forward. > **S** - That CIP will also be used by Ergo - it will be a multichain standard functionally (used by Ergo). > **S** - I have a few examples in Emurgo test library - I don’t have the pictures… hope that’s ok. #### CIP3 > Still need more work before merging into Draft. ### Discussions 1. **M** - Change the README to the CIPx file… (change CIP1 content to reflect the structure) -> **Frederic** 2. Proper License files needed for CIP5 & CIP2 -> **M** 3. Some Stake pool operators think CIPs are a bit too complex - tried to convince Markus to write up a CIP to no avail... This seems like another way of not being heard. So StakePools wrote their own version. Some community members feel this isn’t fair… It might be good to push into a CIP? CIP engagement is still a bit too Silo’d - process could be *more* open. Would need someone in the community to “engage”. We could upload videos or notes in a more public way. 4. **M** - If ppl don’t want to write CIPs we can’t really force them. Since this is coming from the CF/IOHK/Emurgo - it frightens a bit the community. Having ppl from the community involved as CIP Editors might help? 5. **Ben** - (Different possible flows for CIP Editorship, to be continued next meeting) ### Close **TODO** Add license files to CIP5 & CIP2 (**Matthias**) **TODO** Change Format of CIPs (in CIP 1) to have the structures of CIPs change to readme.md (instead CIPx.md) (**Frederic**) (Close) --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-08-25.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 25 2020 notes](#august-25-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [CIP2](#cip2) + [CIP5](#cip5) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 8/25/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## August 25 2020 notes **Attending**: (Duncan, Frederic, Matthias, ~~Sebastien~~) + Ben (CF) ### Triage N/A ### Last Check Merging in meeting notes to publicize the process itself ### Review #### CIP2 > **Matthias** - This is a lengthy CIP and will benefit from a more thorough review. #### CIP5 > Discussion around currencies. Cardano does multi-asset by having a bundle. Address and tokens two separate entities. **Matthias** propose to remove addr in prefixes to keep consistency. Remove reference. **Duncan** will get rid of addr_bootstrap because it's confusing (can render a Byron address bip32 style). ### Discussions 1. **Frederic** brings up CIP stake pool meta-data concerns in the community. A discussion over badges for ITN pools, a CIP could be written? Just because a CIP is 'Active' doesn't mean implemented. 2. **F** suggests prioritizing community PRs towards 'Draft' to exemplify community ideas make it through. Ex: "Extended Metadata" [PR](https://github.com/cardano-foundation/CIPs/pull/15/files). 3. **D** (discussing back and forth with SMASH server) mentions the metadata isn't on-chain or at least no link back to on-chain except through the URL. 4. **M**: For CIP structure, would prefer moving to only using the 'Readme.md' file and cutting the 'Cip#.md' file. **F**: Aligned - some delays might come due to auto-generated site. **M**: Not a blocker. Github keeps track of all. ### Close **TODO** Invite community members to upcoming meeting (**Frederic**) **On Hold** Change Format of CIPs (in CIP 1) (instead CIPx.md) **TODO** Probe IOG for promised parameter CIP (**Frederic**) (Close) --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-09-08.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [September 08 2020 notes](#september-08-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [Extended Metadata](#Extended-Metadata) + [Curve Pledge Benefit](#Curve-Pledge-Benefit) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 9/8/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## September 08 2020 notes **Attending**: (Duncan, Frederic, ~Matthias~, Sebastien) + Steve(CF) + Shawn, Markus, Mike (PR Authors) ### Triage N/A ### Last Check N/A ### Review #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) #### Curve Pledge Benefit ([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) ### Discussions N/A - not enough time due to extended reviews. ### Close **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-09-22.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [September 22 2020 notes](#september-22-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [Curve Pledge Benefit](#Curve-Pledge-Benefit) + [Extended Metadata](#Extended-Metadata) * [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 UML Diagram](#cip-creation-process-as-a-uml-diagram) * [Understanding CIPs further](#understanding-cips-further) ## Summary Rough writeup of 9/22/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## September 22 2020 notes **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy(CF) + Shawn, Markus (PR Authors) + Collin (IOG) ### Triage N/A ### Last Check N/A ### Review #### Curve Pledge Benefit ([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) **Shawn** - (recap) Current pledging incentive mechanism linear setup is less than optimal for <1M ada. The superwhale end of the spectrum provides about 30% benefit for ppl able to pledge their own pool to saturation - By using a curve pledge mechanism instead of a linear one we can incentivise in a better way (for smaller folks/pools). (see graphs in the PR) **Duncan** - Not as simple, incentive folks are exploring all scenarios **Collin** - We don’t want for the high end to be the clear winner.I like the form of the solution - almost a smile shape. Not aligned with all but a solid proposal as-is. **Duncan** - This has been raised internally with IOHK researchers already - they weren’t so positive about it, but have been looking at it. **Colin** - They are in the long term equilibrium - but right now the linear isn’t working. **Duncan** - It was mentioned it should probably be skewed in the opposite direction.. **Colin** - if you can get the delegation bonus as a big holder, you’re much better off splitting into tiny pools right now **Duncan** - Researchers are aware of that - which direction it goes non-linear might cause issues. At no point should it be non-rewarding to add more stake to your pool. **Markus** - What about a ‘S’ curve mentioned by Charles? **Colin** - (Showing example graph) = M * (1/p) + N * p **Markus** - There are some good points or reasons that this can help What are the drawbacks or downsides based on a linear and non-linear approach? **Frederic** - The conversation about the solution can take place once the CIP has been setup as Draft, suggest we move to merge the PR and let conversation take place beyond. ***[Move to MERGE as CIP7]*** (all agree) #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) **Markus** - Recap on the conversation since last meeting: Last week Shawn gave some good proposals about a more standardized and well-thought structure for extended metadata.Need a response from ADA Pools as they implemented something without following the Script process. **Duncan** - Is there the right balance of features to include? You can try to get consensus amongst operators. Mechanism is important to consider, the other attributes can be decided at a later state. **Markus** - We reconsider the maximum size of the metadata file. All other things which are not very crucial, going out quick and sending messages to SPOs can be done in a different way. A potential Metadata proposal should involve security risks considerations, not just adding fields. **Duncan** - Reasonable to say we can add a few extra fields for metadata and limit the total data size to 1,000 bytes... If security is important, we could have a design Field extended with a URL, have a verification key (public key) which is signed for extended metadata. This means you don’t have to use the same key as your pool code key... **Markus** - Need to speak with more pool operators to see the approaches out there. I Will reach out and follow up. **Frederic** - Might be good to have competing views and discuss publicly, Multiple CIPs can propose different implementation proposals. **Markus** - Some pools have large teams and need metadata. “Cardano Scan” does a good job but is not known. Yoroi and Daedalus have uses of course too. **Duncan**- Frontend Daedalus Devs might be concerned about showing metadata when there is a security concern. RSS feed is a good example of a feature in the extended markdown **Sebastien** - The pool selection UI is outsourced for Yoroi. One feature we do care about is RSS feed, we would embed this into the UI. The existing proposal doesn't really talk about RSS feed into extended metadata. **Matthias** - Re: Daedalus frontend considerations - hard to say, there is a need for the data. Onchain there is not a limit of data. It's enforced by the software (SMASH). we can increase this. Can show the hash is on chain, there is a security risk and no way to verify you are looking at the right data. Having a key and hashing that the data is accurate is a good way. **Duncan** - If there is a key in the first MD level to sign the second MD level, this is a good mechanism. You could use HTTPS, could have a fingerprint of the hashed certificate, cant be replaced by any other certificates. **Markus** - Will look at rewriting the existing PR with assistance of ADApools and reframe/rework proposal next. **Frederic** - Can be discussed in comments of the CIP as draft maybe? (would like to bring it in) **Duncan** - People should discuss with others in the community (or IOHK).To Markus' rework: focus on security for feedback on Metadata standardization in the first version. Once there is a mechanism and two categories (Convenient and UnConvenient). Focus on mechanism, security towards minimum amount of metadata to prevent issues. Follow the JSON schema and explanation of each field. BIP44 or BIP32 has a template for similar extensions. Future CIPs might want to add additional Metadata fields and should be structured in this way… it’ll provide a template for future discussions. **Frederic** - Wrapping up on the meeting: Review ‘CIP6’ in 2 weeks. ‘Merge of CIP7’ once Legal ok. Markus to talk to the community about security and minimal metadata... **Sebastien** - CIP4 PR can likely be merged in/ a draft, should it merged? We brought it up in the past + it has been implemented in Yoroi already.. ### Discussions N/A - not enough time due to extended reviews. CIP4 to be looked at in async channels and moved to next meeting. ### Close **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site **TODO** Merge Curve proposal / ‘CIP7’ once legal oks. --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft | | 5 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-10-06.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [October 06 2020 notes](#october-06-2020-notes) * [Triage](#triage) * [Last Check](#last-check) + [Extended Metadata](#Extended-Metadata) + [Curve Pledge Benefit](#Curve-Pledge-Benefit) * [Review](#review) + [Wallet Checksums](#Wallet-Checksums) + [Message Signing](#Message-Signing) * [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 10/6/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## October 06 2020 notes **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy (CF) + Shawn (PR Author) + Nick (Community) ### Triage N/A ### Last Check #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) **Frederic** - “Extended Metadata” has been awaiting the result of conversations with major stakepool operators led by Markus, while Mike wanted to incorporate suggestions from Shawn. No activity since last meeting on the PR. Recommendation is to merge as a draft as discussed last meeting to start/enable the discussion. **Sebastien** - Let’s wait another two weeks for the changes/comments that were expected in the PR to proceed. #### Curve Pledge Benefit ([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) **Sebastien** - Still not sure if the proposal' incentives are fully sound but that’s for analysts to discuss. **Matthias/Shawn** - Last CIP Editors meeting we agreed to merge it as a draft, pending some legal clarifications. **Sebastien** - Can be merged as a draft. As formatting goes, ok to merge to advance the conversation. **Frederic** - Still no word from legal, but Shawn agreed to remove copyright as Draft and amend the PR while unclear, ok to move as draft as-is and modify. ### Review #### Wallet Checksums ([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4) **Sebastien** - Yoroi extension and Yoroi wallet have already implemented a Wallet Checksum. Maps public keys to a picture and text block: People have often entered the wrong recovery phase numerous times, so the checksum means we receive less complaints (for user errors). This is ready to merge as draft I think. #### Message Signing ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8) **Sebastien** - When you send a transaction you functionally prove you own the tokens via signing. You should therefore be able to prove any statement, not limited to tokens. This is a specification of how to bundle together data (a message) and proof (signature) for a transaction. Agreed format for Yoroi and Daedalus, useful for off chain components. The proposed format for how to structure the message is based on COSE, restricting/simplifying a bit the functionalities so it’s easier to use: COSE is a bit too complex for wallets to have a full implementation? The objective is to only support the algorithms that we are interested in using with Cardano. Here, you can submit headers as part of the message. In this specification many of the headers have been excluded. Need to check if this approach can be used for Daedalus wallet. **Duncan** - May have internal IOHK auditors to review, 2-3 weeks needed for review. ### Discussions **Shawn** - What is the process for items to be put on the CIP Editors meeting agenda? **Duncan** - Any relevant items, depending on capacity - easiest way is reach out to the Editors or flag it in Github. (Discussion re: Pool ranking .. needs to be improved) ### Close **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) “Curve proposal” (‘CIP7’) to be merged as ‘Draft’, legal tweaks to follow. “Extended Metadata” (‘CIP6’) flagged for comments and updates next two week. “Wallet Checksum” (‘CIP4’) to be merged as ‘Draft’ in 2 weeks. --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | 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 | :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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-10-20.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [October 20 2020 notes](#october-20-2020-notes) * [Triage](#triage) * [Last Check](#last-check) + [Extended Metadata](#Extended-Metadata) + [Wallet Checksums](#Wallet-Checksums) * [Review](#review) + [Message Signing](#Message-Signing) * [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 10/20/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## October 20 2020 notes **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO) ### Triage N/A ### Last Check #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) **Frederic** “Extended Metadata” has there been updates? Appears this is still on hold - let's wait another two weeks, authors were absent and outreach for info needed. **Duncan** We should open it up to more people: maybe someone else might want to take it over?Let's not push it if there isn't interest. **Sebastien** We're waiting for info on explorers. **Duncan** As long as the authors are still engaged, that's fine. **Sebastien** ADApools is the one who setup an extended metadata format (the format the CIP is based on): we wanted their feedback on this proposal. **Frederic** Will Follow on. Ping them directly or invite them + authors. => **On Hold** #### Wallet Checksum ([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4) **Frederic** all good to go - (no objections). ### Review #### Message Signing ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8) **Duncan** Good feedback from IOG. **Sebastien** Voltaire voting is coming up, I would like for it to be merged now (as it was discussed on the last call). **Frederic** We're working in the context of "CIPs are a set of tools that implementers can pick and choose as they want" and it seems IOG might consider CIP to be canon for the main protocol.. CH brought up CRCs ("Cardano Request for Comments" - open discussion towards Cardano standards) - we touched to those in the past and at the time we agreed on proceeding with CIPs being non-restrictive. **Duncan** All things being equal, it's preferable to have one general guideline rather than three because of interoperability. Mild preference for a single standard for message signing. We lightly discussed merging this now last meeting, let's proceed. => **MERGING** now ### Discussions **Duncan** Suggest we move CIP5 into "Proposed" state, and require details of the plan while it's in "Proposed" state? **Frederic** "Proposed" must have defined metrics of acceptance/plan to Active. **Frederic** Propose we keep every 10 meetings as small (agreement). Propose we try out Crowdcast for next meeting. Need a Pr to fix numbering issues and links. **Duncan** We also need a better chart or table at top-level: a readme would be helpful... **Frederic** the (CIP auto gen site) is being managed by IOG; slow to get issues fixed unfortunately ### Close **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) re: comments and updates => Merge **NOW**: [“Wallet Checksum”](https://github.com/cardano-foundation/CIPs/pull/4) to be merged as ‘Draft’ (‘CIP4’) => Merge **NOW**: [“Message Signing”](https://github.com/cardano-foundation/CIPs/pull/27)to be merged as ‘Draft’ (‘CIP8’) --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | 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 | :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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-11-03.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [November 3 2020 notes](#november-3-2020-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) + [Extended Metadata](#Extended-Metadata) + [Wallet key generation](#Wallet-key-generation) + [HD Wallet for Cardano](#HD-Wallet-for-Cardano) + [Transaction Metadata Registry](#Transaction-Metadata-Registry) + [Cardano URI Scheme](#Cardano-URI-Scheme) + [ Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards) * [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 11/3/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## November 3 2020 notes **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO) + Markus (community) ### Triage N/A ### Last Check N/A ### Review #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) **F** - Last we looked at this CIP, the ask was for comments/feedback from major pools. Cardanians replied two weeks ago. **S** - Some parts we're still unsure re: security model - the RSS feel might not have been fully thought through. I think issues might have been addressed since. **M** - sorry was busy past month. I have some tech Q: what do we need to do with what is already existing from the CLI to generate an additional key? That key could be generated so the extended metadata can be verified, so Yoroi/Daedalus can accept the metadata. **D** - Are you talking about a first level metadata contains a keyhash and a URL (to the secondary metadata level)? **M** - Yes, to be more flexible for the 2nd level: no codekey to update the (2nd level) extended metadata but with some hash or verification mechanism. So that means another key should be generated (am against too many hashes onchain). **D** - We extend the first/primary level metadata with two extra fields: One is the PubKeyhash (that will be used to sign the 2nd level metadata) and the URL of where to find the 2nd level MD. The 2nd level MD is found at URL, and there is some signature that accompanies it (signed/verifiable against 1st lvl keyhash). If that is the case, you can change the 2nd level metadata without re-registering the pool. And also update the 1st level metadata without having to change the key for the 2nd level metadata. **M** - Right now we have a hash onchain of the prime metadata. I want to summarize fields so the proposal can start with "the minimum metadata". What I mean to summarize is that this CIP should contain a proposal for what "future extended metadata should look like" and I need your feedback on key types to use etc. **D** - Ordinary ed25519 key is the simplest thing to do. **M** - Need more time from Mike also - and need some feedback from other groups to weigh in - there wasn't much feedback unfortunately. This is a fairly easy and non-technical CIP. **D** - Focus on the details of the mechanism, but also what the exact format of the witness/signature. **M** - I'll try it out and seek your feedback in the PR through comments. **Matthias** - For signature, go with simplest: if that's embedded, or on the side.. We don't want to complicate things. **M** - From operative pt of view, if SPO wants to integrate, it should be straightforward. **D** - Two files ok? **M** - yes - because when ext-metadata file is updated then would need to do other file (signature). **D** - The CLI would validate the json and generate the signature for you... But still two files you host. **M** - Yes, some external tool / CMS whatever SPO has, can generate the new extended metadata file and you send it to the CLI, which creates the signature of the new extended metadata file. Probably need two URL fields in 1st level. Mike's feedback originally was that he didn't want to update base URL in .json. **D** - ok maybe two URL. => On Hold, Markus to add comments to which Duncan will follow up in the PR regarding scheme. #### Wallet key generation ([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3) **S** - Added test vectors and took comments on the PR. A Fairly small CIP, bulk of is the Test Vectors. I got them from Matthias and some independantly tested on the Yoroi codebase. No problems with Keygen. **M** - I intended to review and approve last week, thanks for the TVs - no issues. This is an excerpt of a diff doc we reviewed as a team - used to be part of Adrestia userguide/docs. The masterkey gen was extracted from the docs into this CIP.. **S** - This comes from the Adrestia docs and Trezor documentation and I added extra about the passphrase feature... Also added the passphraze feature for Ledger which wasn't in the docs. When creating via Trezor and selecting the 24 word option it uses a diff alg that nobody knows of (Matthias: "yet"). **D** - Fine if you both approve this. **M** - All the new wallets are using the Icarus version, the more prevalent standard - I propose we add that to this CIP that for new applications we recommend this version. (agreement). => Merge in two weeks #### HD Wallet for Cardano ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP1852) **S** - This one has a lot of history behind it - we had to represent that new staking key and needed it to be deterministic so Yoroi and Daedalus had to have the same staking key. The easiest way is to just derive it from the Master key so we added a new chain derivation. We added a chain derivation we added a 2-chain & called it "Chimeric account" which came from jormungandr (due to originally keys were the same). We could rename it for "staking key chain"... **M** - We just started calling it "Roles". We also use it for the multisig key. I would push we publish this CIP very soon. **D** - I think that's most sensible terminology.. **M** - Catalyst team decided to have complely different HD tree, so completely diff mnemonic - the rationale is that the voting wallet should be completely separate and independant from the voting wallet... **S** - Bad idea likely but we can discuss some other time. I'll rewrite the CIP. Do you want every new role we add to be a separate CIP? **M** - I would prefer one explaining the general naming, and then individual CIPs for new roles we add. But open to doing PR to that one CIP also for reference... Can do the same as we for Metadata Registry. **S** - I'll split this CIP in two parts then (a CIP for allocating numbers and a separate CIP for the specific role itself) => ON hold, Sebastien to split into two #### Transaction Metadata Registry ([PR](https://github.com/cardano-foundation/CIPs/pull/34) - potential CIP10) **S** - Every Tx in Cardano contains Tx Metadata, stored as a map of unsigned numbers to CBOR. We can use this map as a namespace, but to have it be as an effective namespace we need some sort of registry where people can document what number they are using for what purposes, and/or define possibly reserved/specific ranges. **S** - The SPOCRA ppl already started metadata and have 200-300 Tx on mainnet. They will probably be the first to allocate numbers... **D** - Let's setup a private range now. Start with '0'. We should be explicit... ex 0-255: 'reserved'. We should have a small and large reserve range. Proposing we go with [0-15] - (agreement). Also [2^16 to 2^17 - 1] for private use, so that guaranteed not to clash with interoperable ones. => Merge **NOW** (as other CIPs will depend on this / need the draft). #### Cardano URI Scheme ([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP) **S** - We will need to change and merge two CIPs together. Moving on. #### Treasury Fraction on actual distributed rewards ([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP) **S** - This was on the agenda so we can get Duncan's take on who should be involved. **D** - Lars Brunje. He'll direct through the right teams review and provide feedback. ### Discussions **F** - Crowdcast issues. Will follow-up and attempt to resolve for next meeting. ### Close **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - extend conversation in PR. **ON Hold** [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/27) (potential ‘CIP1852’) - to be split into two PRs by Sebastien **ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - Requesting feedback and review from scientists => Merge in two weeks: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’) => Merge **NOW**: [“Metadata Registry”](https://github.com/cardano-foundation/CIPs/pull/34)to be merged as ‘Draft’ (‘CIP10’) --- ## 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 for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | 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 | | 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-11-17.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [November 17 2020 notes](#november-17-2020-notes) * [Triage](#triage) * [Last Check](#last-check) + [Wallet key generation](#Wallet-key-generation) * [Review](#review) + [Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards) + [Extended Metadata](#Extended-Metadata) + [Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets) + [HD Wallet for Cardano](#HD-Wallet-for-Cardano) + [Cardano URI Scheme](#Cardano-URI-Scheme) * [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 11/17/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## November 17 2020 notes **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Colin, Lars (IO) + Marek, Federico (community) ### Triage N/A ### Last Check #### Wallet key generation ([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3) **S** - minor column changes being added. Merge Once reviewed by Matthias. => Merge as soon as reviewed ### Review #### Treasury Fraction on actual distributed rewards ([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP) **Lars** - A portion of the rewards pool is UNSPENT every epoch - very early, it was planned to go to the treasury (old scheme) - which reduced to about 50% going to the treasury, so now what is left goes to the reserves, which is good because Reserves last longer with Inflation. The CIP Author however highlighted that this however, means somehow a double taxation setup, where the same coins get taxed over and over. The suggestion is to change "when" the 20% go to the treasury, the suggestion is that it not be taken from the pot but rather from the rewards.This was mentionned to Aggelos also who agreed it was a good idea. Might have to adjust the rate to account for the changes. **Federico** - exactly - We're proposing that we apply the Tau param on the real distributed reward, not the reward pot itself. Our proposal is based on what we need to change in the specs to achieve that result - so instead of calculating the fractionning at the beginning of the process, we move Tau application on the distributed rewards. Shouldn't be too technically challenging to implement. **Sebastien** - Do you specify a percentage in here? **F** - No, this is simply a proposition so the conversation can take place. Now, we don't see the big difference we were seeing before. Ex: with the arrival of Binance the ammount of delegated ada went from from 50% to 65-66%. Still, we're experiencing real 30 - 35% Taxation rather than the 20% that is specified by Tau param. **S** so next steps is to merge this PR then go to IOHK to look at percent **Colin** Q in terms of actual calculation: Right now the epoch expansion is kinda scaled by the participation rate. The rewards are as if all the stakes was pledged and received pledge reward. If we just divided through the Epoch reward by 1+a0 parameter... (Back and forth about Monetary expansion setup) **F** - Tau levvy is applied on reward pot before calculating rewards (+Frederic +Lars) (Looking at [ledger specs](https://hydra.iohk.io/job/Cardano/cardano-ledger-specs/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec)) **L** - Page 62. Middle of the page. Jarod ideally the good person to ask (or Philipp). **D** - Before the shelley release, we changed where unpaid ada went - to Reserves. It looks like there is a sentence off in there: "The difference between the maximal amount and the actual amound received is added to the amount moved to the treasury" it should say go to reserve, not treasury. **D** - Probably correct in the mathematics but not the prose. **L** - It says october 2019 which seems old? **D** - You're looking at the right version - Delta T1, is the ammount that goes to the treasury. The change to the reserves is Delta R1 and Delta R2. The formal spec is correct, the text is off, should be ammended. **F** - The discussion is about the unclaimed rewards, for varied reasons. We want to minimize the multi-treasury taxation. **S** - Two pts. double taxation. convo can happen offline. Changing Tau is not a HF event. **D** - I agree taking the Treasury percentage at the end rather than the beginning is a reasonable thing, but would also need a HF. Let's get specific changes in the CIP itself and review then. (=> To be followed up on structure-wise next meeting, pending added clarifications) #### Extended Metadata ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6) **Frederic** - Some conversation happened in PR but missing answers/followup **Matthias** - I don't think there is any edition problem. I would like to see this merged as a Draft and let the convo continue. **F** - I'm with Matthias, would want to move this and let conversation continue as Draft. **D** - It's distracting to have contingent conversations about content, easier to start with a detailed mechanism. Then we can add to it incrementally. **S** - Pushing out to next meeting. => Follow-up next meeting. #### Staking Key Chain for HD Wallets ([PR](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP) **S** - This is one of the two CIPs I split 1852 in. This one specifies the key/derivation path. **M** - Haven't reviewed. will do until next meeting. => Merge in two weeks pending Matthias review #### HD Wallet for Cardano ([PR](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP1852) **S** - The other CIP from 1852. This one is intent as the registry of the different chains used in Cardano. It uses 0/1 for BIP44. For example, If we were to add staking keys, then those would be added here, so we can know which index means what. => Merge in two weeks pending Matthias review #### Cardano URI Scheme ([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP) **S** - Could be merged ... but nobody has had time to review yet. => Move to next meeting ### Discussions **F** - We tried Crowdcast and reverted to GMeet. Want to push [Crowdcast](https://www.crowdcast.io/cips-biweekly) going forward (=> did sync post-meeting: all seem sorted out). Had a Github history mixup due to force Push: reminder to be careful, now CIP10 inception only in history from a side reference. Yet want to consider force-pushing meeting notes rather than awaiting reviews, as they keep taking longer. Conversation was setup with R. Moore's team to take over the [cips.cardano.org](cips.cardano.org) site for next week. Note that [PR #42](https://github.com/cardano-foundation/CIPs/pull/42) WILL break the site further, but it will functionally be better flowing due to minor tweaks. ### Close **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - another two week hold potentially merging depending on week convo/Duncan. **ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider => Merge in two weeks: [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (potential ‘CIP1852’) => Merge in two weeks: [“Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (potential ‘CIP’) => Merge **NOW**: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’) --- ## 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 for Cardano](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 | | 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2020-12-08.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [December 8 2020 notes](#december-8-2020-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR37 - Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets) + [PR33 - HD Wallets for Cardano](#HD-Wallets-for-Cardano) * [Review](#review) + [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme) + [PR45 - Cardano Protocol Parameters](#Cardano-Protocol-Parameters) + [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication) + [PR15 - Extended Metadata](#Extended-Metadata) * [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 12/08/20 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ ## 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. ## December 8 2020 notes **Attending Editors**: (Duncan, Frederic, Matthias, Sebastien). ### Triage N/A ### Last Check #### Staking Key Chain for HD Wallets ([PR37](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP-0011) **Matthias** - Good to merge and proceed. => **MERGING** now #### HD Wallets for Cardano ([PR33](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP-1852) **M** - This one actually should be merged first since PR37 references it. It will function as a Hub for all the extensions going forward, such as staking keys, multi-sig wallet keys (using same purpose but different chain).. => **MERGING** now ### Review #### Cardano URI Scheme ([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP) **S** - The issue is there is another multipool wants to merge into this one and have not heard from them, so not sure if we want to merge this and then merge the multi-pool in after - ok with either option. PR25. They were intent on merging into this CIP. Could deal with it later. **F** - Could we merge their PR rather than this? **S** - This one is ready to go, would be fine as-is. **M** - Going through it... There is no existing implementation of that is there..? **S** - Yes there is, Yoroi/Extension - the code is opensource **M** - Format is good, Grammar fine, we could add it in. Addresses are said to be base58 - we want to add Bech32 in there. => Merge in two weeks #### Cardano Protocol Parameters ([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP) **F** - Pushed by IOHK's Kevin Hammond, this is looking at the intial Protocol parameters as pushed in the genesis file. **M** - For Mainnet. **S** - Makes sense - concerned the actual OnChain version drifts from this CIP but could deal with that. **M** - Would like to structure this by Era - which would be easier. It could be something that might be mentionned in the CIP expaining that Parameters can drift. **S** - If we can auto-generate this, that would be ideal. **M** - It doesn't exist yet as a service if we want to automate it. I like the idea of the CIP however as explanining things. **S** - What next? **M** - Would require changes: disclaimer, link to genesis file... **F** - Doesn't the genesis file reflect the actual parameters as-is? **M** - Only at genesis - the parameters themselves can be updated OnChain through a special kind of transaction. To figure out what the current actual parameters are, you basically have to go through the rest of the chain and cherry-pick the blocks that have those special transactions, iterate from genesis and apply changes. **F** - Adding this in this PR sounds useful. **M** - Could be, also to identify out of those parameters which are updateable, and which are not: for example, the epoch length and slot length are not updateable, but the transaction max size it. **S** - I assumed this CIP was if people would want to propose parameters changes - if we want to make this we want to change. **Marek** - for this particular CIP I see this as for the *intial* parameters, not sure if this deals with *changing* the parameters. **Duncan** - Romain wanted this a a CIP to get feedback on the initial parameters, because they can be changed. While it's still centralized, changes could be made to IOHK through this CIP... I think we should decide amongst ourselves what the best method might be: this as a living CIP or rather people proposing follow-on CIPs. Whichever fits the CIP process better. While we still have centralized governance, give some decentralized input. We're transitioning towards decentralized control. While the OnChain gov is centralized, this mechanism can provide input for that. **S** - Prefer this CIP be modified for each changes, and then when a new genesis block is added we flag it here. **Markus** - I like to have this CIP for intial params. This should have happened before. If we do it for future changes, then it would be better as a *new* CIP. I agree with Matthias - should be made clear which can be tweaked and which require a HF for change. **Matthias** - Do you mean one CIP per Hardfork? **Markus** - At least for every HardFork, maybe for protocol updates. **D** - This only contains updateable characters. **Matthias** - We should add the non-updateable parameters then (of the genesis file) **D** - Good idea. **F** - I think it'd be easier if kept in one CIP. I think both can work, Markus' option should be explored. **D** - Another CIP would enable a fleshed out rationale. **Markus** - If we do through PRs for soft-changes and new CIP for Hardforks, then we should rename this one. **D** - This CIP should highlight how future changes would be done. **F** - This one as Standards might be better as Informational to support the state of things. **D** - Advantages are that for "at least this moment" they are proposals, and not enactments. Always the point of CIPs, providing a filter for things that are sensible, so some things might get proposed but other competing ones might get implemented. Let's put in this CIP a Proposed way about proposing protocol changes. **D** - Let's propose the changes rather than burden Kevin? Change to Informational & others. **Marek** - will work on it. => Review in two weeks #### On-chain stake pool operation to delegates communication ([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP) **Marek** - When looking at the communication between SPOs and Delegates from the perspective of the chain, we have 3 main channels, such as Offchain, Metadata-based (ex:CIP6), and for cases where you want to be OnChain. Benefits and disadvantages, but this is verifyable, auditable. I think the format is not as important as to how we will send the metadata. Two ways to send, distinguished by label. I wanted to open it up for discussion, still working on change requested. **D** - Why do this rather than a RSS feed... Why want it auditable? **M** - We're seeing Phishing on behalf of SPOs for example, the usecase here is for direct communication. So SPOs can ask delegates gradually or with certain ammount of stake. This enables directed communication. Adapools.org does the communication offchain. Cost is a feature, for example wallets could have granular control... Another advantage is the history here. Not sure how much this will be used in the future but wanted to cover that space. **D** - Seems focused on folks that work on the Wallet frontends. **Matthias** - I don't think Darko would have any problem with having multiple CIPs for this, the implementation would fall on my team. **S** - I think this is nice to have. I'm not a fan of markdown as too much of a risk sent to wallet. I prefer simpler format. **Marek** - I was reluctant to send link to delegators even. **Matthias** - For security purpose shouldn't add links. If your delegators knows your pool, they should know where to get your official notfications. The msg pushed by the pool to delegator should be able to say "I am your pool, I have this message, please go see on my official channel for more". **Marek** - Because this has a cost associated with it, it might be interested for wallet users also - it disincentivizes the spam from the pool too. **D** - Reasonable proposal. **S** - let's remove the link part, and merge. **Marek** - will do changes now, can do now. => Merge in two weeks #### Extended Metadata ([PR15](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0006) **Markus** - I replied to Duncan's comment in the PR. I reworked the entire proposal and it now includes the basic principles of how to generate a signable verifyable extended metadata. I tried to do with the existing CLI but with ran into error with the existing TxSign. Using a standard json scheme, not existing. The Txfile requires an initial key name (?) type.. We either need to have the cardano type extended or design the scheme for the extended metadata. The second step is the calc. of the hash, tried with shelley stake pool metadata and raw json, error about filesize (>512b) **D** - That can be changed. **Markus** - Also, outside, I got asked why use this mechanism instead of the Tx metadata to push verification keys and signed Tx OnChain. It's feasible but would require fully sync'd chain and a dbsync instance. If one hasn't, then it's a trust matter. **F** - Sounds like a separate CIP - here the title could be clarified. Want this to be merged. **Markus** - Let's keep in mind: we need CLI support for this to be actually implemented. **F** - Right - Inclusion to repo does not imply it will be imlemented, hopefully support in CLI comes. **Markus** - Re: Focus on mechanism rather than content, if we don't include the most important fields for metadata, then pools will be using the existing, and not care. We should offer at least the most important ones. **D** - It needs both to be implemented and be used. Let's not pack too much into a CIP, this can be extended once it's implemented. => Merge in two weeks (?) ### Discussions - out of time - ### Close **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **ON Hold** [PR35 - “Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider => Last Check - Merge in two weeks pending approvals: [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) => Last Check - Merge in two weeks pending approvals: [PR44 - "On-chain stake pool operator to delegates communication"](https://github.com/cardano-foundation/CIPs/pull/44) (potential 'CIP-0012') => Last Check - Merge in two weeks pending approvals: [PR30 - Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/pull/30) (tentative 'CIP-00xx') => Merge **NOW**: [PR33 - HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (‘CIP-1852’) => Merge **NOW**: [PR37 - “Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (‘CIP-0011’) --- ## 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 for Cardano](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 | | 10 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-01-12.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [January 12 2021 notes](#january-12-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR15 - Extended Metadata](#Extended-Metadata) + [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication) + [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme) * [Review](#review) + [PR46 - Shelley Protocol Parameters](#Shelley-Protocol-Parameters) + [PR56 - HD Stake pool cold keys](#HD-Stake-pool-cold-keys) + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format) * [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 01/12/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## January 12 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** - Some minor asks. It doesn't look like much has happened since last meeting. **Duncan** - It's not something someone could implement unambiguously yet, because it's not described unambiguously. **Sebastien** - There seem to be no rush to merge as-is. The asks in the comments are rather straightforward, recommend they be addressed prior to merge. => Ping @Gufmar to address final tweaks on Github. #### On-chain stake pool operator to delegates communication ([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0012) **S** - I feel the protocol described is fine to merge as-is from a tehnical perspective and fine as-is. There were some concerns regarding format, but my suggestion was to go for the simplest thing possible. I feel that's done, so happy. Only point unclear was about the uncoding for the data - the encoding used is UTF-8 - probably not the optimum way to pass long data - we could use CBOR to pass it on in a more optimized way. **Duncan** - He's suggesting an array of text, each one at most 64 bytes... What would be the advantage of anything else (other than UTF-8)? I would keep it small. **S** - Visually (UTF-8 encoded in Base64) would be smaller, but would be bigger at the byte level. I feel it adds complexity but no significant advantage. **S** - Also I notice there is a conflict on the PR. They are modifying the master readme... Do we want to encourage authors editing the master readme file to add themselves? This wasn't part of CIP1... **D** - I would say no. It will always cause more conflicts than it serves. (Fixed the conflict.) => **MERGING** now #### Cardano URI Scheme ([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP-0013) **S** - Matthias looked at this a while back - no objection I think **Matthias** - I did then, it hasn't changed since December, is fine. **S** - There was a request to add Bech32, that was done. I want to move and merge this, will add number now. => **MERGING** now ### Review #### Shelley Protocol Parameters ([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-xxxx) **Kevin Hammond** - I updated this propsal and included ALL of the changes since Shelley into it. We now have a record for all param changes, appart maybe for 2.1 which may be mythical... **D** - Did we establish (from Sam) re:one? **K** - I can keep checking. **Frederic** - Did we come to consensus wether this should be era-specific? **K** - Up to Editors. What the Auditors wanted was a record of the initial settings, so the community can use that to base changes off, here was the rational for the choices for those params. What you're requesting is a chain tracking the changes. One thing you could do say the current params are the following, Here's a trace of all of the changes since the inception of Shelley plus a rationale for all of the changes. Which might be useful from a historic perspective. **D** - We did discuss last time. I think the conclusion we came to, is that proposals changes should be as standalone - fitting with the CIP context of proposals, not _definitive_. There is no commitment of any party to implementation, so really they have to be independant. I think it makes sense to update it when the changes happen on-chain. So proposals should be separate CIPs, well-reasoned proposals. And this should be updated here when it changes on-chain. But if people want to make proposals that should be as a separate CIP. I think we requested to provide a template to propose a param change. **K** - seems right, it feels that it might be on the Editor's role to provide that template. **S** - I'm ok with no template. Else I recall as Duncan, I agree changes should be standalone CIPs. I'm ok with merging meanwhile. **K** - What we could do is say any changes to Parameters should be submitted as a CIP including the name of the Parameters. **D** - this should be made clear in this CIP that the change proposals should be as separate CIPs, not as changes to this one. => Moved to Last Check #### HD Stake pool cold keys ([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-xxxx) **Michal** - We can add Rafael for the technical explanations. This proposal was added yesterday, but what we propose here is deterministic derivation of stake pool cold keys. We propose a derivation path as seen. Time is critical because we are trying to push this ledger app by the end of January. This approach will also enable to operate multiple stake pools from a single HW wallet. **S** Is it feasible to derive a hardened key from a non-hardened parent? **Rafael** not sure, maybe there are security considerations, thanks for avising. **S** - I don't recall off the top of my head. I can look it up. **M** - Tried looking on the BIP32 paper. We're going to have to spend more time into this to dispell concerns. **R** - The non hardened Index was really for convenience but could be replaced by hardened for convenience. (see last paragraph in the PR). **F** - the ask is to clarify the hardened feasiblity. Can we merge? Ok with numbering? **R** - For number rationale it's in line with 1852 as a root index. The stakepools aren't logically related, it should make sense to add it as a distinct index. **F** - As soon as we start diverging, it's opening the door to wild numberings for CIPs.. **Michal** - who will be responsible for validation on Hardened/non-hardened point? **S** - I just looked it up now, in practice it's allowed but it means you'll only be able to derive the cold key index from a private key. So if you have a public key of the usecase then you won't be able to derive any child keys. Having usecase non-hardened is kinda pointless. **R** - This was reserved for future cases. Someone may come up to proposal to derive non-hardened cold-key (for whatever reason). **S** - Is that why the usecase field non-hardened? **R** - Yes. In the rationale, we explain the non-hardened derivation usecase says that "in the future" it might be convienient to derive non-hardened cold keys. There could be future motivation for multiple non-hardened cases. **S** - So in the future we might need a table for all the usecase values, are you suggesting all usecases be soft-derived rather than mixed (hard and soft)? **R** - yeah **S** - I can't see why we wouldn't have hard only for now, and future non-hardened spectrum **R** - I can do that modification and point out that future usecases might take from the non-hardened cases (if it makes sense) **Michal** - Can we agree you do not see any issue with this CIP and that there are no blockers on path as-is (beyond the hardened thing). **F** - Even though there is a need to have this working from Ledger - there is no need to have CIP inclusion **Michal** - There is no functional blocker, but if we implement it in some way but later change how the cold keys are derived then we could have multiple derivation paths.. We should work on a decision that is final. **S** - Agree. I feel this is fine, including the numbering. **F** - It would be merged on the 28th if we move this to lastcheck. **D** - What does it mean when you have a level hardened and the sub-level non-hardened? **R** - right now for the coldkey index being hardened there is no real point, but for the sake of future proofness. The premise was that other usecases for the coldkeys might arise in the future and those future usecases might find it suitable to have their childkeys non-hardened. **D** - So 'some' usecase would have their (sub) cold keys non-hardened and some hardened. If 'usecase' is hardened then its hardened all the way own? **R** - If you have a usecase hardened, then you cannot use the root key (purpose & cointype) & use that to derive the usecase and child keys because those are hardened. But if usecase is non-hardened, then you can derive those. **D** - Is there a case in the future where you'd want to derive the 0th this as well as the 0th that? **R** - Yes. **M** - It sounds to me we are using 'usecase' as a different 'purpose'. It would be simpler without a 'usecase' and if you need a set of keys for a different Purpose then you pick a separate purpose... **D** - ex: we have SPOs now, suppose in future we have a governance mechanism involving onchain voting through some indirect democracy, where you delegate to someone and they vote for you. To register as someone that folks delegate to, that would be much like registering as a SPO and we would want to manage the keys the same. Same pattern. If I want to register as many ppl they would all be different. I think Matthias is right. Keep usecase but only for things that are really the same. But otherwise, use a different purpose. so all the conditionals can be under a purpose. **R** - Having the usecase hardened then? **D** - Yes. **R** - Agreed, and later (if somehow needed) we can still add non-hardened usecases. => Move to Last Check #### Catalyst Registration transaction metadata format ([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-xxxx) - out of time - ### Discussions - out of time - ### Close **On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting authors to review and incorporate feedback, thn will merge. => Merge in two weeks: [PR45 - "Shelley Initial Parameters"](https://github.com/cardano-foundation/CIPs/pull/45) (tentative 'CIP-00xx') => Merge in two weeks: [PR56 - "HD stakepool cold keys"](https://github.com/cardano-foundation/CIPs/pull/56) (tentative 'CIP-00xx') => Merge **NOW**: [PR44 - "On-chain stake pool operator to delegates communication"](https://github.com/cardano-foundation/CIPs/pull/44) (‘CIP-0012’) => Merge **NOW**: [PR30 - "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/30) (‘CIP-0013’) --- ## 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 for Cardano](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 | | 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 | | 1852 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-01-26.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [January 26 2021 notes](#january-26-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR15 - Extended Metadata](#Extended-Metadata) + [PR45 - Shelley Initial Parameters](#Shelley-Initial-Parameters) + [PR56 - HD Stake Pool Cold Keys](#HD-Stake-Pool-Cold-Keys) * [Review](#review) + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format) + [PR61 - Update to CIP-0013](#Update-to-CIP-0013) + [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 01/26/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## January 26 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** - No update from Markus - leaving as-is, reaching out to Markus. => Ping @Gufmar to address final tweaks on Github. Functionally on hold. #### Cardano Parameters ([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-0009) **Frederic** - Ready to go but missing some structure. Consensus was this is ready to be merged. **Duncan** - If it's simply the header, we should add this in and merge it. You can see the template for it, he added and removed it. **Sebastien** - Ok to merge by me. **D** - Remind the Catalyst group that this is not the PR for "proposing" but the informational one for updating. New CIPs for proposing parameter changes must be separate CIPs - conflicting CIPs can exist, but this should be the informational one. **F** - What about the case where a parameter change happens but this CIP does not get updated? **D** - Anyone would be able to come and push a PR with the appropriate change to update this. => **MERGING** pending internal discussion re: status. #### HD Stake Pool Cold Keys ([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-1853) **S** - We requested changes last time. **D** - There is a patch since last comments that we added - Last meeting we were looking at Hardened vs. non-hardened. Our conclusion was that the usecase fields should all be hardened: Now they are all hardened. **S** - Approving. => **MERGING** now ### Review #### Catalyst Registration transaction metadata format ([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014) **S** - This one is missing a CIP number but it's already deployed on mainnet. If someone wants to change working, this is already deployed. No opposition on wording tweaks. **D** - Did anyone else reviewed this and double checked the description corresponds to reality? **S** - No. This is just documenting what the Fund2 used 'in practice'. There were some test vectors and ideas but no formal writeup. **D** - Can we get someone from Catalyst to review the CIP? **S** - I'll ping on the topic and see. I also posted it in the Catalyst Slack channel as well. => to Last Check (to be merged next meeting) #### Update to CIP-0013 ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013) **Sebastien** - You may remember a while back we had that URI scheme and Robert wanted to add the support to create staking pool delegation through the URI scheme. We decided to setup what we had first, for the payment, but now this is adding another scheme. We want this so external websites can create URI links, that open accordingingly where they should. Since this is fairly related to the payment scheme, this should be bundled here, and might even later be expanded. This provides a source of truth that others can refer to. **Robert** - The formal grammar was reworked, added another authority for doubleslash spent, (there was also a discussion for metadata, the URI could be further extended), we'd want the protocol to evolve, this PR is just for single pools to be added to the CIP itself. **D** - Why is it that we want to custom URL schemes rather than a MIME type? **S** - Yoroi is a browser extension. Whenever you select such a URL it'd open Yoroi (or Deadalus) appropriately.. **D** - Browsers have for decades been dealing with application associating with MIME types. This is my first time I see custom URI scheme - yet am not a web-dev. Presumably this works for mobile phones also. Is this common practive? **S** - It used to be more contractors like mailto: and so on. Back then we could embed skype links etc. But it got too complicated and they created a whitelist of URI prefixes and not being on the list is no bueno. The recommended approach is to use an existing prefix which is why the URI scheme starts with 'Web+Cardano'- they still let you do it but in the namespace. Bitcoin (because it was created a while ago) managed to make it to the whitelist because it was created a while ago. **D** - They still encourage you to do this rather than file + MIME types? **S** - As far as I know. Have never seen MIME types used rather than this anywhere. **D** - The QR codes? **R** - QR codes are just enconding of URLs **S** - Chrome has poor support for this but Firefox had. Unfortunately Chrome is winning the browser war. The support for the APIs are the bare minimum for the browser extensions / functionality to work, while Firefox has better thought out support. The only people that recommend specific setups are mobile apps, such as registering directly with your App: Instead of using a URI scheme, they link to a specific page and you have that specific page register with your app to check if it is installed, and if installed open the app... **D** - Thanks for the digging into things. **R** - This was explored in the closed [PR25](https://github.com/cardano-foundation/CIPs/pull/61) - Sebastien had answered it there. I'm a webdev, I integrate with websites and whatnot. Some schemes are more popular than the community realizes because of torrents and others... At least knowing we can rely on URI consistently would give the SPOs and end users at least one consistent option that is well supported. **D** - One more Q: Can you use a combination of MIME/URI? **S** - You cannot. It's not possible. **D** - Why do we allow pool tickers given they aren't unique rather than their IDs? **S** - The rationale is to accomodate for pool operators that have multiple pools with a common prefix. So they may want to have a URI to the common prefix and the wallet would be in charge of managing it. => to Last Check (to be merged next meeting) #### Update to CIP-0010 ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010) **F** - This is an update to the registry entry - not sure what this does. **D** - It sounds like he wants CIP-0010 using a machine-readable format (on top of the existing human-readable format). He's given examples and a schema for how it should be added and implicitely the registry should fit that schema. **S** - This seem to make sense in theory. Slightly concerned that these two (formats) will not sync up and we'll run into issues with one no longer matching the other? If we were to only pick one I would pick the machine-readable format and would avoid having both. **D** - Avoiding duplication typically sensible. => Move to REVIEW for next meeting + reaching out to Author (Marek). #### Key Serialization formats ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-xxxx) **S** - Have not been able to review. **D** - I've not properly reviewed yet. The intention here is to complement the prefixes CIP - this one here would be looking at the format of those keys for historical reference and documentation: This CIP is intent on describing what the FORMAT of keys is about - due to historical complexity and so no. That's from the 3 types of keys. Edd25519 keys, ordinary verification and signing keys, also the Jormagandr "extended keys" and later the "BIP32" keys. (One of those format should never have existed but Jormagandr added it anyways). **S** - There is a good [Forum post](https://forum.cardano.org/t/message-signing-specification/41032/5) describing things, and it lists 4 formats. **D** - We should be careful reviewing this, should flag to Matthias. The two recommended forms, and also for historical reasons the other ones still used by the older tools, intended to be never be used yet used as extended version by some tools... but not recommended to use. We should probably take this CIP over from here, this should be a good starting Draft. => Move to REVIEW for next meeting. ### Discussions **D** - [PR55](https://github.com/cardano-foundation/CIPs/pull/55) looks like it's simple / ready to go and should be merged. **S** - Let's merge it. (=> merging) **F** - Mentions about using Tags in the repo if anyone has preference. Also regarding publicizing those meetings. **D** - Also let's add [PR31](https://github.com/cardano-foundation/CIPs/pull/31) to next meeting. Looks ready to be merged even. **R** - [PR61](https://github.com/cardano-foundation/CIPs/pull/61) has 2 reviews, but 1 of those isn't from an editor, are we awaiting for some other kind of review? **D** - Correct, awaiting another Editor review. Will look into [PR61](https://github.com/cardano-foundation/CIPs/pull/61) and give it the green tick for next meeting. ### Close **On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup **On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting last tweaks. => Merge **NOW**: [PR45 - "Initial Parameters"](https://github.com/cardano-foundation/CIPs/pull/45) ('CIP-0009') => Merge **NOW**: [PR56 - "HD stakepool cold keys"](https://github.com/cardano-foundation/CIPs/pull/56) ('CIP-1853') => _Last Check,_ Merge in two weeks: [PR58 - "Catalyst Registration transaction metadata format"](https://github.com/cardano-foundation/CIPs/pull/58) (tentative ‘CIP-0014’) => _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013, adding delegation URI scheme](https://github.com/cardano-foundation/CIPs/pull/61) --- ## 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 | | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-02-09.md ================================================ **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. _Notes might contain errors or miss pieces - call out issues as needed_ 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-02-23.md ================================================ **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. _Notes might contain errors or miss pieces - call out issues as needed_ 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-03-16.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [March 16 2021 notes](#march-16-2021-notes) * [Triage](#triage) + [PR62 - Update to CIP-0010](#Update-to-CIP-0010) * [Last Check](#last-check) + [PR61 - Update to CIP-0013](#Update-to-CIP-0013) + [PR65 - Update to CIP-0013](#Update-to-CIP-0013) + [PR64 - User-facing Asset Fingerprint](#User-facing-Asset-Fingerprint) * [Review](#review) + [PR57 - Key Serialization formats](#Key-Serialization-formats) + [PR66 - Fair Min Fees](#Fair-Min-Fees) + [PR21 - Non-centralizing Rankings](#Non-Centralizing-Rankings) * [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 3/16/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## March 16 2021 notes **Attending Editors**: Matthias, Sebastien, Duncan, Frederic ### Triage #### Update to CIP-0010 - ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010) **F** - I think I might have been getting the request for rebase wrong, is this correct/good to go here? **M** - This PR wants to keep things separate = moving content to a different location, out of the readme file. This PR makes the registry easily parseable by tools, instead of having to manually parse a readme. The dynamic one you want to have in a structured format. Checking in as it was rebased last week... Looks good. => Merging **NOW** ### Last Check #### Update to CIP-0013 ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) and [PR65](https://github.com/cardano-foundation/CIPs/pull/65) - Updates to CIP-0013) **Frederic** - Both 65 and 61 were setup as "Last Check". To be merged this week if feasible. **Robert** - I don't know what PR65 woud actually do: There's really only been one technical description of how the SPO links would be added to the URI scheme. PR65 is incomplete. So CIP-0013 should be the one that has been outlined: PR61. Suggesting PR65 as a separate CIP would be logical. **Duncan** - Can we go over the differences between PR61 and PR65? **R** - The resistance that Nick had to using the StakePool names as keys also would prevent them from having values. So when the StakePool links would be accomodating the delegation portfolios and we have a problem with not being ablt to use pairs and have to use a complicated schemes with tuples in order to assign these stakepools a value in a haphazardous way... and that's been the question we have asked for PR65 / during the previous CIP Editors meeting. I think Nico wanted to note there were some things that were technically not attractive about using the highly variable stakepool names as keys instead of predicable ones but unfortunately that's the only way to make the representation scheme concise and resistant to errors. **D** - And then the ones that has to do with the security issue is involved with names, they have to use local lists and so on, which pools they actually refer to. **R** - That seems like it would be a challenge for BOTH approaches: You will always have to check the consistency of the stakepool name anways, the Question is weither they will be keys or values. **F** - The two approaches should be fine if conflicting - Sebastien? **Sebastien** - Just conflicting about which should get the "CIP13" name. Maybe make more sense as "CIP13a + CIP13b". However I am not sure we want to go down that road. **D** - I think they should be standalone CIPs if they extend a specific CIP. If genuine disagreements that is, we just want to make sure what is proposed is a well formed technical proposal. **S** - Originally there seemed to be only one path - I know that for Emurgo we will go with Nico's. **R** - Hard for me since I can't see what the alternative URI would be. **S** - It's been informally described, in github comments and such. 65 is not up to date. **R** - PR65 says "it's wrong to use the stakepool names as keys" and wrong to use "stake" where we really should be using "delegate" for stakepools. But the question of what happens when the values themselves need to have values was never addressed, except perhaps privately as noted by Sebastien. So we've been really discussing the idea that the stakepool names actually can be keys, becaue they are expected someday to have values when we have delegation portfolios. It seems when the links have to refer to delegation portfolios and the stakepool keys need to have values this would cause problems. **S** - It looks like PR65 is up to date. **R** - But it doesn't address the question about when you have to associate a value or a proportion with a stakepool - so in that sense it is incomplete. This actually was a PR for an independant CIP on the 29th of September 2020. Sebastien suggested in October this be reintroduced as a change to CIP13. The Original CIP still had a more thought out plan. **D** - Summarizing: The concern is we might be merging (in CIP13) something that might make future things more complicated for multipool delegation, and you want some consideration to take place to think about either is more useful down the line than the other.. **R** - Right, would be useful. We have all the info for 61 but not yet for 65.. **D** - Sebastien can we add more content in there? (for 65?) **S** - Yes, on the todo list for 65. I don't mind waiting for merging this. **R** - It looks like Emurgo has stakepool links for 2021. **D** - All things equal, merging things quicker is better. But we want to make sure we have a design that isn't prematurely merged and can extend to multi delegation pool. **S** - We are the only company that has implemented CIP13 and the extension for now as far as I know. So I don't mind waiting until Nico adds in the changes he wants to add. **R** - We may not be rushing to implement it, but if this stakepool links scheme were available, then the SPO would be rushing to implementing it. **S** - I don't think so as no wallet would be implementing it at that point.. **D** - If we do have a closeback that people are happy and agree on then it's much more likely to be implemented in Deadalus.. **R** - right, this is a lot easier to consider implementing on something that has been agreed on as a standard... **D** - It sounds like we want to wait at least a little bit to see where things go... What would we be waiting for and who would be writing the extension from here? **S** - I can have Nico add the missing parts for 65 within two weeks. **F** - This might be for a separate group - the CIP platform is not intent on saying which is better. Looking too far freezes us. **S** - I agree. And propose a/b options. **D** - Happy to wait a reasonable ammont of time. Yes we don't want to block, but we could see if there is a consensus resolution that might make things easier. If we don't have to have competing CIPs, better. This isn't so urgent, no wallet yet implement it, if we can spend a little bit more time that everyone can agree on is worth it. **R** - Let me know if there are unanswered technical questions and I will jump into it. **D** - Will it be clear to Nicolas what we are interested in here? **S** - Yes. **R** - I would like to see things in the open so we can make sure it's not (in fact) a bureaucratic issue. **F** - Tabling 61 and [PR65](https://github.com/cardano-foundation/CIPs/pull/65) - they were as "Last-Check" but now pushed to "Review" stage. => Moved [PR61](https://github.com/cardano-foundation/CIPs/pull/61) & [PR65](https://github.com/cardano-foundation/CIPs/pull/65) back to "Review" for next meeting. #### User-facing Asset Fingerprint ([PR64](https://github.com/cardano-foundation/CIPs/pull/64) - User-facing Asset Fingerprint) **S** - The main thing with this one was dealing with the merge conflicts. I think that's done. **M** - Hasn't changed in a fwe weeks. I added in a typescript implementation from Sebastien. **S** - Implemented by a few places, Daedalus, Yoroi, Adalite, Blockfrost... Good to merge. **D** - adding my green tick as well. => Merging **NOW** ### Review #### Key Serialization Formats ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016) **F** - This is looking at the various keys using accross Cardano. Matthias did you go over this one last time? **M** - Maybe "Cryptographic key serialization" format is a bit too generic, because we don't really touch to vrf or other types of keys: We could maybe rename this CIP. **D** - I have not looked at this one recently and this is one of the ones that requires more brainpower. We have a new Cryptographer that just joined, this might be a good task to look into to review and check if the CIP here is comprehensive. The good thing about this CIP is that this is documenting - so this just needs to be accurate. **M** - This implements exactly what we have in both Cardano Adrestia and Cardano CLI and was discussed in Slack historically to agree on forma... Really how we want to serialize things and how does it compare to existing implementation and before (basically Jormungandr). The new one is more on the compact and it does recomputes some things on the fly. I guess both are fine but we could ask cryptographers, and maybe there's a good reason to package the private and public key and not recompute it all the time. We could almost go one step further: This specifies the datapart of the Bech32 payload that we specified in [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md), but only for 4 of them. We have maybe 20 objects or so now in CIP5... so we could go for an expansion of CIP5, starting with the keys, but also going into payloads. I think we could document all of them. This very strongly seem to connect to CIP5, so maybe we should make that connection a bit more explicit. **D** - Right, this is covering the greater compatibility issues. I feel someone should spend some time and brainpower on this. Because Matthias and I are rather busy.. **M** - agree. **F** - Forward to Cryptographer at IOHK, Duncan to flag. **D** - The new cryptographer just started (so two weeks too short). => Moved OUT to give time ... #### Fair Min Fees ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - potential CIP-0017) **F** - This is about Minimum fixed pool fees. Flagged to Colin and Kevin who are taking it to the researchers.. We might not be able to look at it as-is. **D** - Unless there is a strong push from authors or other we should wait for follow-on from researchers. => Moved OUT to give time (for research) ... #### Non Centralizing Rankings ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - potential CIP-0018) **D** - This one makes sense to wait as we need to figure out how the order of the changes must align with the system - here changing the underlying assumption have to come first, then the utility function... Shawn understands, that's why this one is on how. **F** - Can we look at the spec changes themselves? **D** - This is referring to the [design document](https://hydra.iohk.io/build/5737201/download/1/delegation_design_spec.pdf). If needed the repo [Readme](https://github.com/input-output-hk/cardano-ledger-specs/blob/master/README.md) has links to all the docs. **F** - What does non-myopic mean here? **D** - Myopic is what happens "immediately", non-myopic is "in the end" / at equilibrium. So non-myopic is "k pools saturated in the end. Shawn's proposal is that we not use the non-myopic and have all pools saturate. With my non-editor hat on, I don't agree with this proposal here. But that's why it's worth discussing with researchers. It's completely well written. On the technical grounds I happen to disagree with it, but isn't relevant as an editor, but we could see what comes out of that discussion. **F** - Communication in the Github Thread has been very helpful to provide visibility - will flag to researcher and remind to update in the github thread themselves. => Moved OUT to give time (for research) ... ### Discussions N/A ### Close => Merge **NOW**: [PR62 - Update to CIP-0010](https://github.com/cardano-foundation/CIPs/pull/62) Update to CIP-0010 => Merge **NOW**: [PR64 - User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/pull/64) (‘CIP-0014’) => Moved OUT to give time (forwarded to cryptographer) [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’) => Moved OUT to give time (for research) [PR66 - "Fair Min Fees"](https://github.com/cardano-foundation/CIPs/pull/66) (tentative 'CIP-0017') => Moved OUT to give time (for research) [PR21 - Non-centralizing Rankings](https://github.com/cardano-foundation/CIPs/pull/21) (tentative 'CIP-0018') => Moved OUT to give time (for contrasting with 65) [PR61 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013 => Moved OUT to give time (requesting extra details) [PR65 - Update to CIP-0013](https://github.com/cardano-foundation/CIPs/pull/65) - Update to CIP-0013 --- ## 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-03-30.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [March 30 2021 notes](#march-30-2021-notes) * [Triage](#triage) + [PR71 - Update to CIP-0015](#Update-to-CIP-0015) * [Last Check](#last-check) + N/A * [Review](#review) + [PR57 - "Key Serialisation Formats"](#Key-Serialisation-Formats) + [PR69 - "Multi-signatures HD Wallets"](#Multi-signatures-HD-Wallets) + [PR75 - Update to CIP-0015](#Update-to-CIP-0015-1) * [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 3/30/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## March 30 2021 notes **Attending Editors**: Matthias, Sebastien, Duncan, Frederic ### Triage #### Update to CIP-0015 ([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015) **Matthias** - Sebastien added test vectors in there. I feel that the whole Catalyst framework is moving faster than the CIP is progressing on the subject. We have a few PRs about this CIP-0015... **Duncan** - Sam and Sebastien are reliable sources - should be good to go.. **Sebastien** - The test vectors work, but they only work for Fund3 - and there's a separate PR, there's two basically for Catalyst. One is for the test vectors and the other is for updating the Catalyst specifications for Fund4: Fund4 adds a new key and also changes the signing scheme: you no longer sign the full metadata payload but rather now sign the hash of the payload. This PR (which is adding test-vectors) will have to be updated because the vectors have changed. The other PR (which adjusts the specs for Fund4) is still innacurate I believe. => Moved out and adding comment in the PR to touch/Update ### Last Check N/A - (PR61, see below) ### Review #### Key Serialisation Formats ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016) **Frederic** - This is looking at the various keys using accross Cardano. **Matthias** - Inigo, a specialist cryptographer, has been reviewing this PR. The whole CIP is itself pretty straightforward, just putting down something that already exists and have a sanity check on it. And the feedback was positive. We knew it was designed by the previous cryptographer, and so now we have the ok from the new Cryptographer. **Duncan** - So Inigo looked at PR57? **M** - Yes. We had a chat and he wondered on the best way for feedback (if any) and I flagged that Github PR comment was the best way. He left a Review, although not part of the org. Review was OK. One note about endianness - and the question was about specifically wording it out... But since it's generalized in most places as big-endian, it would be fine to leave as-is. **D** - It might be better form to simply note it as "Like in most other places, this is big endian" **F** - Moving the status to "Last-Check" (to be merged in two weeks) => Moved to Last Check (to be merged in two weeks) #### Multi-signatures HD Wallets ([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854) **M** - This is putting down what we've been designing for the multi-sig wallets. This adds new derivation paths to the 4th level of the HD tree like we did for the stake keys, but this one dedicated to multi-sig keys. This also describes how multisig wallets should work, discover addresses and communicate with each others using addresses and keys generated from this new HD subtree. There is an implementation on the Cardano Wallet as we speak that is already here. It hasn't been added to the PR yet but might be added later to link and show how this work. **D** - Sebastien - Does Emurgo have any future supporting plans for multisig generally? **S** - We had some concern about no multisig coordination server. There are a lot of projects where multisig would be useful. **M** - The multisig coord server will happen, but separate from this CIP. We've left out any sharing of the multisig, or the partial Tx here. But later, we'll expand with the coordination server, expected to be a partial publish-subscribe broker (you subscribe to specific channels, send your partial Tx in, and every listener gets it and can reply to your channel). This would be done ideally behind the scene by wallet softwares. This CIP is really how to manage the wallet keys in the context of shared wallets (called "shared" over "multisig" because they can also be used in many context, for example Catalyst). The idea is to define a particular template for wallet: monetary scripts with placeholders as keys for each cosigners and every instance of that template simply instanciates all keys at a particular index. The same index is used for all cosigners, and if the same cosigner appears multiple time in the template, we also use the same keys index for a particular instance. For a particular script, all the keys are derived from the exact same part to the tree of all the different cosigners' wallets - which makes it easy for the wallet to keep track of what index to use for the next address, and discover their funds / to verify the addresses belonging to their cosigners. **D** - It makes sense to break it down with the server as out-of-scope (intermediate Txs etc). Interested when we get to that. **M** - We have a few drafts on that already **D** - Let's discuss further as this touches Alonzo **M** - This CIP in the end is pretty straigthforward: All cosigners have the same index, so it makes it easy to verify. When you see a particular address you just have to discover your own key inside it, and you know that all your cosigners have used the same key, and since you have your cosigners public keys and your index, you can derive their child keys. All is derived from the structure itself, but we're also going about it sequentially. Indexes are sequential, but also we're tracking with a gap, so standard practice. It's an extension of CIP-1852 (second extension) **D** - Examples were using purpose as '1852', shouldn't they be using 1854? **M** - No, the role is changing but the purpose is the same. **D** - How is the script template setup? **M** - We use the exact same as a script but not locked to a type, and instead of a keyhash we use a cosignerID. The template is just a script with cosignerIDs and when instanciated you replace all cosignerIDs with proper keyhashes. So it has the same representation internally and also externally in interfaces we typically use json. We have a way to represent as json and the same approach for template for the template with cosigners for keyhash. The mapping of the cosigners is defined on the side. **D** - And you're welcoming any template? **M** - Yes, the only constraint is that you cannot change the template. Using a different one would be using a different account on your wallet. To be able to recover, you need to know your key, the template and also your cosigners public keys. **M** - For the setup phase, when you don't yet have your cosigners public key: cosignerID is just 'cosigner #1' for example. In a way because there is a one-to-one mapping it's the cosigners public key. We didn't want to include the sharing of the keys through the multisig server because the MCS isn't going to be secured. For now at this stage the better way is to (directly) "talk" to your cosigner, through a (secure) side channel. Later on we might think of a protocol, but the implication is that the wallet needs to be created in two steps. 1) Create the shared wallet (get your credentials from that) 2) share your credentials with the cosigners (and collect theirs), finish the installation of the wallet. **D** - All sounds very sensible so far. **M** - This was also reviewed by the Vaccuum Labs team, who are also doing the HW Wallet impl. At this stage we know this work is 'ok': we've been able to do light multisig test locally... => Moved to Last Check (to be merged in two weeks) #### Update to CIP-0015 ([PR75](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015: "Catalyst Registration Transaction") **S** - Let's move this one to two weeks, still significant conversation and open comments there. => Send to 'Review' for next meeting #### Update to CIP-0013 ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013: "Cardano URI Scheme") **S** - I spoke with Nico about this and we're not going to make a proposal in the foreseable future that deviates. This one is approved as-is. Considering this as "Last Check' as this was discussed multiple times. => Merging NOW. ### Discussions #### "Cardano Addresses" [PR78](https://github.com/cardano-foundation/CIPs/pull/78) - "Cardano Addresses" **M** - New PR for a "Cardano Addresses" - it's not final yet but I want to put it on the radar as I have been getting many questions on the subject - it specifies things that already exist but I've been getting a lot of questions so this is a good place to collect information. In the Shelley specs the Byron parts are mostly opaque... Here this goes a bit more in detail if you have to handle Byron addresses - not pressing, but good to document. **D** - Sensible to include. Good Unicode art! => Moved to 'Review' for next meeting ### Close => Merge **NOW**: [PR61 - Update to CIP-0013: "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013 => Last Check: [PR57 - "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) (tentative ‘CIP-0016’) => Last Check: [PR69 - "Multi-signatures HD Wallets"](https://github.com/cardano-foundation/CIPs/pull/69) (tentative 'CIP-1854') => Review/Triage next meeting: [PR71 - Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015 => Review next meeting: [PR78 - "Cardano Addresses"](https://github.com/cardano-foundation/CIPs/pull/71) (tentative ‘CIP-xxxx’) => Review next meeting: [PR75 - Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015 --- ## 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-04-13.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [April 13 2021 notes](#april-13-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR57 - "Key Serialization Formats"](#Key-Serialization-Formats) + [PR69 - "Multi-signatures HD Wallets"](#Multi-signatures-HD-Wallets) * [Review](#review) + [PR71 / Update to CIP-0015: "Catalyst Registration Transaction"](#Update-to-CIP-0015) + [PR79 / Update to CIP-0015: "Catalyst Registration Transaction"](#Update-to-CIP-0015-1) + [PR78 - "Cardano Addresses"](#Cardano-Addresses) * [Discussions](#discussions) + [PR76 - "Key Serialization Formats"](#Update-to-CIP-0003) + [Static website and advertising the CIP platform](#Static-Website) * [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 4/13/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## April 13 2021 notes **Attending Editors**: Matthias, Sebastien, Duncan, Frederic ### Triage ### Last Check #### Key Serialization Formats ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-0016) **Duncan & Matthias** - All good / ready to go. => Merging NOW. #### Multi-signatures HD Wallets ([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854) **Matthias** - This should benefit from Sebastien's review. Which is a fari point and really argues about the design - I touched to it earlier today. **Sebastien** - What I put out in my comment isreally the privacy, but if folks are not worried then that's not a big issue. Meanwhile also the scaleability, for example if we start having multiple derivation. Because Any change to one of those would have an impact on the other which bundles/combines them generally. If you're ok with leaving everything under 1852 and conveying to the user the implications, then I'm ok with that. I think your proposed solution of generating more accounts to handle this does not work well inerlight (?) already supports multi-accounts for wallet, so if they derive account 1, 2 3 ... They might run into a multisig account, which would be undefined as to how to handle.. **D** - Can I get the concern summarized? **M** - The idea of this proposal is to extend the 4th role/level of the HD derivation scheme so have two new derivation paths, '3' and '4', which would identify multisig key or keys used in a multisig context. That level is normally internal address, external address or stake key. These are WITHIN an account. And so if you want to share your keys with your cosigner you have either to share your account's public key, which by soft derivation they can derive both your multiderivation key or stake key, OR you have to share two keys: The key at level 3 and the key at level 4 so they can both be sub-chain derived. If you have to share your account key, it means you also allow your cosigner to derive your payment keys. Only the public ones, yes, but you give away some privacy. In principle if you want to use Multisig, then you would use a dedicated account for that, only containing multisig keys. If you have the multisig keys in an account, they might get discovered and it could get messy... **D** - I think it's inevitable that different account are going to be for different purposes - and it's not going to be feasible to have the wallet generically treat all. This one for multisig, this one for contracts... **S** - Wether we want multisig to be handled by different accounts or do we want multisig to be handled by different "purpose" and so whenever you restore a wallet in Deadalus or Yoroi, you'd pick at the beginning of the restore if you'd be restauring a multisig wallet. **D** - The Downside is that every new kind of thing you want to use it for is a different set of accounts... **M** - This goes against the principle laid out in the CIP for 1852, where we give the general structure, and the 4th level is used as a hole (where we have 0,1,2)... **S** - For Catalyst, we have a voting key - and it would simpler if we had a voting key chain. If we said Role 3 is a voting key chain (**M** - Why not) the voting key could be deterministically derived by incrementing the index. so (0,1,2,3) would be (external, internal, staking, voting key) and multisig would effectively be (4, 5, 6 and 7)... and every time we'd want to add a standard, we'd have to look at this and the multisig path equivalent and it might get messy. **M** - I get your point: you want to reflect the existing strucure also on the multisig. It's always going to have the same set of roles... **S** - Yes, and so if we change the derivation path / purpose type, I feel it's not a big deal. The wallet keep track of your root private key so the key stays the same and you need the password to derive a new account just like you'd need the password for a new purpose so it feels like not much work and would keep things tidier.. **D** - So in my wallet, I want to have a bunch of accounts, some will be for some purpose while others will be for different purposes: voting multisig or other. The question I presume if how do we reflect this in the HD structure itself **S** - That's the reason why 'purpose exists' in BIP44 specs. We can use it that way if we want to, but we do not have to. I think it's slightly cleaner if we do that way. If we keep 1852 and generate new rules, I would at least argue to make them non-sequencial such as 100, 101, 102 as a namespace so that if things get added inthe future we have room. Changing the purpose I feel would be slightly cleaner. **D** - What about cointype, is this used? **M** - It's not used but it would likely do more harm than good to remove it. **D** - What about to use it? If we're trying to say there are different kinds of account, or roles, it seems fair that it should live above the account rather than below. **M** - You mean having a non-hardened path before the acount? **S** - It's mostly to prevent collisions or clashes with other cryptocurrencies. **D** - So even though cointype is the second level, in some sense it's the top level. **M** - Yes, has to do with how things where specified: In BIP44 the 'purpose' gives you the rest of the structure: It tells you there is an account type. Conceptually it's below in term of hierarchy. **D** - So cointype has to be registered with HW wallets and such but purpose can be changed, it makes sense to have accounts with different roles. Wherever we already have staking keys within an account, then it makes sense to have these - these are things within an account. But when it touches to roles within an account it makes sense to move that higher in the derivation tree. **S** - Purpose is my preferred choice as well **M** - It's also relatively easy to change. **D** - What was the tradeof you were initially thinking of? **M** - The main reason to try to have this as the same account is that it felt a bit unnatural for sharing: People already know how to share account public key - and if I wanted to share my account with someone else, like cosigners or such - having this as an extension within the account would make sense. The same account used for a different purpose would mean sharing account (with a different purpose) not the entire wallet itself. **D** - But in some sense, if we were to do it this way, it would still not be the entire wallet, rather all accounts within the wallet. **M** - We're very much account-centric in all the wallets that we have. Using 'A' particular account and then addresses within that account. **D** - I think that's ok logically for the user: "there is a set of accounts". Instead of having ONE heterogenous-style account, then you have several Homogeneous accounts characterized by the role/purpose first. **M** - For the purpose also, the natural thing then would be to change the purpose, but also piggyback on the structure of the 1852 wallet - but I really don't like this internal chain for which we have no use of for any wallet - inherited from the BIP44 design: To have different derivation paths for the internal addresses and external addresses is useless and only adds up to the complexity. That's also the rationale to have only two path: payment and stake keys, period. No Internal/external payments. **D** - You could also use the external one always - and ignore the other. **M** - That would be a bit weird but maybe more consistent, because we could say "look at this overall spec for the rest of the path" or "we have a new purpose and define the new path in CIP xxx"... **S** - I would specify the same thing and state that "internal is unused" **D** - This should probably be added to 1852: "as we add more kinds of accounts, we will add new purpose, but yet outllining we keep the cointype". **M** - I will update 1852 as part of this PR **S** - I'm fine with it. If we want to modify 1853 to mention it or leave as is, either works. **D** - I think we should capture it somewhere so the next person that comes along and wants to do it for new things... and make it consistent. **D** - => 1852 defines the pattern of extension. i.e. "when you want to extend this with a new kind of account (..)" Perhaps we might need some other type of accounts in the future, which should be done by keeping the same cointype but adding a new purpose. **D** - CIP-1854 would therefore be its own CIP as it is now. We've sortof made two decisions here - the right pattern of extension is (local), but the GENERAL pattern of extension should also be documented as part of CIP-1852. **M** - I will ammend this CIP. And also ammend CIP-1852 to clarify that for future use. It's really for different kinds of accounts. For things like the voting key, the "role" is still a better fit: you want it to be part of your normal account but also have it shareable as an extension of the role makes sense, so you can have it as part of the normal account or the multisig account. Having that as an extension of the role makes sense. Just change the purpose if you want to have a multisig-shared voting key OR have it fully owned by yourself. Maybe we can change the naming within the HD tree to clarify the (1st) one should be the account purpose, and the (4th) role as the key purpose WITHIN an account. **D** - So for 1854 you would go back to using just 0 an 2, and 1 would be unused. Ok. If Matthias is fine to do changes, it would be good as Last check again. => Moved to Last Check (to be merged in two weeks) ### Review #### Update to CIP-0015 ([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015: "Catalyst Registration Transaction") **S** - Test vectors have been updated and validated so this PR is ready to merge. In Fund4 the structure changed slightlyy. I spoke with the Catalyst folks about the changes and adjusted the difference in the test vectors by the dryruns - and Samuel helped review too. I am fairly confidient in those changes. **M** - In the first sentence, isn't this the "Hash" of the CBOR encoded metadata? I know that that was changed recently - it used to be the cbor, but then was changed to the hash for space. **S** - Probably right - we need to updte this PR to not touch CIP-0015 as all. **M** - Ok - [PR71](https://github.com/cardano-foundation/CIPs/pull/71) is adding test vectors, while the other (([PR79](https://github.com/cardano-foundation/CIPs/pull/79)) will modify CIP-0015 directly. => Moved to Last Check (to be merged in two weeks) #### Update to CIP-0015-1 ([PR79](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015: "Catalyst Registration Transaction") **M** - (Summarizing) This was reviewed by the Vaccuum Labs team, who are also doing the HW Wallet impl. At this stage we know this work is 'ok': we've been able to do light multisig test locally... **M** - This one touches to the changes themselves **S** - They closed the old PR and created this new one - I haven't had time to look at it yet. I think that Vacuum Lab comments is very fair and we need to have a look at that conversation. I think that defining the nonce as the slot number makes a lot of sense **D** - That's not a nounce, that's a counter. A nounce is Entropy. **S** - This should be changed to min slot number. Once that's done, everyone will be happy. **F** - Does it make sense to rename it? **M** - Quite many things to look at. **S** - I think we can move it to 'Last Check' because the last unknown is this field / nounce thing. Let's move to Last Check, will resolve this for next meeting. => Moved to Last Check (to be merged in two weeks) #### Cardano Addresses ([PR78](https://github.com/cardano-foundation/CIPs/pull/78) - Potential CIP-0019:"Cardano Addresses") (**M** - HOPING INTO 76 - see below in Discussion) **M** - This is documenting what exists and giving more details on the Byron parts, with some test vectors for ppl to use. Some of it deals with the address space and some of it looks at the behind the scenes. => Moved to Last Check (to be merged in two weeks) ### Discussions #### Update to CIP-0003 ([PR76](https://github.com/cardano-foundation/CIPs/pull/76) - Update to CIP-0003) **M** - This isn't an actual CIP but a clarification on an actual CIP that we reviewed with Sebastien - Why Trezor is using a different derivation format from the seed to the master key with the 24-word mnemonics.. Vaccuum Labs just heard back from Trezor and this was basically due to an earlier bug that eventually had to be kept for continued compatibility. **S** - OK with merging it, good to go. => Merge Now. #### Static Website **M** - Do we want to advertise the [static website](https://cips.cardano.org/) a bit more? What is blocking here? It's a bit easier to digest than the github site itself. **F** - The meetings, the platform are not getting the engagement it probably deserves - Do we WANT to advertise it? **M** - I think we do, I think developers.cardano.org should link to it. => Added to a the retro for discussion. ### Close => Merge **NOW**: [PR57: "Key Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/57) - CIP-0016 => Merge **NOW**: [PR76 - Update to CIP-0003](https://github.com/cardano-foundation/CIPs/pull/76) => Last Check: [PR71 - Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015 => Last Check: [PR78 - "Cardano Addresses"](https://github.com/cardano-foundation/CIPs/pull/78) (tentative ‘CIP-0019’) => Last Check: [PR75 - Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/75) - Update to CIP-0015 --- ## 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-04-27.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [April 27 2021 notes](#april-27-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR71 / Update to CIP-0015: "Catalyst Registration Transaction"](#Update-to-CIP-0015) + [PR79 / Update to CIP-0015: "Catalyst Registration Transaction"](#Update-to-CIP-0015-1) + [PR78 - "Cardano Addresses"](#Cardano-Addresses) + [PR69 - "Multi-signatures HD Wallets"](#Multi-signatures-HD-Wallets) * [Review](#review) + [PR85 - "NFT Metadata Standard"](#NFT) + [PR82 - "Cardano Delegation Portfolio"](#Cardano-Delegation-Portfolio) + [PR86 / Update to CIP-0013: "Cardano URI Scheme"](#Cardano-URI-Scheme) * [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 4/27/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## April 27 2021 notes **Attending Editors**: Matthias, Sebastien, Duncan, Frederic ### Triage N/A ### Last Check #### Update to CIP-0015 ([PR71](https://github.com/cardano-foundation/CIPs/pull/71) - Update to CIP-0015: "Catalyst Registration Transaction") **S** - I had forgotten to update the PR - Will do that right now, but otherwise good to go. (This PR now strictly adds the test vectors and nothing else). => Merge now #### Update to CIP-0015-1 ([PR79](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015: "Catalyst Registration Transaction") **F** - Prior Editors conversation went over the review from Vaccuum Labs team and suggested that authors change the 'Nonce' field to "slot number" as it functions as a counter... **D** - We put a comment to that effect and they came back with this being used elsewhere and generally preferring "Nounce". (Conversation around wether the naming should use "slot number" rather than "nonce". As evidenced from other uses and checking definitions, "Nonce" is fine) **D** - This is really a naming issue, withdrawing request as they pointed to prior use with naming. **M** - OK. => Merge now #### Cardano Addresses ([PR78](https://github.com/cardano-foundation/CIPs/pull/78) - Potential CIP-0019: "Cardano Addresses") **M** - The past conversation was that this was good to go - there is some conflict in the readme likely from a separate merge. Resolving. => Merge now #### Multi-signatures HD Wallets ([PR69](https://github.com/cardano-foundation/CIPs/pull/69) - potential CIP-1854: "Multi-signatures HD Wallets") **F** - This is the one we had a lengthy conversation last time (1854). **M** - The changes from last time were to change the purpose instead of adding a new role - we will use a new purpose (1854) to distinguish multisg wallet from standard wallets and will keep the same coin type. And we will keep a structure similar to the structure defined in 1852 and as a summary I recapped all that in a small table, but leaving the 'role=1' out, which is reserved for the internal adddresses in the standard wallets but will remain unused in the multisignature wallets so we will only use '0' for the payment keys and '2' for the stake keys after that the structure is the same. One account which is hardened and an index not hardened. This prevent mixing up a standard wallet and a shared wallet and also makes it possible to share the cosigners the account key without exposing your other normal payment keys to your cosigners - and makes it easier to extend both proposals, such as adding new roles for 1852 and piggyback on the same structure for 1854. For example the voting key could be added as a new role here (ex role=3) that could be added. Re: user-facing encoding we have defined new prefixes for the bech32 encoding so there isn't a shared prefix for all the keys coming from this particular proposal. I made the update to [CIP-0005](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/README.md) directly, and it setups parallel for every key - [CIP-1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md) and [CIP-1854](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/README.md) have their own formats. I added a bit to CIP-1852 to explain the rationale - if intent simply to extend the existing roles with a completely different semantic then it's fine to add a new role. The part about discovering the template does not change. **D** - Nice. I think that's good. **S** - LGTM too - I approved it. => Merge now ### Review #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **D** - A lot of conversation about the NFT CIP PR... **M** - This is one of those for which I wanted to do a summary - there has been a lof of conversation on that and people also seem to disagree on the goal of that CIP... **F** - Oftentimes people seem to not grasp "NFT" **D** - Why does one need a standard here? you can already create them. What's the standard for? **M** - This standard is mostly about associating metadata (or more exactly content) with the token encountered onchain (NFT) - this proposal is mostly about linking the association of data with the minting. But this proposal is mostly about "images". So there is some will to also associate NFTs with anything you can link (video / anything that has URL/MIME type) - but here some seem to be arguing as this being solely about images rather than a wide-reaching NFT standard. I think it makes sense overall but we would need to include content hashing - but they should also rename the proposal accordingly to not have some overly generic format. **D** - That makes sense - So really it's "metadata to be associated with an NFT" to say what it is, rather. **F** - This goes back to NFTs "as experienced" on Ethereum, such as smart-contracts complying with a standard (ERC721). We don't have those standards yeton Cardano, this might be a first step for images here. We have one registry run by the CF, but not pushed as a standard - which has a set of metadata attributes that it can associate. I feel it's rushing a little bit until we have a distributed setup (smart-contracts). **M** - I think the rationale was here trying to document how "Spacebudz" as an application setup their NFTs - So they wanted to write down the approach those guys took onchain so other applications can reuse it similarly (for images NFTs). "General" NFT conversation might be better to put somewhere else, such as a future CIP that would be MORE generic.. **F** - So this sounds like the CIP is perfectly fine, if reframed a bit? **M** - Yes - modulo a few corrections. I wouldn't put anything about the MIME type in there for example. Really should be images only so future CIPs can be more generic for NFTs. This has values in itself, such as "My app supports CIP-122 (madeup) for images" while another conflicting image standard might defines a different approach that some other app took. We don't have to choose which is the better one, just that it makes sense. **S** - I think that's a good summary - I haven't had time to go through it, but maybe it's settled down for now? **M** - I don't mind making a summary of the conversation so far and opening it for next meeting. **F** - Will add to the thread so people are notified. **M** - I'll add something at the end of the github conversation, summarizing what I just proposed - add content hashing, and making the focus on image. => Add comment in thread (**M**) + Moved to Review for next meeting. #### Cardano Delegation Portfolio ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") **M** - [PR86](https://github.com/cardano-foundation/CIPs/pull/86) came out as an offshoot of [PR82](https://github.com/cardano-foundation/CIPs/pull/82) - so they are linked. There was an extensive comment from Robert on 82, suggesting to use URLs to transport the portfolios information rather than using an external json file - more cumbersome to generate and pass along - while a link is easier to modify as just text... I don't think these two cancel eachothers, but are complementary. It would be good to get someone like that on both URI and JSON schemes. **M** - Robert makes a good point on the framing of the CIP, the motivation for it: there is a monetary incentive to split your delegation into multiple stakepool, especially for users that have a lot of money or stake. I do agree with the comment on motivation - As soon as a user reaches a certain ammount of stake (enough to over-saturate a pool) there is a motivation for you to split your ada into multiple pools. Then there is the question of allowing decimals (which I am strongly against in that proposal): This proposal uses plain integers as weights, exactly to cope with problems that come with floating arithmetic especially with json and javascript kindof world where this is often causing issues. The illusion of precision that you get with decimals in the end is unecessary for this particular proposal because there is no way you can achieve that level of precision anyways with a wallet - the "best effort target" for the wallet. That's really what it is. A wallet is defined in several UTXOs and you can only associate A particular UTXO to A particular stakepool which means that in a way you have the granularity that your UTXOs give you. If you have 2 UTXOs in your wallet there is no way you can delegate to 3 stakepools at the same time (you'd need to break down your utxos and whatnot). Having the illusion of "precision" with decimal numbers doesn't make sense for that because you will not be able to achieve it anyway with a wallet. That's why we went for a "weight", a sort of indicator that your wallet is supposed to "try" to achieve delegation according to the weight, and is fine - maybe it could be called "best effort" or be highlighted more in the description, although I thought I did. => (Tentative) Moved to Review for next meeting. #### Cardano URI Scheme ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **M** - This is using decimals as proportions which we probably do not want as explaind earlier, and I will comment in this PR itself. And it would be good to get alignment between the portfolio as json and the portfolio as URL. With which we would actually redefine this [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) and provide a more general structure and have something a bit more like what was done for the metadata label registry ([CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/README.md)). (For the metadata it was essentially imposed by the blockchain format really) and say this is how it works and this is a registry for the various actions that can be recognized. **S** - My main Q for the portfolio stuff is still if we can get it implemented in the actual Cardano nodes themselves: The single stake key, with the multi-pool delegation... We were previously told "possibly in the future"... With the Alonzo integration into the node wrapping up maybe more bandwidth would enable that? **M** - The last info I have on that is basically that "no" we aren't going to bring this into the node (at least immediately) because of all the complications it brings. I am not aware of any long range target. It could be that we have this notion of portfolios for now, but it might be deprecated in the future if there is the capability. **S** - It feels we're moving the complexity from one place to another. But the PR is fine as is, I have no issue approving it and merging it. => (Tentative) Moved to Review for next meeting. ### Discussions ### Close => Merge **NOW**: [PR71 / Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/71)- Update to CIP-0015 => Merge **NOW**: [PR79 / Update to CIP-0015: "Catalyst Registration Transaction"](https://github.com/cardano-foundation/CIPs/pull/79) - Update to CIP-0015 => Merge **NOW**: [PR78 - "Cardano Addresses"](https://github.com/cardano-foundation/CIPs/pull/78) (‘CIP-0019’) => Merge **NOW**: [PR69 - "Multi-signatures HD Wallets"](https://github.com/cardano-foundation/CIPs/pull/69) (‘CIP-1854’) => Review next meeting: [PR85 - "NFT Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/85) (tentative ‘CIP-0020’) => Review next meeting: [PR82 - "Cardano Delegation Portfolio"](https://github.com/cardano-foundation/CIPs/pull/82) (tentative ‘CIP-0017’) => Review next meeting: [PR86 / Update to CIP-0013: "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/86) - Update to CIP-0013 --- ## 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 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | Draft | | 19 | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019) | 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 | | 1854 | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-05-11.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [May 11 2021 notes](#may-11-2021-notes) * [Triage](#triage) + [PR66 / "Fair Min Fees"](#Followups) + [PR21 / "Non-Centralizing Rankings"](#Followups) * [Last Check](#last-check) * [Review](#review) + [PR85 - "NFT Metadata Standard"](#NFT) + [PR82 - "Cardano Delegation Portfolio"](#Cardano-Delegation-Portfolio) + [PR86 / Update to CIP-0013: "Cardano URI Scheme"](#Cardano-URI-Scheme) * [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 5/11/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## May 11 2021 notes **Attending Editors**: Matthias, Sebastien, ~Duncan~, Frederic. Research Guest: Roman Oliynykov (IOHK). ### Triage #### Followups ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - "Fair Min Fees") ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings") **Frederic** - Roman (from IOHK Research) was looking at these as well as Colin - however the timezone might be an issue to get updates. There were inquiries from the community to see if we could get a better insight from IO research, do we have any updates regarding either of those. **Roman** - It's a side of my research right now and being brought up to the next Chief Scientist meeting next wednesday. There is deep theoretical research on game theory and equilibrium towards a given number of stakepools - I also agree with this approach. I also agree that tasks raised in these CIPs are essential and need to be researched more. It's a side of my research and will be discussed more with (IOHK Chief Scientist) Aggelos. I looked at both of those and will provide details regarding those to him for discussion. #### Minor PRs **Matthias** - Three major PRs are currently ready to be merged and we can push those through quickly: 1 - A bot dependancy fix. nothing to see, let's merge unless someone is against it. 2 - A Minor one about some linkfixes. 3 - A PR from Mikhail to separate data into its own file so it can be parsed seaprately and whatnot. I think this is something we could encourage when writing CIPs, When people have separate files, they should try to aim to put them outside of the CIP itself and keep the CIP itself in prose while the data can be as its own file. **Sebastien** - I approved all those. => merge NOW. ### Last Check ### Review #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **F** - It felt we had a good overview the prior meeting, but we might do a recap for recording viewers or such... **S** - I've read through this PR. I think there's been a lot of good points (that I agree with) but it looks like some of those conversations are still ongoing. **M** - Apotential thing we should be careful with, is using the blockchain as a datastore. For instance, this here is suggesting we put the entire metadata on the blockchain itself, then for each token there's a set of fields / metadata which needs to be encoded and use space: it (the blockchain) is not an ideal tool for that. The blockchain is good to ensure that content has not been tampered with... it's a Ledger, not a Database. Rather we should probably encourage a hash (of the metadata) onchain with a URL pointing to the (hosted) metadata offchain in a separate server. Like we did for stakepools and various other things. Not completely settled on having everything in there, even though it would be conveniently small and accessible (onchain), without needing a server to host the whole things. Plus it has also already been done a few times. I'm not sure how we can prevent people from doing it directly still. **S** - I have to agree. The problem I have with this standard is in this standard, we have a name, a description, but I can imagine multiple standards that (also) have multiple names and descriptions conflicting (for example if a token is trying to follow multiple standards) **M** - And it is also more readily expandable in a way **S** - I feel requiring people to put an IPFS link and a hash would not be a big issue as users are already uploading images and linking them through IPFS (so this would be something they would be familiar with) **M** - It seems they have considered the offchain approach in the [forum post](https://forum.cardano.org/t/cip-nft-metadata-standard/45687) but not in this CIP(PR) itself. The offchain approach would still miss a hash because you wouldn't be able to trust any content you get... **F** - Isn't IPFS linked to Ethereum? **S** - No. It's 'used' by Ethereum but not linked in any way. It is somewhat linked to a project called filecoin (a blockchain) the group behind IPFS. Consensys does work with Filecoin on some projects and so they have some unoficial partnerships and things like that. **M** - I think we can suggest what we said last time still. This CIP seem to be more clearly focused on images and so while most NFTs seem to be images at the moment, this CIP is accordingly skewed towards images right now. It could be that this '721' label is reserved for image NFTs and so putting a link to an image on the IPFS network could be sufficient (provided there is a hash). Different story if it's a IPFS client ID or similar. I don't think we need any of the outside fields... Which actually posits multiple issues because it's not only about the image: they also want to have a name and other fields, which means the IPFS links should probably NOT be an image but the actual metadata. Hm. **S** - That's what we want: We want the description to also be offchain, they could be pretty long for some. **M** - For me that's why we'd probably want these files (fields) removed from this PR here and limit ourselves to images only. We don't need files or mime type, you can simply assume an image enforces png for example as format.. **S** - I think this is still open for discussion so far. People have not been convinced either way. **M** - Which leaves the name and description. **S** - I feel this (name and description) is something we should have had from the start when we launched multiassets. **M** - You mean upon minting Tokens? **S** - Yes, it would not have been perfect, but having this as separate field would have made it easier for adding support in wallet or expanding. And standards such as 721 would not have to fight or multiply-define "name" or "description" multiple times. If we want to double down on the Token registry to act as the place for names and descriptions (rather than have it onchain) then we should remove these from 721. Else if we want to have metadata onchain then we should extract it from here (721) and put it in a separate namespace so it can be used by other standards as well. So I feel we have to pick one or the other. **M** - You're right, but I am still not convinced by the onchain approach on that, especially with all the NFTs that are being minted everyday nowadays. The Blockchain is currently 8GB for Cardano, 5 of which were just generated since the Allegra era, so yea, the transactional volume has increased but also the size of the transactions that were submitted. We could probably measure the impact of all the metadata being submitted onchain at the moment and I also agree that we already have an offchain solution for that: we should probably push that a bit more. The name and description are already covered by the Cardano Registry. Adding a new wellknown property as an img that is a link to an IPFS link should be trivial... **F** - Any way to multipurpose the Logo field for that? **M** - I would still keep them separated. The Logo was intended for actual currencies, having a different field might make more sense. **F** - Regarding the Cardano Token Registry (an instance of a Metadata Registry) from the Foundation side that was intently meant to handle coin-like token - I think the more functionalities get grafted on it the more you will see some pushback on the new functionalities beign added. Unless if you're talking about the more general server code that IO is making available. **M** - The server in itself is a centralized solution, but the metadata format itself is not, and so it can be transported to a different server if desired. There is nothing the server provide that cannot be transfered to another instance. There is only one hosted by the CF right now, but in that sense it's only semi-centralized: You don't really have to trust the server itself as the data itself is authenticated and self-contained. Having said that, it's true that the format is very much tailored towards 'currencies'. If you were to do that for 100 NFTs you'd need 100 different files, all with different subjects, which is not practical. **F** - The CF registry as a solution might not be ready for that kind of setup.. **M** - Having things in one single file would not really change much - you wouldn't have to repeat some of the field but you'd still need all the other ones. And still minting 10K entities might be a bit too much but also a reason to not put that onchain (which would be large for no reason). **F** - Maybe the NFT conversation regarding images might be more focused on the format: something we could either add onchain or offchain on a registry. I'm hearing your point as the offchain solution being really 'semi-centralized', the same way as the CIP platform more or less. **M** - My recommendation here is: "Have the lightweight metadata onchain if indeed it is limited to a name and a description. For any more elaborate metadata, we need an offchain solution." But that is still not satisfactory I think.. **F** - For this PR - let's add a comment in the PR with the caveat that this is a 'recommendation' - also noting that this PR is still going to be reviewed again next meeting, with the understand that we aren't trying to find a perfect solution - it sounds as the lead recomendation has been to refocus on image NFT for this PR leaving the greater NFT conversations out for continued discussions. **M** - Definately one of the points we want to communicate - also really want to emphasize the Blockchain is not meant as a database - and should not be used to store content, which should probably favorize offchain solutions. This is a good conversation to extend with the Author of course. I don't think there is a clear case for the storing of items on the chain, besides the readily availability of metadata as you synchronize the blockchains, and you wouldn't have to fetch that from a different ressource or server - but you already have to fetch the image from a different server, and since that cost is there, then we might as well build on such kind of solution. I can understand that the current Cardano Token Registry (an instance of a Metadata server) is maybe too centralized for that, but then we need a better (more decentralized) solution that doesn't require storing things on chain. => Adding a note in the PR + leaving in Review for next meeting. #### Cardano Delegation Portfolio ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") **M** - There was a last remark from Robert as we were discussing the 'Decimals' on other proposals - which is sortof related - to extend the URI scheme for delegation portfolio as well. I added a response here in the PR (which was also discussed in our last meeting), saying that we want to avoid using floating arithmatic as much as possible and that's why we use plain integers as weights and ratios, so they can be represented as fractions and more importantly those ratios do not need to be precise because there is no way in the end to achieve that precision in the end for the wallets (it will always be an approximation), and so they are rather a "direction" for the wallet to know how to balance its utxo accross pools rather than a perfect target. (going over the PR comments) **M** - Several points in the latest comments - the first one is about the protocol change for having multi stakepools and ratios between stakepool delegations as it was done basically for jormungandr at the time (for the ITN). This is a completely different topic and I don't see this happening any time soon in the actual Haskell implementation (for various reasons). I agree with Robert and Sebastien here that it would be cleaner and a lot easier for many of the consumers downstream but it isn't really doable at this stage from the latest feedback we got from the core team: that's why we went for a pure wallet solution regarding the multidelegation. That also doesn't prevent us from deprecating a CIP later on if this gets implemented. In the eventuality where it will be implemented we might already want to have a CIP that is compatible with that (although we have no idea if the core team would use pure floating points or use ratio like the Jormungandr team did at the time)... **M** - The second point is that we cannot say that we want to use Integers (and not decimals) because we don't need the precision brought by the decimals. One might want to actually have a very precise representation of your portfolio despite the wallet not being able to enforce it, because there might be other consumers of that representation (third-party services). Taking the point of view of the wallet is a bit bias. **M** - The final argument states that it would be easier to use decimals in here here because the interface will most likely display decimals to users - and most users prefer to deal with percentage or things like that rather than plainweights - Still, should the UX also impact the underlying format we want to enforce? I don't see a strong justification for one or the other in the end, it seems more like a preference matter. I'd argue for integers but I can also understand Robert's arguments. These are different approaches. I would prefer to have consistence betweek the Link approach and the JSON approach. But I don't see any strong arguments for the Decimals or the Integers really. I might be bias coming from a wallet perspective - there having integers (as plain weights) would be easier to manipulate rather than with decimals. And since it's not going to be a precise measure anyways, we don't care for floating arithmetic precision in here: it will never be exactly matching the portfolio weights anyway so being off by a few decimals doesn't really change anything to your wallet distribution. Plain decimals might be more transparent for people, especially if we require decimals to have a fixed number of places, and the scope may be between 'this' and 'this', to represent actual precentage. The annoying thing (with decimals) is that we likely want them to sum up to 1. It would make no sense to have a portfolio delegating '150%'. Integers as weights would solve this from context. **S** - I still need to reflect on the comments, but have commented loosely a few times. I will get back to this. => leaving in review for next meeting + Flag to Robert. #### Cardano URI Scheme ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **M** - A similar conversation, this time from the Link perspective - the idea here is to define the portfolios as a set of stakepools but also with proportions (the equivalent of the weights in the earlier proposal). With the proportion as a decimal number, any number of digits and any number of decimals as well. Not sure how much more can be said beyond what was earlier discussed for [PR82](https://github.com/cardano-foundation/CIPs/pull/82).. (reading in the PR) This is the same meaning as the integer weights, it simply defines fractions of decimals, the proportion itself is still to be interpreted in the context as integer proportion - what I said previously (about having to sum up to 1) doesn't really apply here. Putting aside the integer/decimal question, there should be ONLY ONE WAY to specify proportions. Here it suggests a lot of different default cases ("if there is no proportion", "if there is only one"...) If no proportion is given, it should be an invalid proposal IMO (in the same way that weights should always be required in the other proposal). If a stakepool is mentionned multiple time it should also be invalid. (adding a commment in the PR) ### Discussions N/A ### Close => Review next meeting: [PR85 - "NFT Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/85) (tentative ‘CIP-0020’) => Review next meeting: [PR82 - "Cardano Delegation Portfolio"](https://github.com/cardano-foundation/CIPs/pull/82) (tentative ‘CIP-0017’) => Review next meeting: [PR86 / Update to CIP-0013: "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/86) - Update to CIP-0013 --- ## 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 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | Draft | | 19 | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019) | 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 | | 1854 | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-05-25.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [May 25 2021 notes](#may-25-2021-notes) * [Triage](#triage) + [PR66 / "Fair Min Fees"](#Followups) + [PR21 / "Non-Centralizing Rankings"](#Followups) * [Last Check](#last-check) * [Review](#review) + [PR85 - "NFT Metadata Standard"](#NFT) + [PR82 - "Cardano Delegation Portfolio"](#Cardano-Delegation-Portfolio) + [PR86 / Update to CIP-0013: "Cardano URI Scheme"](#Cardano-URI-Scheme) * [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 5/25/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## May 25 2021 notes **Attending Editors**: Matthias, Sebastien, Duncan, Frederic. Editorial Guest: Robert Phair. ### Triage #### Followups ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - "Fair Min Fees") ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings") **Frederic** - There have been some updates yet both PR are still with IOG Research. An update from Colin: he believes the mechanisms described in both CIPs to be "fit for purpose" and that these are now with the research team at IOG for review. Roman himself reviewed and reached out to Chief Scientist Aggelos, and is awaiting replies due to everyone pretty busy with Alonzo and other releases right now. **Duncan** - I know the research group has been pretty busy with getting the A0-related things ready. I want to add that it isn't necessary to wait: we have always said that it is OK to publish technically self-coherent sufficient proposals: they don't have to be agreed or approved by IOHK research or other - really the choice should be with the original Author of that CIP, if they choose to wait for review or push for publishing. Reseach or review does not have to be a blocker for publication. **Sebastien** - I feel bad that we're leaving this open but I am not sure that there is a better option really. **F** - I would be more inclined to try to merge this (due to community feedback). **D** - Just as long as we make it clear that the publishing has no implication/expectation for the implementation. => Loop back with authors re: publishing and update. ### Last Check ### Review #### Cardano Delegation Portfolio ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") Joint conversation with 86 - see below. #### Cardano URI Scheme ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **Robert** - (re: [PR86](https://github.com/cardano-foundation/CIPs/pull/86)) The gist of the conversation is already present in the separate threads really: We're not looking at competing proposals: we want to find out how portfolio links are made, so they can define delegation to more than one pool (here as a json file), we want to make sure Standards are as simple and consistent as possible. I personally think people will want to use decimals to define delegation proportions. Then there's the question of precision also. It's a matter of user expectation/preference. In the long term it might be more difficult to have a more confining standard (that users would want to use with more variety). (This should be documented in the conversation github threads themselves rather than in meeting notes, or at least in BOTH places). I've observed with how people try to use these features in the internet landscape and they try to use it very flexibly - so unless there is a very specific reason to restrict these things from the beginning (ex: something would fail if not), I suggest making the standard as open and flexible as possible. I kinda split my comments into what would be more needed in a linking scenario ([PR86](https://github.com/cardano-foundation/CIPs/pull/86)) while the feedback on decimals is more in Mathias' [PR82](https://github.com/cardano-foundation/CIPs/pull/82). Some of the way that this was framed was due to uncertainty about precise staking ratios if at all achievable. As Matthias noted, that is a separate issue, but as it hasn't been decided one way or another it would be good to keep the standard more flexible to allow for have it not be confining later. **D** - To your last point, do you mean "specify the ratio any way we like" and the implementer is to handle it as they choose/approximately? **R** - That is what I was trying to get in my comment. Another thing I picked up is the need to have more engagement from the community. Both Matthias and I have our sides of how we feel pretty comprehensively detailed in the threads themselves - so we really need to have more engagement from the community directly - maybe IOG could raise the issue with SPOs since they would be the ones managing delegation portfolios? (Maybe it might be serving a private interest of sort re: "not discussing it" yet..) I think that dev channels or SPO digest should ask "If you could link to your stakepool, how would you like to do it?" (could link to the forum posts or github threads?) this would gather community feedback including the impact on members, how they think delegators would be affected due to the imprecise nature of delegation due to the UTXO model... all to get some more consensus on those items. **D** - If what you are suggesting is "more feedback from SPOs", let's get in touch with Ben O'Hanlon and get him to help us with getting it as a topic in the next SPO group meeting: This will be useful to collect the feedback/opiniong from SPOs. **R** - I think Ben became SPO community manager around October of last year, that's when I put out the original standalone CIP I had before it was merged with Sebastien's - I was unable to attend those "townhalls", I find them a bit overmanaged, where SPO can interjects to their own comments - they feel a bit one-directional. **D** - That is certainly true for the events, community discussion is more for forums or telegram groups. I will speak with Ben next week. **R** - That kind of visibility (where I could keep it semi-technical) for the audience would help with engagement. **D** - The current schedule I see a SPO comm scheduled for next week - so will try to push for it. **M** - My 2c on that conversation - the whole portfolio-decimal-thing - I think it escalated a bit more than the proposal itself: The proposal initially was covering existing capabilities of the Cardano Blockchain, not making any assumption of what might end up in the ledger or in the protocol in the future, but really how wallets TODAY can represent multi-delegation portfolios, assuming that this multi-delegation is entirely done on the wallet side (no protocol change required to do that) it's really just a way to represent having multiple stakepools, which is achieved by having multiple stake keys in the walley and delegating to multiple pools. So the entire discussion about "what should happen if it ever gets supported by the node" is like a completely different conversation... and at that hypothetical time I think it would be ok to obsolete this CIP and move to a separate solution using native multistaking (if there is even such a thing). **D** - I missed the conversation about fractions - Was that the "weights as integers or decimal numbers"? (and really they are equivalent as you could use integer ratios) **M** - My pt is that Integer is simpler, while decimals provide a false sense of precision. Really the precision is absent from this entire proposal setup UNLESS we have that native support at the protocol level - But currently from the way wallets will implement that it will be imprecise (so having just integers is simpler..) **R** - For cases where users might still prefer to conceptualize using decimals anyways, I documented my comments in the [Github thread](https://github.com/cardano-foundation/CIPs/pull/86#issuecomment-838550989) - looking at the marketing rather than the technical rationale, including how an architect or implementer might choose to consider it. **D** - I think the nice thing about Weights is that they don't have to add up to 1. **R** - Right and if I were to want to have my pool to get a 50% boost I could just set it to 1.5 if all weights were at 1. But you need a decimal for that. I'm happy to continue conversation where required. **D** - I'll go over this with Ben next week and will plug you into the SPO meet for feedback. => Duncan to follow on this with Ben, Robert to possibly open the conversation with SPOs. #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **M** - The "NFT metadata standard" we've already discussed a few times - There have been some more discussions since last time we discussed. To summarize, this is a standard to summarize some metadata for NFT, at the moment of "minting" the NFT. The initial proposal was suggesting to put all the necessary metadata INSIDE the trasaction metadata (minting the various tokens) according to some given format. The conversation happened around "what" metadata should be included and what the format might be. The initial proposal was more tailored towards image NFT but tentatively opening up to more general kinds of medias. Eventually it was also suggested that storing metadata on chain was a poor move - the Blockchain being better at storing hashes (and storing the content elsewhere). Some conversation followed around using the IPFS network for storing the actual content and using the transaction metadata to link to the content itself. The idea was to store the JSON structure of the NFT metadata on the IPFS network (name, description, mediatype.. ) while on the Cardano blockchain would be a "link" to that location. Since then, some responses have occured (going over onscreen). A lot of good things noted, converging towards "offloading the actual metadata content to other (different) networks". Right now this CIP hints at IPFS - but really this CIP might not require IPFS specifcially and be open to use other storage network. The good thing is IPFS is addressable and verifiyable at the same time. The structure itself could be "free" or specified in a different CIP than this one. This one then would be about "how to get metadata" but then we would have other (possibly competing) CIPs focused on specific types of netadata, ex: NFT audio file or NFT image, or NFT Legal contract... Allowing for various different formats and it would be up to the applications consuming these formats according to the format they align with/by. This would be very much how "mediatype" works on the web - where you fetch a particular ressource, obtain the mediatype, which then lets you interpret the bytestream from whatever server you're fetching that resource (ex: a PNG image). Here you'd get "some" metadata from the link, anf the link itself tells you what type of metadata that is, and if your client can interpret/consume that type they are free to manage it as desired (or report an error if unable to or other). **F** - The last comment seemed about spliting it in two (CIPs) - this one about "obtaining" the metadata and the other about identiying the varied types/structures. Without updates from the CIP Author since, this might be tabled despite the conversation.. **R** - If the scope of this "NFT standard" was as broad as some of the participants would want it to be, schema.org tags could be used. Not sure where the best place for that vocabulary would be though - just that the vocabulary might be used/useable at some future time if the CIP remains general. **Roberto** - Completely agree with Robert, I have been pushing the conversations towards schema.org way of representing assets/events - not just about NFT metadatas but so that any metadata stored onchain becomes a bit more explicitly defined - so that it becomes "web-semantic friendly". These metadata standards would be good if we pushed metadata to be stored externally and explicitely call metadata URL/URI so it's clear we don't expect a json object on that key. (+ agreeing re:metadata Schema URLs comment) **M** - Really scoping this CIP has been a URI to a particular metadata file and probably rely on Schema.org and provided schemas here to describe varied media contents types. This should already be quite complete to cover a lot of usecases. But also quite large in a way: some projects might want to restrict the space, but should be fine.. (ALSO a good example of why "storing this onchain" is a a weak idea - there can be a LOT of metadata later on). **Clark** - the problem with most metadat ais that offsite requires a caching layer and multiple http requests to display **M** - But what's the cost a of a http request compared to making the chain 10 times bigger? We won't really get rid of the cost of fetching data. **F** - How to proceed re this CIP then? It has been in the background for some time. Alexandro commented in there that he'd be willing to split it or rework it.. **M** - Currently writing a few suggestions to move this forward and check in with Author to see if he agrees on the varied pts.. Let's wait for updates before setting it back to "review" for the follow meeting. => Adding a note in the PR - moving things out ### Discussions N/A ### Close => Updating PRs with conversation, will reach for SPO feedback on the matter (Robert) re:[PR82](https://github.com/cardano-foundation/CIPs/pull/82)/[PR86](https://github.com/cardano-foundation/CIPs/pull/86) => (Matthias) Adding conversation and outreach in [PR85](https://github.com/cardano-foundation/CIPs/pull/85) --- ## 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 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | Draft | | 19 | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019) | 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 | | 1854 | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-06-08.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [June 8 2021 notes](#june-8-2021-notes) * [Triage](#triage) + [PR66 / "Fair Min Fees"](#Followups) + [PR21 / "Non-Centralizing Rankings"](#Followups) + [PR85 / "NFT Metadata Standard"](#NFT) + [PR82 / "Cardano Delegation Portfolio"](#Delegation) + [PR86 / Update to CIP-0013](#Delegation) + [PR89 / Update to CIP-0015](#CIP0015) + [PR97 / Update to Autogen script](#Update-Script) + [PR88 / "Cardano dApp-Wallet Web Bridge"](#dApp-Connector) * [Last Check](#last-check) * [Review](#review) + [PR96 / "Forging policy keys for HD Wallets"](#Forging-keys) * [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 6/8/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## June 8 2021 notes **Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic. Editorial Guest: Robert Phair. Kevin Hammon (IO Research). ### Triage #### Followups ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - "Fair Min Fees") ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings") **Frederic** - Both of those are effectively tabled until we hear back from CSO Aggelos or if the author is fine with moving forward we can merge appropriately. **Kevin** - Re: PR66 / "Fair Min Fees" - IOG is considering this and there is a blog post Aggelos has put together relating to the fee structure that should be pushed around now. **K** - All fee-related parameters, how they work, are set and the levels. Also min/max settings. Expect an encompassing blog post. **D** - So it may or may not address this ([PR66](https://github.com/cardano-foundation/CIPs/pull/66))... **F** - Any update on [PR21](https://github.com/cardano-foundation/CIPs/pull/21)? **D** - I think the same point applies, which is that the researcher have just about completed and are about to provide internal feedback on the pledge benefit curve ([CIP-0007](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/README.md)) proposal. It doesn't directly address this PR but it addresses in some sense what comes before that: incentives leading to ranking. So one might want to rethink/adjust "ranking" post incentive tweaking.... I think the situation is basically as it was before and Shawn should be in his right to push for the publishing of these proposals: The researchers at IOHK will get to those proposals in time. Not everything has to be what everyone agrees with and what gets implemented might be a gradient of those. **K** - Expecting good news on that is the near future.. **D** - Shawn might want to revisit the proposal pending changes. **K** - The blog is in the final stages, might be out already. **F** - Any other update from IO Research? **D** - The big one is the one just mentionned, the pledge curve, touching to A0. **K** - What we are expecting to see there is a revised pledge-related reward formula: The researchers have been measuring the effects under Myopic and non-Myopic situations. The model proposed by Shawn in his CIP unfortunately had some issues: it works under some situation but not under ALL situations that we would like. The change rationale/rework will likely have the effects Shawn was intending but would not be the same exact same formula. **D** - Yes. It does have implications on rankings, as part of looking at the pledge curve they also looked at wether it's okay to look at Myopic vs non-myopic views adn part ofthe question was wether it's more interesting to look at the long term vs. short term. Again, it's very clear that he has a reasonable proposal and it would be fine to publish as is. => Moved to (Last Check) post-email follow-up #### Delegation ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **F** - Any update on the current outreach to the community? **Robert** - I have been in touch with (IOHK) Lenna Onto regarding joining the upcoming "SPO community call" this Thursday (June 10th) where I will introduce the stakepool links and confirmed there would be a more general CIP/SPO meeting in two weeks (June 24th). We only have space to introduce the PRs, some links to the discussions and talk about what is coming up in the future + how that would enable the delegation options (json, ++ ). The point of this intro is to start getting feedback from SPOs, maybe get some timeline, expectations of precision and what else might have come out and/or suggestions, pushing users towards posting in the forum or github threads, and remind that the merging/inclusion in the CIP repo does not imply implementation (Governance process being separate and also needing their voice). Trying to get that in 5 minutes and opening up to a question is the aim for that meeting, with the follow-on meeting as a way to onboard SPOs further in the CIP conversation. **F** - So the follow-on SPO community meeting on the 24th is specifically the "delegation" meeting? Or should it be a more broader look at the CIP framework? **R** - Up to Ben's team. I've made myself available to jump in to educate as much as feasible. I think the focus is going to be JUST about CIPs. #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **F** - [PR85](https://github.com/cardano-foundation/CIPs/pull/85) (NFT metadata standard) was discussed at the last meeting - there was a new comment in there from Matthias... **Sebastien** - I read through last comments and I think it makes sense, but the conversation seem to have died afterwards. We have to figure out how we define when the PR/CIP is good enough to be merged. **F** - The past back-and-forth here (on this PR) appeared to be consolidating towards a Schema.org-style of disintermediating, using some kind of subspace of ... NFT space thing? **S** - Alessandro (PR author) has the last comment rather open - as Editors we might have to step in to figure out the path to proceed - ex: there is no discussion, do we close, merge, etc... we should do something. **F** - Without Matthias present (as the closest to this PR) we are lacking maybe closer educated opinion. **D** - Clearly a topic with a lot of interest and we should probably be guided by "has the state of discussion died down enough to.." **S** - Alessandro not providing clear steps, folks already having implemented this standard, Alessandro currently working on building his own wallet: there seem to be grounds for merging - some standard is emerging. **D** - "Existing Implementation" is a good step toward considering something as becoming standard: competing standards are perfectly OK. **S** - IOHK has a wallet, Emurgo has a wallet and everybody who has a wallet is interested in joint NFTs in some way shape or form: it would be nice if we could coordinate and wrap this up so it doesn't cause issues later. **D** - Have you checked if this is "more" about images? (or if it should be exclusive to images or other..) **S** - That is what Matthias' last comment is about (trying to use a schema) but there's no clear path forward after this. At this point up in the air, previous discussions were about spliting it up (i.e. for Images and other kinds) but I don't know of anyone who actually put in the work for doing that. **F** - We are at a standstill - I propose we move this for Review for next meeting and invite Alessandro to the follow on meeting. (**S** - He's very active on social, let's reach out). => [PR85](https://github.com/cardano-foundation/CIPs/pull/85) - "NFT Metadata Standard" moved to next meeting's Review + Author (Alessandro) invited to next meeting #### CIP0015 **S** - [PR89](https://github.com/cardano-foundation/CIPs/pull/89)/Update to CIP-0015, should be good to merge NOW, it's just updating the test vectors (matching what has already been implemented): For Round4 (Catalyst Fund4) they decided that the address specified in the metadata would not be the receiving address for rewards and rather the rewards would be handed out via mirror certificate again. **F** - Do we need Matthias to review? **D** - Happy to merge this one as-is. => Merge NOW #### Update Scripts **S** - [PR97](https://github.com/cardano-foundation/CIPs/pull/97) "Script to update ..." is not something that should be processed through the actual editorial grooup, not a CIP itself **F** - I'm assuming it is touching to the auto-generated site located at [cips.cardano.org](https://cips.cardano.org/) helps people browse CIPs themselves. => Move to merge as soon as we have CF FrontEnd review. #### dApp connector **F** - the next one is [PR88](https://github.com/cardano-foundation/CIPs/pull/88) - "Cardano dApp-Wallet Web Bridge". Did you get to look at it? **S** - Not worth talking about today: they are still tweaking a lot of things in there. **K** - Work on the dApp connector is being done within IOG... **S** - They (IOG) are welcome to add comments in this PR then: Yoroi ppl are implementing it now, and others in the community are also implementing this as-is. So there is a more involved conversation happening as usecases are still emerging. This will change over time and that's why I feel it's not worth digging into it, folks are adding comments in the threads. => Tabling PR88 for FUTURE meeting conversation #### Other **F** - [PR80](https://github.com/cardano-foundation/CIPs/pull/80) seem ready to merge. It adds to CIP-0010 (registry namespacing) **S** - Is this related to SPOCRA? It's been some time and things are a bit stale: If they are actually using this and there are transactions on chain that use it, I don't mind merging it. (I don't know if they ever did anything with it as there are no comments) => add to the thread and ask for example of use **F** - [PR83](https://github.com/cardano-foundation/CIPs/pull/83) - any reason why this is on hold. (**S** - No comments in there so on hold) => do nothing. ### Last Check ### Review #### Forging keys **F** - [PR96](https://github.com/cardano-foundation/CIPs/pull/96) (potential CIP-1855: "Forging policy keys for HD Wallets") - that's Derivation path for forging Tokens. **S** - No rush to do anything, PR is kindal stalled. Not much to go over. I think it's fine as-is and wouldn't mind merging it. It isn't anything too significant, just that we need a set of keys for forging tokens, unrelated to the wallet itself (not like you're forging from your wallet). They needed some key to forge, this is the same thing they did for Catalyst registration - and so created a derivation path for it. Same template, just change the path. => move to Last Check for next meeting + add Matthias for review. ### Discussions **F** - (thoughts about proactively trying to advance the CIP statuses as most remain as "Draft") + (Discussion) **R** - There's been only a couple of ppl interested in pursuing the SPO links (publicized in the forums late september and a few other places) - see links. Because of the way things delvelopped, nobody know about it and we will have to wait until thursday to get some feedback. This information about the potential of SP links, we tried to get it in the forefront about 8 months ago before folks here pushed to discuss. **K** these are the links to known stakepools right? (**R** - yes). I've seen SPO discuss this on TG and they weren't aware of this somehow pulled. The SPO that we pulled were picked rather than nominated. **R** - Glad that we're getting it out in the open **K** - This is on a private TG channel. If you want to get something in front of the SPO community then Ben is the right guy to contact for that. We have channels we use to inform SPOs.. **R** - I subscribed to that list yet I thought it was already made clear (that the CIP was there and what it would do, including marketing potential for SPOs) a few months ago. I thought that that meant that the issue wouldn't be covered in his channel. People were talking about publishing videos and other. And so many people might be linking to their stakepool... **K** - you need to ask Ben there. ### Close => Move to **Last Check** - [PR21 - "Non-Centralizing Rankings”](https://github.com/cardano-foundation/CIPs/pull/21) - potential 'CIP-0018’) => Move to **Last Check** - [PR66 - “Fair Min Fees”](https://github.com/cardano-foundation/CIPs/pull/66) - potential 'CIP-0017’) => Move to **Last Check** - [PR96 - "Forging policy keys for HD Wallets"](https://github.com/cardano-foundation/CIPs/pull/96) - potential 'CIP-1855’) => Move to **Discussion** - [PR82 & PR86 - stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82) => Move to **Review** - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85) - potential 'CIP-0020’) => Merge **NOW** - [PR89 / Update to CIP-0015](https://github.com/cardano-foundation/CIPs/pull/89) --- ## 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 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | Draft | | 19 | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019) | 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 | | 1854 | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-06-29.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [June 29 2021 notes](#june-29-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR66 / "Fair Min Fees"](#Followups) + [PR21 / "Non-Centralizing Rankings"](#Followups) + [PR96 / "Forging policy keys for HD Wallets"](#Forging-keys) * [Review](#review) + [PR85 / "NFT Metadata Standard"](#NFT) + [PR83 / "Multi-Stake-Keys Wallets"](#MSK-Wallets) * [Discussions](#discussions) + [PR82 / "Cardano Delegation Portfolios"](#Delegation) + [PR86 / Update to CIP-0013: "Cardano URI Scheme"](#Delegation) * [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 6/29/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## June 29 2021 notes **Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Duncan Coutts~, Frederic Johnson. Editorial Guest: Robert Phair, Alessandro Konrad. ### Triage ### Last Check #### Followups ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - "Fair Min Fees") **Frederic** - Fair ammount of conversation occured. Shawn (PR author) has confirmed by email that he would like to push for this merged. A lot of the conversation about this has occured, including some from IO Research in comments (See Colin's comments) as well as a Blogpost by IOHK but some of the feedback. **Robert** - Colin's comment clarifies a lot of things for everyone: It's hard to argue against a minimum fixed fee if we can wait until a min variable fee comes on, because then that prevents the combination of people feeling compelled to have 0 minimum fixed fee as well as 0 minimum variable fees. I think that's what some of the SPOs were worried about, as a kind of "race to 0"/bottom. With the min variable fee requiring a change to the protocol, whereas the min fixed fee can be done any time but would be too early without also imposing a min variable fee. **Matthias** - Reminder: we can merge a CIP without it meaning it will be implemented. Merging a PR means it has been reviewed and is technically valid, but might still not get implemented. => Merge NOW as a CIP-0023 ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings") **M** - The main problem that people have with the current ranking system (which is also its main point in a way) is that it is not fair for pools "beyond" the **k** limit (the system is trying to establish homeostasis around k, fixed by the protocol -currently 500- and pools that are beyond k appear unprofiteable - this is by design as the system is trying to achieve "k" pools) Pools beyond k are punished quite severly in the rankings, such as appearing unprofiteable. What this proposal here is doing is smoothing a bit the transition beyond K so that there is no more hardcut, but it is smoother... If you are close to k, then you get less punished than if you are severly further out. It makes the transition a bit smoother. **R** - Happy to move this forward. Meanwhile (I don't know if it's within the scope of this PR but) if "ranking" is always showing for every pool, then it will have a centralizing effect. Ex: for pools outside of k=500, will users get flags about the "beyond k" pools? (even from following an external delegation link ala [cip 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md)) there might be red flags and warning signs from the current discrimination, which would effectively centralize stakepools, and I want to go on record about this. **M** - Not sure the title aligns with the CIP though / this should be about "non-centralizing"... If you limit the number of stakepool then you are acting against decentralization. But we can adjust K if the goal is not acceptable, ex: from 500 to 2000 and such as needed - that was a bit the rationale about that. We have to find the sweet spot where you make most of the people happy and still achieve good decentralization? **R** - You might say something like "less abruptly centralizating rankings"? hard to put that into few works. **M** - It will not prevent having flags/warnings and still having a lot of incentives for having "less" than k pools because the entire system is designed around that... So if you really want to have "non-centralized rankings" then we probably need to rework the entire ranking system and not have that designed around k. And that's a totally different endeavor. I would agree with **R** and propose "less punitive rankings" as a better title. I would push for merging this as draft and then notify the author about the cosmetic changes. => Merge NOW as CIP-0018 #### Forging keys ([PR96](https://github.com/cardano-foundation/CIPs/pull/96) - "Forging policy keys for HD Wallets") **M** - The PR is straightforward - it's based on another proposal we've done around derivation paths. Here it's about agreeing on a specific HD path in the wallet to derive a set of keys, reserved for forging policies. People have so far been using arbitrary keys (generated on the fly, not attached to any wallets), or payment keys associated with their wallets, which is not necessarily good (You typically want to separate the activities such as 'payment' and 'forging policies' so that the security can be granularily adjusted). It's getting quite common to use 'purpose' for a new purpose. Only remark I had in there was a path in the file, which seem to be a copy/paste leftover. Beyond that, good PR. **S** - Last I looked, conceptually fine. => Merge NOW as CIP-1855 ### Review #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **Alessandro** - (PR Author) The Metadata Standard is meant not solely for images but any kind of mediafile. I made an update in the conversation about how I would propose to adjust it. (Looking at [conversation nested in a comment](https://github.com/cardano-foundation/CIPs/pull/85#discussion_r629120254)). There is this files" property, that is where you could specify any kind of mediatype you want. The basic idea about having "image" (field) separate is that nfts are 99% images already and the "image" field can double-function as a thumbnail. There are mediafiles like video or 3d models that you could have as nfts, yet most wallets would likely not display those properly. Here an "image" would enable a better UX for representation. SO two functionalities - it could either be a thumbnail, or the actual Image. The 'files' property meanwhile is an array where you might even put multiple files in there. That's the general idea. My issue with schema.org is that I'm not sure how to put that in because this is not only one type of medium: there are multiple mediums in there... **M** - You mention that you want types beyond images: [schema.org](https://schema.org/) actually provides json schemas for a lot of different media contents, not only images. And for each of those schema types - I think they have all the possible fields you could imagine on such a schema - The idea is not to require all those fields, but (if you have a list of files) you must have at least as the first type, the **type of object** that you are going to use, and then the rest of the schema will fall from the definition on schema.org, which gives you a broad level of extensibility. For example if the object type is image, then you know that any of the other fields might be present. And maybe we could specify some 'fields' to be mandatory and have applications relying on that, for example the exact mediatype for the iamge - jpeg, png, whatever... That was my past suggestion: let's rely on something that is battle-tested and has been proved to work as json schemas, but maybe for a few handpicked mediatypes require some fields to be mandatory. For example image, "at least X,Y,Z,.." **A** - The issue is that there are already nonstandard NFT projects out there, such as with a not-very-normal mediatype where the image is created out of a piece of code and the code is embedded in the metadata. I don't think (that for something like this) there is something on Schema.org... So we probably would have to support both cases. **M** - I wouldn't be so formal, there are lots of different types. Creative content/Code might fit in some of the existing categories. **R** - Schema.org would also provide / an already agreed-upon framework for representing ownership, as well as objects that may not be pieces of data, representing real-world objects (people, events, other). There are many usecases for NFTs beyond digital. **M** - There is actually a "software sourcecode" datatype... Plus also as Robert mentions, all the other (extra) properties that come on other schemas. **A** - There are already a lot of projects following this standard/CIP: If we want to add schema.org style, maybe we could move that towards a v2.0 so we can support both still? **M** - That would work. About the 'image' field with the double functionality: for a Standard you might expect everything to have (only) one purpose, that's why I propose to move it to 'thumbnail', so that has one singular purpose (and use 'files' to store the actual image data). **A** - It's not only for thumbnails though. If you want to make a very simple NFT (an image), you can just use the name and the actual image and THAT is the actual NFT. **M** - You could use the name and under 'files' have the actual image NFT itself. From an application standpoint everything is then more consistent, You only have a single way to process NFTs there (otherwise you always need to have a special case for 'images') **A** - So you would add the same file under 'files' as well as under 'image'? **M** - Yes: I would rather put the NFT content under 'files' because that's where the actual NFT goes. If the specification says "your NFT file goes in the 'files' property" then there shouldn't be a special case for image. If you want to have a thumbnail for the image it can still be created. Any application reading this can treat it in a consistent and singular manner to consume/handle. It eases the consumption/processing of that NFT. It doesn't make it much more complicated, but it makes it easier for the application consumers. **A** - For the end-user it might be a bit weird to have to put the same object twice. **M** - That's a UI problem, not a end-user problem. The user doesn't really care about the NFT format. The format here is meant to be digested by machines, not by humans. If it is not really appealing to humans that's not really a big deal so long as it is easy to process by a program. **A** - This could work. I think that sounds fine as a tentative future v2.0 (schema.org, thumbnail...) **M** - If everyone is already aligned with the current v1.0 as-is, no point changing yet. But it sounds good as a v2.0. **A** - Another question around the mediatype/MIMEtype. Is that something that needs to be added? **M** - No - I would rather go with the actual object name itself (on schema.org). A bunch of specific types are listed on the main page - either name of the type or just a link to the schema.org page that contains all the propoerties of that type. Maybe feasible to even have it directly to a json schema (link), so you might even download the schema and validate against it if you have to (for an application). **F** - Regarding PR85 - prior point was that usecase that it is starting to establish some kind of standard, should we merge or continue to review? **M** - Suggest merging it as-is, it's being used (plus Alessandro might open a new PR towards a v2.0). **A** - I still need to merge in the latest comments. **R** - Can you possibly include also a roadmap to 2.0 to hear what you're thinking about (users might want to select wether to stay with v1.0 or x.0 ..)? **A** - Can add. => Alessandro to add changes, Moving to 'Last-Check' for the next meeting. #### MSK Wallets ([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: "Multi-Stake-Keys Wallets") **M** - There has been a lot of interest around the ideas of multi-delegation, portfolio stuff and such. This PR is actually the CIP introducing multidelegation and its stakekeys (not the portfolio one that focuses on the format itself of the protfolio). I was thinking with Johannes about how we could do multidelegation on the wallet in a safe manner. Because that isn't actually a trivial problem and is why multidelegation has taken quite a long to come for Cardano - it isn't something that can be implemented at the protocol level currently, it has to a burden handled at the client/wallet level. For wallets to maintain multiple stakekeys can be cumbersome because the keys have to be managed independantly, and you have this whole mess of key registration/ delegation/deregistration etc... So once you have created an address and you put a stake key inside the address, that is fixed: that stake key will be in that address forever. The only way you can change the stake rights of the funds associated to that address is by changing the delegation settings of the stake key. But you can only delegate to a singular pool per stake key, and you cannot put multiple stake keys in an address, which means the wallet must do some form of key management, of rebalancing of its UTXOs (Cardano being a UTXO-based blockchain, we don't have the freedom accounts-based chains have, picking arbitrary ammounts and buckets of Txs). Here we have to select a particular number of UTXOs that have particular values and assign them to different pools. You can't arbitrarily fragment or defragment your UTXOs to adjust accordingly, but that's all work that goes on through wallets, and when you do that you also have this problem of the blockchain being a completely decentralized system. Many people today have more than one wallet, using Yoroi + Deadalus or Apple lite... there are many entry points to the system, doing modifications concurrently, and chain forks (especially in Ouroboros Praos), every 4 or 5 blocks there are forks with leaders getting elected on the same block which means (from a wallet standpoint) if you send a Tx, your Tx might get rolled back after a few blocks. It might get further inserted in the ledger and later disappear. If you are not too careful about your registration, and you want to be able to fully recover the state of your wallet from the blockchain state, you have to be very careful on how you activate chains of deregistration, because any of them might actually disappear because there would be a rollback on the chain fork. The true immutability is quite long on Praos at the moment - around 36 hours, beyond which you can be sure there won't be a rollback: the maximum length of the fork is fixed by the protocol. One of the first proposals touching multisig stakekeys proposed to wait 36 hours between each key registration, and was a poor UX of sorts. Even though you're not creating new keys constantly, you might want to do this a few times in short span when managing: delegating to a pool, changing your mind, switching to a different pool or other - waiting 36 hours between changes was poor experience.Because we already have a mechanism that makes sure that everything is sequentialized and cannot end up in a corrupt state: The UTXO model itself. So here one of the pain point can therefore become an advantage and guarantee ordering - The idea is to attach a particular UTXO to every stake key registration (or deregistration) so that there is ever only one UTXO that is consumed every time and passes from one registration to the next. It would contain only 1 ada, have no value except the minimum and is consumed by every registration such that if any (previous) registration gets rolled back, then each subsequent registrations are automatically invalidated as consuming a UTXO that no longer exist. Like that you enforce that what you see on the chain is really reflecting the state of your wallets. And there is no more risk on the (?)external or anything. If have two wallets at the same time doing key management or registration and submiting conflicting Txs, in the end the ledger itself will make sure that only one of the transactions goes through as only one UTXO can be consumed. For creating that special UTXO, we have also chosen a custom derivation path that isn't confliction with other payment keys of the wallet, such that the UTXO cannot be consumed inadvertently by the wallet during its normal operation, and for wallets that don't implement THAT CIP and meanwhile implement CIP-1852 (like most wallets today), then it's completely transparent and this won't interfere with the wallet activity. If the wallet then chooses to implement multi-stakekey delegation then they can implement that and use the special UTXO. This is this CIP - there were some questions in there already from Marcel Clamer which made me think that we might be able to clarify some things in the CIP itself, such as "Why" / "Why use a UTXO like that" I thought this was clear but apparently not enough - I will loop back and update on the PR and clarify some points, plus also translate the diagram Johannes is pointing to into something a bit more acceptable for the CIP. We have a first implementation going on in the wallet, which has so far been successfully tested on a harnet prototype. This is being finalized and also comforts us in the sense that this is indeed doable and works as we expect. There has been quite some extensive testing done on that with various scenarios - creating concurrent requests ... and we are now pretty sure this resolves the problems we might have with concurrency and a decentralized system. **S** - Everything said makes logical sense. **M** - I want to get some of the insights from Marcel's comments in there, such as making the intent clear and capturing some of the reasons in the body of the content. I would maybe prefer to review it again next time. **F** - we're getting a bit crowded on the review space. Would move to 'Last Check' to leave room for other CIPs to be reviewed. => Moved to 'Last Check' ### Discussions #### Delegation ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **R** - (About the Delegation conversation and Robert's outreach to the SPOs). Everyone knows about the conversations, there were 3 meetings - the first meeting (with SPOs) was on the 10th, then Frederic came on to the following meeting (two weeks later) mentioning the PRs, and I also met with SPOCRA (grouping of the large pools). The people who actually might need this CIP the most might not be in the SPOCRA meeting I attended then, so not a representative sampling of the pools. But longtime members were supportive of the process, the threads, that they know they can contribute on, also in github conversations. I think they are very practical-oriented people, and so are looking more at CIPs to align with a timeline, with some expectation of accountability. Which doesn't seem to sit well with the current iteration of what the CIP framework is for (more towards a standards body). Here's a link of how the SPOs are currently discussing it in their own forums, so any member of the community or orgs, anyone is welcome to join and follow how the issues are currently being presented to the SPO community (I have agreed to give them an update every few weeks on CIP and governance). Meanwhile IOHK's Daniel Ribar posted about "Catalyst Circle" while SPOCRA told me that IOHK brought this to a governance agency that came up with the plan for Catalyst Circle. It is a little bit toned down from what they initially recomended. From that same quarter they have issued some statement about this and Catalyst Circle being the first governance process within Cardano, there might be questions why they skipped the CIP process - I think it looks like two standards group emerging, see Daniel Ribar's post on the cardano forum. As these things evolve, we have links in both direction and all the people that we have mentioned in all those forums feel comfortable coming observe and discuss. **F** - Any preference or news about the PR conversation? **R** - All the people I spoke with say they would welcome both proposals merged in. On the surface they feel both are valid and would need to be there. **F** - The consensus we're looking for is that we're ok merging these concurently... **M** - Moving to Last Check would be fine. => Moved Both to 'Last Check' ### Close => Merge (**ASAP**) as CIP-0023 (Draft) - [PR66 - "Fair Min Fees"](https://github.com/cardano-foundation/CIPs/pull/66) => Merge (**ASAP**) as CIP-0024 (Draft) - [PR21 - "Non-Centralizing Rankings"](https://github.com/cardano-foundation/CIPs/pull/21) => Merge (**ASAP**) as CIP-1855 (Draft) - [PR96 - "Forging policy keys for HD Wallets"](https://github.com/cardano-foundation/CIPs/pull/96) => Move to **Last Check** - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85) - potential 'CIP-0020’) => Move to **Last Check** - [PR83 - “Multi Stake Keys Wallets”](https://github.com/cardano-foundation/CIPs/pull/83) - potential 'CIP-0018’) => Move to **Last Check** - [PR82 & PR86 - stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82) --- ## 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 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 | | 14 | [User-facing Asset Fingerprint](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0014) | Draft | | 15 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015) | Draft | | 16 | [Cryptographic Key Serialisation Formats](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0016) | Draft | | 19 | [Cardano Addresses](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019) | 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 | | 1854 | [Multi-signatures HD Wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1854) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-07-20.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [July 20 2021 notes](#july-20-2021-notes) * [Triage](#triage) + [PR66 / "Fair Min Fees"](#Followups) + [PR21 / "Non-Centralizing Rankings"](#Followups) + [PR96 / "Forging policy keys for HD Wallets"](#Forging-keys) * [Last Check](#last-check) + [PR82 / "Cardano Delegation Portfolios"](#Delegation) + [PR86 / Update to CIP-0013: "Cardano URI Scheme"](#Delegation) + [PR85 / "NFT Metadata Standard"](#NFT) + [PR83 / "Multi-Stake-Keys Wallets"](#MSK-Wallets) * [Review](#review) + [PR88 / "DApp connector"](#DApp) + [PR104 / "Collateral Key derivation"](#Collateral) * [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 7/20/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## July 20 2021 notes **Attending Editors**: Matthias Benkort, Sebastien Guillemot, Duncan Coutts, Frederic Johnson. Editorial Guest: Robert Phair. ### Triage #### Followups ([PR66](https://github.com/cardano-foundation/CIPs/pull/66) - "Fair Min Fees") **Frederic** - Process-wise we want to make sure that 3 out of 4 of the main editors have transparently approved the request. In this case you can see there are 3 already and is good to go as-is. => Merged as CIP-0023 ([PR21](https://github.com/cardano-foundation/CIPs/pull/21) - "Non-Centralizing Rankings") **F** - The CI checks were throwing errors - Clark (CF) helped push a PR to try addressing - how would you want to proceed? I propose we can push this through and adjust later as Draft. **M** - Unless Shawn has blocked it we can do a rebase of his branch by default. Will look into it. => Merged (CI Resolved) #### Forging keys ([PR96](https://github.com/cardano-foundation/CIPs/pull/96) - "Forging policy keys for HD Wallets") **M** - (checks gathered, good to merge) => Merged as CIP-1855 ### Last Check #### Delegation ([PR82](https://github.com/cardano-foundation/CIPs/pull/82) - potential CIP-0017: "Cardano Delegation Portfolio") ([PR86](https://github.com/cardano-foundation/CIPs/pull/86) / Update to CIP-0013: "Cardano URI Scheme") **F** - This has about delegation portfolio, can someone update on the state of this PR? **Matthias** - It hasn't changed for a month or two. That's mainly describing a JSON format for representing portfolios that can then be shared with wallets or application dealing with delegation such as SPOs. There were some divergence of opinions between Robert and I regarding what sort of structure we should try to go with for portfolios - try to offer decimals or units. Robert has a proposal that would have the SPOs represented in-URL, transporting some information in that medium, allowing decimals for weights - Not sure if we have really settled the discussion there or not Robert because there are arguments in both directions but I still don't really see why allowing decimals in weight would be useful since we can represent any number with a matter of integer fractions (multiplying the fractions by some numbers..) **Robert** - We have one or two pathological cases that came up when looking at how people would practically use them if the fractions / decimals are not allowed, like the case where Stakepool weights will default to 1. If we want a long list of reducded delegation then we can't use a number less than 1 to indicate a fraction. And there were two or three cases like that we reviewed in the prior meetings, also documented in the PRs. If anyone has specific ideas regarding if those cases are problems or not. We could try to add to the PRs and have them confirmed there? All of them would be about similar kinds of boundary conditions. Some of them didn't emerge until we considered how stakepool links could be made more concise, which is why the advantages of using fractions never really came up when the json portfolios were being considered, where you basically have an arbitrary ammount of precision in files that can have any size. But then the problem needs to be considered differently if you're trying to constraint the delegation portfolio within the space of a URI (PAUSE). It may be that "weither the decimals are appropriate for the json or not" is actually a separate question, of weither they are appropriate for the stakepool URIS. That's why I don't feel the differences HAVE to be resolved. It could just be that the datatype for the stakepool weighta would be more sensibly integers for the json file and would be decimals for the URI. I think we could go ahead with the plan to merge as they are, rather than try to reconcile a conflict that isn't really there. **Duncan** - Makes sense. No space constraint in the json and there is in the URI. **F** - [PR86](https://github.com/cardano-foundation/CIPs/pull/86) changes an existing CIP - [CIP-0013](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/README.md) while [PR82](https://github.com/cardano-foundation/CIPs/pull/82) would be a brand new CIP - Does it seem fine in that way? **M** - Yes, this is just an addition to an existing CIP, it doesn't invalidate what exists, just adds new primitives. => Merge ASAP #### NFT ([PR85](https://github.com/cardano-foundation/CIPs/pull/85) - potential CIP: "NFT Metadata Standard") **M** - Did Alessandro get time to update as requested last time - or update to the latest format? The idea was to merge "as-is" since it is being used by a lot of people. Did work begin on the next version / possibly a JSON schema version? **Sebastien** - I have not had the time to manually compare the JSON to see if it really matches: Can someone confirm that the commit that got added (since we last spoke about it) made it match with existing wallets and explorers? That was the only real concern with this - that the readme might not actually match what was implemented.. **Clark** (in chat) - "What will happen to the minted NFTs already by the way?" **S** - The NFTs on mainnet use this specification or a variant as mentioned in comments on the PR (instead of the actual Readme) - that was the main open question and it looks like there was a commit since then to match the spec. I was hoping if someobody in this meeting might be able to clarify that this looks good here (but looks like there is nobody... ) I'll approve this PR, under the assumption that the commit fixes what was expected to be fixed. **D** - Add that comment in your PR review and then we can proceed. This is not for last check is it? **F** - It is. **M** - There are a lot of good ideas on how to improve this one but that CIP has already been implemented by quite a few tools. One idea is to produce a new CIP version of this one, including all we discussed about format and structure so far, deprecating this one afterwards. Propose we merge [PR85](https://github.com/cardano-foundation/CIPs/pull/85), then modify it later through a new PR/version. **D** - Right. **F** - Should we move back to Last Check? **M** - Good to merge, as soon as we get the go ahead from Alessandro that he added what was needed. => Merged ASAP once ok'd by Alessandro #### MSK Wallets ([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: "Multi-Stake-Keys Wallets") **F** - This is setup as a 'Last Check'. Going through prior meeting notes, everything should be fine re:merging. **M** - Yes, all good. I will double check with Yohanes on the side because ihe has been working on an implementation to confirm that the CIP is actually sound. We will make an update to [CIP-0010](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/) to point to a first implementation of it (for reference) but it's not necessary right now. **D** - So is it an extension of the existing CIP that states you use index [0] and you have to folllow the derivation index? **M** - It's a bit more than that: we use a **special UTXO**, crafted from a stake key so that we can actually track which is the last stake key that is **registered** on the blockchain and this way, restoring the wallet on different machines/platforms and be totally resillient to the decentralized aspect of all this. **D** - So you look at it by checking at what is registered on the chain? **M** - Yes, we have one UTXO that gets consumed and produced for every Stake key registratiom, which makes sure that all stake key registrations are actually sequentialized. You cannot double spend your UTXO so cannot double register a key concurrently, and if any Registrations get rollback, then you get the whole chain is rolled back because of the UTXO chaining. We have outlined a number of problem, a lot of that using some good property testing - up until the point we arrived at this idea here to propose solving all of that. It's rather cheap and transparent for the user and so is the best compromise between UX and usability we found, which still lets us completely manage the multi stake key wallets without requiring any offchain information. **D** - Does that chain of UTXOs mean that all the stakekeys can be grouped together? **M** - "Grouped together?" **D** - That they are related to eachothers: Does the privacy disappear again? **M** - No. Or Maybe.. You could identify probably that 'a' particular registration is linked to another registration because if you know the previous stakekey, it will... registration certificate for a new stakekey and you could link it to the previous one. It doesn't completely solve the privacy issue because you could still rollback the registrations on the chain and get it back. I don't know if we could solve it really because you would always have a link to your previous stakekey or known stakekey, unless if we only use stakekeys that are only used for registration. **D** - The Privacy is not really a requirement. **M** - Privacy makes things better than the current situation because it is a bit more involved, but it would still be trivial to write a script to crawls the chain and unroll / get all registrations of prior keys (unless if using UTXOs only for registration..) **F** - Did you get answers regarding Marcel's comment? Should this be merged? **M** - Yes. We were wondering about maybe adding a diagram to the proposal to maybe make things clearer but we have not yet come with a clear enough diagram, so that might be a future edit. Good to merge I think. Enough information in it already to work out an implementation and we will add a link to a reference implementation in Haskell when ready. =>(asking for approvals for merge from Duncan/Sebastien, Matthias checking in) ### Review #### DApp ([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - "DApp connector") **Rob** - (PR Author) - This PR here is similarly to something we've implemented for ERGO. It's similar to what Metamask does - it does some code injection to expose a bunch of endpoints for user wallets for DApps and it's trying to standardize this so that we can have one standard that all DApps and wallets can use (instead of having separate competing things). The conversation is ongoing on the PR already, much has been about changing the signing endpoint so far (still need to be decided), newer conversation around how to handle what happens when multiple wallets implement the same spec (how should it be handled?). Also how we want the API - as a free floating function or entirely contained within the cardano instance: be returned from that said fn() as opposed to be injected (in a two phase injection). **M** - What do you mean "what happen when multiple wallets implement..." **R** - How the spec work right now is kinda like a two phase code injection: The first phase injects a free floating function, that DApps can use to request access to user's wallet, and then the DApp can call that and the user sees a confirmation box in their wallet, and if they accept, then the rest of the API gets injected (getUTXO(), getBalance() ... etc). But what happens if there are two separate wallets? if Yoroi implements it, and Adalite implements it - that is they would both be injecting the same code... **M** - but you wouldn't be using both at the same time... **R** - You'd still want to choose which wallet gets open. Right now if Yoroi injects first, Adalite override the fns that the API that Yoroi would have already injected. We're going to have to figure out a way around that. I posted some into the PR, have possible suggestions. **M** - My strawman suggestion is to go with namespaces: Register a particular ID for your wallet app - we can have that registry somewhere on the CIP. Then Yoroi, Adalite can have identifiers / be listed. New wallets can pick new ones. If you have many wallets that start injecting random Javascript in your page it might start becoming heavy. I don't think many people will use many wallets anyways. **R** - It's an edge case, just something to consider. **M** - There's also the case of other applications trying to inject things (instead of a wallet). **R** - That's why we don't have super-generic names for the most part. **M** - My only real worry is on the security aspect of it - all of that happens in the client/browser in a way and is very much hidden from the users. As a User you get prompted some things and you type in your passphrase or something like that .. and it's very easy for an evil DApp to inject itself and harvest your data. I am not sure how Metamask handles that problem. **R** - Do you mean the code impersonating the DApp or the wallet or both? **M** - The wallet **R** - It could do that and could return whatever it wants to and possibly cause the DApp to do something you don't want to. Assuming that's the worry you had? **M** - The DApp itself could be malicious - it could harvest passphrase or other. For example asking for a signature, where the wallet would require a passphrase to decrypt your key - which is typically handled by the wallet. **R** - For the signing we are implementing a different CIP - I think CIP-0008 the messaging spec. Are you talking about a keylogger? **S** - The concern is that you're using a DApp, and you click "sign" and it pops up a FAKE Yoroi... (**M** and basically anyone can inject javascript in the page) **R** - I see - that's significant. **M** - I've seen DApps impersonating Metamask - and they look like it but they are actually cataloging information on your behalf - they might not have access to your wallet but if you are using the same passphrase multiple places then you might be opening yourself to vulnerabilities. **R** - Do you know how Metamask handles that? **M** - I think a blogpost warning users to be careful? **S** - Banks solve this at account creation and picking a picture out of a few different options and every time you go and access the bank it displays that picture (and if not your picture then you are accessing a fake version of the bank). We could do some version of this but you know, it would be 'an extra page' the user has to confirm and I am not sure how people would understand the system (or why it exists => it might not help that much) **M** - We need some way, not only to authenticate the DApp onto the wallet but also the DApp on the wallet. The user needs to check that he/she is dealing with the wallet he expects to be dealing with and not some other fake app. Beyond all the UX and API we've made so far, I think there is a big big question around the security aspect of that one. **R** - Would that be in scope for this? It would make sense to have a security section in there, but not sure about "mandating" things. **M** - I worry about wallets going on and implementing this without looking at the security concern. If we just push it out as a "wallet concern", that's taking the risk that all the wallets will get it wrong. **R** - There are several areas for security where the wallets will have to be cogniscent so that it should be "provably secure" rather than "making it work". Do you think we should have some standardized "wallet authentication system"? **M** - Yoroi has the little 'visual checksum' when you access your wallet, that only you know in principle (unless you share screenshots). It could be that every popup has that checksum in place and you could control that you are acessing your wallet. this might be a sane way to make sure you are actually dealing with your Yoroi wallet. We could suggest that implementation push for a proof that the user is dealing with the wallet (they are expecting to deal with). **R** - And on the flipside: can you think of concrete example/attack where the DApp is being impersonated (rather than the wallet)? **M** - In the PR comment I gave one example around the signing function: If you are actually signing anything, do not sign an arbitrary message, and make sure you only return the witnesses and not the fully serialized transaction. As a DApp you only want to get the signature produced, you don't necessarily trust the wallet to have returned you the right thing. You want to reconstruct the tx body YOU have constructed - you want to get signatures for that and THEN do the combination yourself. You don't want to blindly trust the wallet for a serialized thing. If you blindly trust whatever you get serialized from the wallet without actually checking that this is what you passed in the first place, then that's bad. **R** - There was also some discussion around partial signing as well for more complicated usecases.. **M** - A tx is not by default valid after a signature: could be multiple signers required, or other arbitrary reqs.. I think that should just be the default of the API actually: you pass a particular body and you ask for a signature from one of the wallet keys, and as a DApp you have constructed the transaction so you know what to expect (e.g. if multisig you know you will require a sig from the other user) **R** - When you say we were trying to sign from one key, are you specifying which key to the wallet somehow or..? **M** - The idea is to point that to a particular input although in practice not only inputs require signatures: That's fine for payments but if we go a bit deeper down the Alonzo path, you can sign pretty much anything. Consider 'certificates' even - that's not even pointing at an input, that's pointing to a stakekey, or at a certificate. The signature should have a way to point to anything in the tx as "I need a signature for that particular certificate" -> the wallet should know which key corresponds to that and produce the appropriate signatures (after approval by the user) OR you request a public key (and the wallet can product a signature matched to that key). Might be public key hash rather than public key. I don't need a way to point to what element needs signed really, it could be many things. Or you give out the keyhash you expect a signature from. **R** - Are there possibilities where the keyhash might be a bad idea? **F** - short on time, let's move this back to follow-on meeting for discussion. =>Discussion in the PR itself - To be Reviewed again next meeting #### Collateral ([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - "Collateral key derivation") **S** - Background here - as of Alonzo, all txs that call smart contracts will require collateral inputs. That collateral input has a few restricitions: it cannot contain any tokens and cannot be locked by any script. It has to be just ada. You can reuse your regular inputs as collateral inputs, they don't have to be separate, but there's no guarantee that the wallet has valid collateral input. On top of this, there is a minimal collateral you have to put up, to cover the tx fee for the smart contract yet nothing is stoping you from overcollateralizing. This isn't too dangerous because txs calling smart-contracts should never fail if all goes as planned. Yet some Qs remain such as how to handle HW wallets. Historically the HW wallet prompt you for every field in the Tx, so should we show the user of the HW wallet how much collateral they are putting up? This might be concerning for the HW wallet users calling a smartcontract, they might be confused by a prompt asking if they are "OK with a collateral of xxxx ada" but this might be the right way to go about to protect against a hostile app. That's the kind of consideration taking place. My main concern is about input selection: all wallets have to select which inputs to use for a tx, and because of this collateral system, the wallet has to make sure that there are always inputs 'suitable' as collateral input, so some UTXO with no tokens on it that isn't blocked by a script. If you don't have UTXOs matching those requirements, the wallet will have to prompt you "You have no UTXOs that fit these requirements, you need to rearrange the UTXOs to be able to use this contract": Imagine on Ethereum if you were trying to quickly call some uniswap smart contract while trying to make a swap and your wallet prompts for a UTXO swap... wait for a few minutes for the Tx to be confirmed before you can actually call the contract (by which time someone else might actually have called the swap) ... This is a really poor UX, where the reorg has to be confirmed and so we want to minimize the number of time you have to do that rearrangement because it's such a UX hit. The easiest way IMO we can reduce the number of times we have that happening is by speciying a **new derivation path**: I added a new derivation path at index [3]: So we have External Chain at [0], internal Chain at [1], staking key at [2] and collateral key account at [3]. Any ada put into this will be a flag to the wallet, basically "don't spend ada from this address unless you have to". That way if you ever have to rearrange your UTXOs for a DApp, then it knows to use this as collateral. This makes sure that all wallets in the ecosystem are not actually stepping over eachothers and spending their collateral inputs. This should minimize the ammount of time that users have to do any rearrangements. There is a problem with this specification, it increases what the user has to know - here that there is this new derivation path for collateral. We can make it very explicit for the user i.e. "You have this collateral address, here's how much collateral you have". Or we could make it implicit (as an implementation detail): there's that colleteral account and we don't tell the user it exists (and we let the wallet manage it for you). I prefer being explicit about it, I think this is up to the wallets themselves. I feel having this derivation path is the right thing to do because it will minimize the number of rearranges required. **M** - This makes sense to me although I haven't followed the discussion in the PR - I saw 60 messages and felt there were already enough people discussing. **S** - Most of the messages I feel are going down a different path maybe, focusing on weither or not some contract could fail or the implications of failing (which I feel are valid considerations). IMO the more important thread is about trying to minimize the rearrangement, but it being a more subtle topic, folks tend to go to the more flashy aspects. => Moving to Review ### Discussions N/A ### Close => **Merged** as CIP-0023 (Draft) - [PR66 - "Fair Min Fees"](https://github.com/cardano-foundation/CIPs/pull/66) => **Merged** as CIP-0024 (Draft) - [PR21 - "Non-Centralizing Rankings"](https://github.com/cardano-foundation/CIPs/pull/21) => **Merged** as CIP-1855 (Draft) - [PR96 - "Forging policy keys for HD Wallets"](https://github.com/cardano-foundation/CIPs/pull/96) => **Merged** as CIP-0025 (Draft) - [PR85 - “NFT Metadata Standard”](https://github.com/cardano-foundation/CIPs/pull/85) => **Merged** as CIP-0017 (Draft) - [PR82 stakepool delegation PRs](https://github.com/cardano-foundation/CIPs/pull/82) => **Merged** [PR86 / Update to CIP-0013 "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/pull/86) => **Merge** pending (Internal checks pending) - [PR83 - “Multi Stake Keys Wallets”](https://github.com/cardano-foundation/CIPs/pull/83) - potential 'CIP-0018’) => Moved to **REVIEW** [PR88 - "DApp connector"](https://github.com/cardano-foundation/CIPs/pull/88) => Moved to **REVIEW** [PR104 - "Collateral key derivation"](https://github.com/cardano-foundation/CIPs/pull/104) => Moved to **REVIEW** [PR100 - "Transaction message/Command metadata"](https://github.com/cardano-foundation/CIPs/pull/100) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/README.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/README.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/README.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/README.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/README.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/README.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/README.md) | Draft | | 8 | [Message Signing](../CIP-0008/README.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/README.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/README.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/README.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/README.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/README.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/README.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/README.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/README.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/README.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/README.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/README.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/README.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/README.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/README.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/README.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/README.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/README.md) | Draft | :bulb: - For more details about Statuses, refer to [CIP1](../CIP-0001/README.md). ### CIP creation process as a Sequence Diagram _"Alice has a Cardano idea she'd like to build more formally":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-08-03.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 3 2021 notes](#august-3-2021-notes) * [Triage](#triage) + [PR83 / "Multi-Stake-Keys Wallets"](#MSK-Wallets) * [Last Check](#last-check) * [Review](#review) + [PR104 / "Collateral Key derivation"](#Collateral) + [PR88 / "DApp connector"](#DApp) + [PR100 / "Transaction Message"](#Message) + [PR102 / "Pool Operator Verification"](#Pool) * [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 8/3/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## August 3 2021 notes **Attending Editors**: Matthias Benkort, Sebastien Guillemot, Duncan Coutts, Frederic Johnson. Editorial Guest: Robert Phair. ### Triage #### MSK Wallets ([PR83](https://github.com/cardano-foundation/CIPs/pull/83) - potential CIP: "Multi-Stake-Keys Wallets") **Frederic** - This was already a last check and was approved last meeting - it is now a matter of gathering the formal number of approvals in github. => Merged as [CIP-0018](../CIP-0018/README.md) ### Last Check ### Review #### Collateral ([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - "Collateral key derivation") **Sebastien** - The point of this CIP is mostly to solve two problems: one is the fact that to have collateral readily available for transactions, we need to make sure that the way the wallets pick inputs and outputs is done in a smart way, and we also want that in the case where the user has to rearrange the utxo set, it is done in a way that is understandable to the user - Obviously we prefer them not worry about the internal workings, sometimes there is no choice and we have to make it as understandable as feasible. I feel the easiest way to do this is similar to what we did with internal addresses: create an alternate derivation chain, this time as the collateral address derivation chain. We would make sure that wallets when creating Txs put (have) ada in the collateral address and then whenever they are doing regular Txs, you never touch the collateral address unless if needed (ex: if the user were to send all his ada). This way when wallets need to do Tx - such as with smart contracts - it doesn't require any fancy logic such as having enough collateral etc... In most case it should be readily availlable and that should minimize the number of times where users needs to rearrange Txs. In the case it is needed, it becomes easier to explain why and how: we prompt about the collateral address and user will understand. That's the main motivation. The side motivation prevents/avoid putting a million ada for collateral especially for HW wallets. Probably the HW wallets should tell the users how much collateral they are putting up for Txs. And so we should make sure the collateral is not some absurd ammount (even though that's probably safe). This specification covers this as well as it would enable for wallets to mointor the collateral address and make sure it doesn't have abusrd ammounts in it. **Matthias** - Without even talking about risks or mitigating, the conception, it might be good to have a dedicated namespace to put this sort of keys in. Just for the sake of doing the coin selection on the wallet, and also from the user perspective, to be able to report exactly how many ada is available as collateral. **Duncan** - With my 'technical architect' hat on, I've already shared my opinion on the ticket - I don't like it and have explained reasons why in the comments. With my editor hat on: it's a proposal, it makes sense, it's self-consistent... it's just that my architect recomendation would be to not do this, not implement this bridge. **M** - What are your main arguments against? **D** - Summarized in the comments - I don't think we need to create this new concept for users, it's not something they have to understand or ever know about. **M** - Sortof: If it is a request for a Txs and it fails because they don't have enough to put up for collateral, what does the wallet say? it's not a fee, it's not a deposit.. **D** - We already have this situation already, where you may need to do rearrangement within the wallet to spend certain ammonts. This is another situation where the same is needed... it would be unusual. The vast majority of the time users wouldn't encounter this. But occasionaly they might, just like if they wanted to spend something like 99.9% of a wallet and you don't have the UTXOs properly arranged. I don't think it's beyond our wits to figure out some sort of wording to explain that we need to rearrange the coins within the wallets. **S** - The case for this happening is really a user wanting to send some ada to somebody yet having NFTs tied to some of the UTXOs. This is already happening (and isn't that rare) and is clearly something we want to minimize. The easiest way to do that is to have this kind of namespace. I think trying to shove this into the coin selection algorithm complicates all the code and does not even give that great results. It's best to avoid rearrangements entirely just through the namespace. **M** - Even from a user's perspective actually, it makes sense: in terms of user flow, we first ask for a small deposit as a collateral, that is reserved under this specific space under the key derivation scheme (used by the wallet just for that) and there is no reason why this would ever be consumed if the wallet is doing its job correctly. So it's really like a traditional deposit, like as you'd do for when you rent a place. Except that here it's deposited with the assumption the wallet does its job correctly. **S** - The way this proposal is written now does not have the wallet ever automatically add collateral for the user. It is done through an EXPLICIT process, which doesn't have to be the case: there is nothing stopping the wallet from proactively putting some amount in the collateral, because at the end of the day, it's not like it's lost: it's on the side and only spent if there is need. This might be better for the user even. **M** - This is even more important for Native Assets, that there is a tendancy to group Native Assets together in a single UTXO. So the number of UTXOs that only contains ada tends to be reduced over time. For users who tend to transact with NFTs and Native Assets they end up with very very dense UTXOs... **S** - If we don't have this kind of CIP, this concept of rearrangement would not be a rare occurence but would be more frequent / every other transaction kindof. **D** - Over the long term, as you do series of transactions - if we want to make sure we consolidate tokens and have enough UTXOs only containing ada - that's a thing we can do as part of the coin sleection. We don't need to make it a hard and fast rule, but rather something that the coin selection does. Doesn't mean it should be in a separate bucket. **M** - There are multiple wallets doing multiple coin selection in their own ways, so having a standard like this would help. **D** - The standard could say "you need to make sure you keep things in a specal place"... I think the danger of making it separate is that it's NOT available to the coin selection, and having to explain that "it's not really in your wallet or really available". Yes, you need to have coin-selection (of different wallets) help to avoid having too many of those rearrangement transactions, but it doesn't mean you should go all the way and introduce new concepts to end users. **M** - I disagree - I think users need to know at some point. This is a case here, in the same way we had to mention the stakekees. People were getting confused about the "2 ada fee" despite it being a deposit that you get back. Most users are not aware of how it works. That's normal, you get to learn about it later on. It doens't have to be in your face when you start a contract. If the user tries to spend their ENTIRE wallet without enough collateral, the wallet could prompt them with a message saying "Are you sure you want to do that?" or "This would impact your ability to run scripts/smartcontracts (unless rearrangement)" **D** - Soft rearrangement is fine. This would mean you'd have to adjust the available balance. It's always in your face rather than an occasional "corner case". **M** - Nothing wrong with breaking down available total. **D** - I think that creates more problems / is unnecessary. **S** - The question of how to present to the user depends on a lot of things. We could have said that we deal with Internal/External ada balances when we had two derivations then, but everybody chose to consider internal/external as the same for purpose of balances and we can do the same thing here.. **D** - Because we're trying to create an extraction fee. Users don't want to have to do UTXO managmeent. **S** - There is no reason we can't do that here as well (not show the collateral explicitely). The User doesn't have to know about this unless they are in this kind of case. **D** - But in once case, it is availlable, and in the other it ISN'T. **S** - And in this CIP we would not make it available unless needed. **D** - But then that means it IS available. Which means you no longer need separate addresses for it, which is quite different than what this CIP is proposing (and a lot better in my mind) and you wouldn't even need separate addresses: rather a policy for coin selection that typicially maintains enough collateral (if wallets are using it). **M** - That's similar to how rewards work: they are in your wallet but are not really available **D** - We tried to maintain a simple user abstraction that you have a set ammount of money in your wallet without all this notion of reward. **M** - The same thing could be done for the collateral - because it is located on a separate derivation chain, doesn't mean the wallet can't select that for coin selection. **D** - If it is (available), then the need for putting it on a separate address is much much less! If it's completely an internal thing (not what is proposed here) - that is different. It would then seem a bit more unecessary, as if we've introduced a possible inncompatibility (where wallets now have to be aware of this to report totals and balances, where diferent wallets report differently etc..). Making this a policy of coin selection would not change the fundamental compatibility, but deals with the problem more elegantly. **S** - Wallets will have to update for Alonzo the same they had to upgrade for Shelley when we added reward addresses. **D** - There is no new special address here though. **S** - For the new derivation path. In Shelley we had to have all wallets upgrade so as to know about the reward address and its derivation path. **D** - But there's nothing like that in Alonzo. **S** - From the wallet perpsective it might need if they want to do scripts. **D** - I can't think of anything that would require to change the schemes. **M** - As soon as the wallet want to spin Plutus Scripts then they would have to acknowledge for the Plutus stuff **D** - But then the same wallet would still be restorable in a different wallet just not supporting Plutus Txs. There is nothing that we would need to do that would be incompatible (just adding the ability for ordinary wallets to fund script transations: where the scripts are not in the cell with addressses part of the wallet). It's more like please fund this script for me, and keep things in your wallet. There is no incompatible changes: You need to add functionality in the wallet, but if you were to restore that very wallet, you would get the same exact balance in any (other / non-script / non-plutus) wallet. If different wallets report different balances it would scare people. (Yet, with my CIP Editor hat on:) I think it's self-consistent, clearly explained, makes sense. I should probably not argue too much about it. **S** - I think the steps forward from here is I will change the wording on the PR based on my discussion with Matthias, to allow for different wallets to either explicitly show the information to the user and also explicitly show based on the wallet preference. **D** - I encourage to think through the possibility of a design where it was just done such as an ateration to Coin Selection as a CIP... **S** - The Cardano wallet team has already looked at it and have as an internal document. **D** - But if it's something where multiple wallets would benefit on this rather than stepping on eachothers toes, then it would be better as a CIP. **S** - Would need to speak with Jonathan on that. Would prefer merging this sooner than later given the Hardfork is only a month away. Given that we don't have that many meetings left before. **M** - I want to discuss this offline a bit further due to technical decisions. => Moved to "Last Check" tentatively (might be merged earlier depending on conversation) #### DApp ([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - "DApp connector") **Rob** - This is mostly the continuation of what was discussed two weeks ago (see notes). The main things we didn't really cover in the last meeting were issues pertaining to what happens if there were multiple versions of the spec and if later some changes came in, how exactly DApps would be requesting which version of the spec they require and also what happens if there are multiple wallets implementing this specs. I was looking into that and there doesn't seem to be a good solution on Ethereum (besides "don't have multiple wallets"). I posted two possible solutions to that in this PR. **M** - We mentioned namespaces last time as a possible solution.. **R** - By "namespace": do you mean a Cardano object and you would inject multiple properties for the wallets that implement that? **M** - Yes, part of the CIP probably, a registry of sorts where wallets can register their own IDs such that they would only inject in that specific namespace ID. Which is maybe a bit harder for DApps to choose a wallet but makes it for better UX. If you have two wallets injected, as DApp you can ask the user which to use and how to request. **R** - Yet if the DApp is not aware there are changes to the registry, would it still be able to see all the wallet it can interact with? **M** - You can always inspect the Cardano object for Registry key(s). The registry on the CIP would just be for wallet so they don't have conflicting IDs: Just for that sole purpose. **R** - That sounds like a reasonbable approach. One of the approaches I considered was to just be injecting the list as an object property, but this works as well. **M** - We could also specify for wallets to use UUID v.4 so that there is no conflict possible and no need for a registry. You stick to it for your half-life cycle. That would however mean that we would need some kind of metadata attached here - a schema that identifies a wallet maybe - something with name, version, implementers / whatnot. **R** - I guess if someone ever needs some nice UI for choosing a wallet, then someone can create a library that analizes the version numbers and only show the ones that are relevant to DApps or something like that. **S** - If we go the registry route, we could even inline the registry with this CIP like we did for [CIP-0010](../CIP-0010/README.md) . And just expose it as an object with a set of keys. **R** - That sounds quite simple, I didn't know if that should just be injected or external.. **M** - There could be a reference implementation in this CIP, and I would even encourage people to follow the specification rather than doing things their own way. Doesn't mean it should be done by you or right now, but this would be a nice track to develop. There are 3 methods to get addresses here: getUsedAddresses(), getUnusedAddresses() and getChangeAddress(). But there is actually no method to get any public key from teh wallet, which I think would be quite useful, to be able to query for any public key at any path, which might actually be more useful than addresses probably, because it's pretty easy to construct from a set of public keys. Knowing which address is in use is useful, being able to generate a change address a bit less: you can do that from a public key so long as you can pick a right key. I would lower down the abstraction layer and instead of working with addresses work with keys directly. So that we can get DApps to generate corresponding addresses. That way, if they want to add a stake part to the address or script they can. They can really construct that how they want. **R** - Would your proposed change just be a litteral switch between addresses instead to public keys then? **M** - Pretty much, and instead reduce that to only one function - getVerificationKey(). Working out of the path, enabling that corresponding key. **S** - If you do it this way, there needs to have other information on what kind of key it is. There is no guarantee the key you're getting is a [CIP-1852](../CIP-1852/README.md) key. You could pass in the path to the key or something like that. **M** - It's a bit closer to how hardware wallets opperate: they don't really make any assumptions regarding what scheme is used (although they use BIP32 as a route for defining the hierarchy) but what path is used (within that hierarchy) is up to the client. Although they provide extra checks to make sure you don't do anything bonkers. That's a bit more flexible but that adds more complexity to the DApp itself, and then the DApp has to know what kind of path it is looking for. So perhaps there are usecases for both: (1) The ability of getting an address and letting the wallet decide what a valid address is. But also have the flexibility (2) to get a verification key for that/DApp (which is maybe more advanced) and know exactly what you are doing with keys. **R** - Would it be useful to have an API that (given an address) could return a verification key? **M** - Unfortunately not possible - because in an address is a hash of a verification key.. Or do you mean as a the wallet and do a reverse lookup? The wallets keep track of a certain number of keys, so that they can reverse-lookup back an address to a particular key. But that means you cannot ask for an arbitrary address: if the wallet doesn't know of that address there is no way it could tell you about a key associated with the address. **R** - I am talking about a wallet-controlled adresses... Because what other addresses would you be returning? **S** - I feel there is a usecase for exploring the Public Key. There is also a usecase for providing the endpoints as userfriendly. There will be a need when we get to Alonzo for something like GetCollateralAddress(), depending on how much ada you need it would return to you some UTXOs with enough collateral ... I'd rather not every role have to implement that kind of thing itself by looking at the account key and figuring out what to do. We may even run in this thing where some alts have varied set of addresses and preferably abstract that through DApps if possible. **M** - The conversation should continue, notably on the PR - there are things to say we don't have time to cover. Will add after the call. => Moved to "Review" in two weeks. Rob to adjust PR towards a registry-like solution. Matthias to add comments. #### Pool ([PR102](https://github.com/cardano-foundation/CIPs/pull/102) - "Pool Operator Verification") **M** - This describes a protocol to authenticate stake pool operators on various websites. There are different tools and platforms today like adapool, adatools you name it, which shows stakepools and will also occasionaly provide some aditional interface for stakepool operators. But there is no clear way (yet) to aunthenticate yourself (as an SPO) and prove that you are indeed the actual owner of a particular pool. This is the problem this PR/CIP is trying to solve, by providing a flow that can be implemented by both an SPO trying to get validation and a validating server. This is a very well-known approach: You have a challenge sent by the server and you have to sign it with your SPO secret key, such that the server can then verify it against your public key, and if you are the owner of that private/public key, you can provide the signature. We made some edits on the protocol to make sure that the server cannot really fool the SPO into signing something else (than a challenge) and there is enough randomness to prevent replayability. **F** - Isn't that CA-like or ..? **M** - You would have many validating servers if you want - such that PoolTool.io might choose to implement that protocol. The same thing couuld be implemented by other services. **F** - So SPOCRA might run one such server, as an external entity? **M** - Yes, but this is really describing A flow, not who is doing it... There is also a reference implementation for both the client and the server - and as far as I know this has already been implemented in the CNCLI community tool. **S** - I think this is good. Still this is yet another way of signing or representing stuff - I would prefer if we could combined this with the message signing spec (CIP?) in some way. But maybe the message signing spec is more for UTXOs or keytypes and I don't really find it to be super different. **Robert** - I think it is good and ready to go. The idea SPOCRA or other party to be involved might be good. => Moved to "Last Check" #### issue ([Issue109](https://github.com/cardano-foundation/CIPs/issues/109) - issues with the autogen site) **F** - (issue not a PR) - it seems the autogenerated site is not getting the attention it deserves. **Robert** - It might be graphic but it touches to text documents - here [CIP-0003](../CIP-0003/README.md) has a lot of documents in the PR but they are stripped through the auto-gen site - and this was not seen after it was merge - we saw it after the Public website was built. I see we have some other supporting files in [CIP-1852](../CIP-1852/README.md) that we were looking at and they all have relative pathnames to it, and some of them that were added were not detected while the other from the [CIP-0011](../CIP-0011/README.md) was always invalid. This was probably never noticed before the issue was raised. This is affecting more than one post in the CIPs. **M** - I don't think the CIP relative links should afftect the CIP but it could be that the website doesn't properly export the files (and only exports the readme). There is also the option of just getting rid of the exported website and sticking to the github website for browsing the CIPs. **R** - If that's acceptable for the CF, I think that would be good. In fact I think it even gives them a barrier, and the perspective that things are read only. But seeing things on Github projects that they can get involved, even after they have been pushed. **M** - And the benefit we get is that it's all markdown - we get maybe a slightly nicer interface. Would even propose we rename all the CIP files as "Readme" by default - which WOULD break the existing system and the site export. If we get rid of that it would make Github the default UI for navigating the CIP in a quite friendly way. **F** - Maybe pushing this out to the later roadmap for the CIP program we're fleshing out - creating a Jira ticket for this. Renaming might be an issue. Getting a community site auto-pulling from the current repo would potentially be good. Up in the air on this one. => ading a Jira ticket and potential Roadmap #### Message ([PR100](https://github.com/cardano-foundation/CIPs/pull/100) - "Transaction Message") **S** - The spec is simple, nothing technically wrong with what they did, people wanted it: I don't see a reason not to merge it. **M** - Fine by me. Seem sensible and already being used. => Moving to "Last Check" (correct and in use) ### Discussions **M** - Hoping to move the Wallet DApp connector PR. It would be good to settle on a design so that when Plutus lands we have wallets ready to cooperate. Yet the DApp PR only covers very basic wallet stuff, and with Alonzo coming there are new things coming in and we'd want to get done by a DApp connector likely like script validation and collateral allocation and this sort of things. It's a good start but will not be sufficient and should be updated for Alonzo. ### Close => **Merged** as CIP-0018 (Draft) - [PR83 - "Multi-Stake-Keys Wallets"](https://github.com/cardano-foundation/CIPs/pull/83) => Moved to "Last Check" (Internal checks might hurry merge) - [PR104 - “Collateral key derivation”](https://github.com/cardano-foundation/CIPs/pull/104) - potential 'CIP-0027’) => Moved to "Last Check" - [PR102 - “Pool Operator Verification”](https://github.com/cardano-foundation/CIPs/pull/102) - potential 'CIP-0022’) => Moved to "Last Check" - [PR100 - “Transaction Message”](https://github.com/cardano-foundation/CIPs/pull/100) - potential 'CIP-0020’) => Moved to **REVIEW** - [PR88 - "DApp connector"](https://github.com/cardano-foundation/CIPs/pull/88) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/README.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/README.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/README.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/README.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/README.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/README.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/README.md) | Draft | | 8 | [Message Signing](../CIP-0008/README.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/README.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/README.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/README.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/README.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/README.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/README.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/README.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/README.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/README.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/README.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/README.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/README.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/README.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/README.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/README.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/README.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/README.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/README.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-08-17.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 17 2021 notes](#august-17-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR104 / "Collateral Key derivation"](#Collateral-Key-derivation) + [PR102 / "Pool Operator Verification"](#Pool-Operator-Verification) + [PR100 / "Transaction Message"](#Transaction-Message) * [Review](#review) + [PR88 / "DApp connector"](#Dapp-connector) + [PR107 / "Restriction on transactions signed by hardware wallets"](#HW-Wallet-signatures) * [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 8/17/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## August 17 2021 notes **Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community guest: Gabriel ([PR107](https://github.com/cardano-foundation/CIPs/pull/107) author). ### Triage ### Last Check #### Collateral Key Derivation ([PR104](https://github.com/cardano-foundation/CIPs/pull/104) - "Collateral key derivation") **Sebastien** - Based on discussion, it looks like one of the ways we could avoid making too many reorganization Txs, is to allow tokens to be included inside collateral inputs - which means that there would also be a need to specify collateral outputs... This would make it that much easier to include transaction in the collateral, but I am not sure that anyone is actually working on those ledger changes for this because the HF is so soon. **Duncan** - It certainly will not be included in the next HF. The point of that discussion was that if it there was consensus (that it was a good solution) it could make it in the next HF (Babbage) but that consensus has not been reached from my point of view. When I did bring it up internally, the folks from the Daedalus wallet / wallet backend team did not think they would particularly benefit from it. I proposed that idea as an alternative to this and if you think it is a good idea, perhaps you can help make a bit more noise about it / clarify or argue that we should add it to Babbage. But there is certainly no time for the Alonzo HF. **S** - For this specific idea, I have mixed feelings: it's slightly hacky, doesn't solve all cases but alleviates some of them (so it's not a "Bad idea"). I feel that if we were to go down that route it would have made more sense to create some equivalent to the rewards account that could optionally be used as collateral if wanted, so a collateral address could be a utxo address or account-style address, and then account-style address could have tokens in some way shape or forms. But that seem like way too much work to solve the problem.. **D** - Also it wouldn't work in general because you need at least ONE UTXO per Tx that gets consumed (for replay protection). We don't really want to go down the acccount-route style for a full hybrid thing... No particular demand for that. **S** - I don't think there is particularly a path forward for this CIP/PR, we could mark it as 'Rejected' and move on, leave it up for others to dig into it? **D** - I think we wouldn't want it rejected as it is a perfectly self-contained well formed proposal. I guess you might choose to withdraw it as a better solution rather than rejecting it. We don't reject it as editors. I suggest you continue this discussion with IOHK's Wallet backend team: if you can come to consensus that there is agreement on, then it becomes easier to argue for. **S** - Vaccuum labs said that one of the benefits from this approach would be for HW wallets, because we'd like HW wallets to be able to validate how much collateral is being inputted into their transaction. But they mention they see no good way to do that, because transaction endpoint don't contain the inputs explicitly.. **D** - That's not a solution right? If that's a problem HW wallet have in general (because it's not just for collateral), then they can't verify the input for anything - and if they really want to be able to do that, they can say "we want an extension where any input (collateral or otherwise) can specify an assertion on how much is being spent there" **S** - The problem is that to do this you need to add a lot of logic and the ledger app doesn't have enough memory for that. So they wouldn't be able to provide any protection wether or not this CIP is added regardless (because of the memory limitations and the complexity involved). **D** - You wouldn't be able to tell how much money is in, even if it's in a 'specially-derived' address. **S** - For this PR: This issue will continue to come up so will need to be addressed at some point (Not necessarily through this CIP). If we have to wait for the next HF anyways, we can have more in-depth conversations after we see more onchain activity and see what happens... **D** - Just on timing, if you think you want to get something added to a HF which is not completely trivial, any such decision should happen early in the cycle, since the changes going into a HF on the Ledger have to be ready at the beginning, not at the end, due to the need to be formalized etc. => Issue / conversation to continue, this PR tabled #### Pool Operator Verification ([PR102](https://github.com/cardano-foundation/CIPs/pull/102) - "Pool Operator Verification") **Sebastien** - This is already implemented. I don't think there are any objections. **Matthias** - Everyone approved, looks good. Andrew did the change touching to the CIP number, so all good. **D** - Did anyone get a cryptographer to look at the VRF? There is a proposal here about using VRF Crypto, which is not completely obvious to me, which seem exactly the kind of thing where we would benefit from having a Cryptographer looking into it.. I would suggest to get Inigo to give a review from a cryptographist POV. **M** - Makes sense, I will reach out to Inigo. We already had a couple of rounds, making sure that people were not signing things that they shouldn't. It should be good but it's good to get a second set of eyes. **D** - I am always aware that we aren't expert cryptographers despite likely fair intuition. **M** - Agreed, we have a good intuition but that doesn't automatically translate into expertise: Let's make sure that the crypto side is safe and doesn't risk things through the VRF and unforeseen security consequenses. => Requesting IOG cryptographer for review, left as 'Last Check' with merging pending review. #### Transaction Message ([PR100](https://github.com/cardano-foundation/CIPs/pull/100) - "Transaction Message") **M** - Same for this PR good to go. It adds a new entry to CIP-0010 plus an accompanying CIP that explains for that purpose/how to use it. It's clear, we run it through a few review already. => Merge now ### Review #### DApp connector ([PR88](https://github.com/cardano-foundation/CIPs/pull/88) - "DApp connector") **F** - The last conversation that we had (last meeting) requested further conversation take place in the PR as per Matthias. **M** - This long-running CIP aims to standardize the way we can have a plugin or addon for wallets - very much like MetaMask for Cardano - that would provide some basic wallet functionalities accross the ecosystem for various DApps. The idea is to get some little core plugin that can provide and hold user credentials and provide dappps with UTXOs addresses and preipheral things like signatures on transactions, prompting the user when necessary. This is quite an important piece in a way and something we are trying to get right, and is also concurrently being implemented in the Nami wallet which is a bit taking the place of a guinea pig in a sense and experiencing first with this particular addon and making improvements as they see need. The last thing in there was actually events to know when the network changes or when you disconnect the addon or things like that - to have events that dapps can register and react to (ex: to adjust UI or other)... That was the last thing discussed. I think the goal for that one is really to come up with an initial foundation that can then be extended. Yt is very much Alonzo-agnostic right now (not touching redeemers, collateral focusing instead on things like Mary wallets, address management and utxos). We've gone through a few iterations already and it is getting into shape, but the discussion is still going on in the PR so not worth discussing here until we have come up with a final draft of sorts: let's first reach a solid draft, ideally before the Alonzo HF, to have a foundation for that and then iterating for the Alonzo features. **D** - Given that this is being done as a collaboration between people involved with two wallets, it is likely a good basis for the proposal. => Tabled for now / until it is ready to be reviewed. (Looking for a more finalized draft) #### HW Wallet signatures ([PR107](https://github.com/cardano-foundation/CIPs/pull/107) - "Restriction on transactions signed by hardware wallets") **Gabriel** - The main purpose of this CIP is to have some specification regarding what is supported by the HW wallet. It was brought up that the Cardano CLI serializes the transactions in a way which isn't really supported by the HW wallets which can result in different hashes (by the HW wallets) and thus leading to invalid signatures. This CIP mainly specifies restrictions on the translation body elements and some other restrictions to be considered **if a transaction is to be signed by a HW wallet**. I'm not sure if there is more to add, open to questions.. **M** - I added some as comments in the PR, more general remarks or concerns, nothing really against this CIP itself because it is mainly highlighting what is currently implemented in the various devices. Just "should something be planned ot be worked on in the future?" This is the current situation, but it might not be the one we want to reach in the end. We should continue discussing in the PR - nothing really against merging this as it's capturing the current limitations. But as a followup I feel we could rework some of them. **G** - The point is to actually reflect the current state, and so as HW wallets are updated we also update the CIP. As noted in some of the responses, such as update to transaction body, as far as I know it was never meant to be supported by HW wallets, and if it ever is required to be supported it can be added + the CIP can be updated (and the same goes for auxilliary scripts) - we have not really dug into Alonzo yet as HW wallet developers - but if it is required to support it then it can be added to HW wallet and this CIP can also be updated. You asked about the number of witnesses that is limited depending on the TX Body or the number of elements in the TX Body. This is already being changed in the multisig or the script update coming to HW wallet. **M** - I think the only points before merging would be the number of Tx elements: it's listed like another similar Tx elements. I think we should make the list completely explicit so there is no ambiguity (even if we have to update it for every era). **G** - Yes, I will do that. **S** - Is there a library where you can give it a Tx and it tells you if it matches those requirements? **G** - We are planning to add this to the Cardanowallet CLI tool. We were thinking of adding an option to transform the Tx in a compatible format, but yes, we can also add an option to just validate the Tx according to the CIP, it would make sense. **S** - Transform would make sense also. Probably folks are adding it in javascript or C ... we probably would want this in a Rust library as well - it would be good if there were some implementations to look at as references. **G** - We will be adding it in Javascript - I'm a bit confused can you explain? **S** - Right now, most wallets use the cardanoserializationlib as part of the rust library. That's what most wallets are using. It would be good if there was a reference implementation so that it can be added to the rust library codebase. **G** - Ok can arrange. Or would the Js implementation be enough? **S** - That would be enough and can be used as reference, webasembly also could but that might not be an option depending on what you folks are trying to do. **D** - Overall this is sensible, enthusiastic about this going into a CIP - it started off about canonical CBOR and is now becoming about interoperability between HW wallets and such - I added a few comments in the PR. => Moved to "Last Check" in two weeks. ### Discussions ### Close => **Merged** as CIP-0020 (Draft) - [PR100 - "Transaction Message"](https://github.com/cardano-foundation/CIPs/pull/100) => "Last Check" - [PR107 - “Collateral key derivation”](https://github.com/cardano-foundation/CIPs/pull/107) - potential 'CIP-0021’ => "Last Check" - [PR102 - “Pool Operator”](https://github.com/cardano-foundation/CIPs/pull/102) - potential 'CIP-0022' (merge pending cryptographer feedback) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft | | 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Draft | | 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-09-07.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [September 7 2021 notes](#september-7-2021-notes) * [Triage](#triage) + [PR102 - “Pool Operator Verification”](#Pool-Operator-Verification) + [PR123 - meeting note naming convention](#Meeting-Notes) * [Last Check](#last-check) + [PR107 / "Restriction on transactions signed by hardware wallets"](#HW-Wallet-signatures) * [Review](#review) * [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 9/7/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## September 7 2021 notes **Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair. ### Triage #### Pool Operator Verification [PR102](https://github.com/cardano-foundation/CIPs/pull/102) - “Pool Operator Verification” **Frederic** - There was a request for cryptographer review and Inigo jumped in. **Duncan** - I agree with Matthias - Inigo seem happy to proceed, will add my tick to this. **Matthias** - I suggested to merge PR102 as 'Active'. **D** - Do you know if the solution that is proposed here notes that the VRF keys can be updated (that they can be updated whenever users re-register) **M** - That's technically a new pool isn't it? So I mean, from the perspective of the CIP, it'll need a new "registration". Updating the VRF would require to go through the "verification process" again. **D** - Not, it's not a change of identity, the hash of your cold key is your identity . The VRF is one of the hot keys. I'll approve but will add a comment in there to clarify. **F** - Do we want to set it up as active as per the comment request? **M** - 102 could be merged as _Active_ **D** - Fine with it as active, if it reflects the reality that's fine by me. **Robert** - Active works. => Merge ASAP #### Meeting Notes [PR123](https://github.com/cardano-foundation/CIPs/pull/123) - changing meeting notes naming convention **D** - Adding green tick. => Merged ### Last Check #### HW Wallet signatures ([PR107](https://github.com/cardano-foundation/CIPs/pull/107) - "Restriction on transactions signed by hardware wallets") **D** - Overall this is sensible, enthusiastic about this going into a CIP - it started off about canonical CBOR and is now becoming about interoperability between HW wallets and such - I added a few comments in the PR. => Merge ASAP ### Review ### Discussions #### Informing devs **Robert** - when CIP items are done, we should aim to quickly call attention to it in the "CIP Corner" in the IOG Marketing newsletter (if people haven't seen it before). **F** - I am working with Lenna Onto from IOG to get a stronger presence in that email wrapup, point taken. #### CIP Statuses **F** - The greater conversation has been about the process for CIPs, for when we bring them onboard the repository,as we bring them as 'Draft' and functionally there should be steps to progress them from 'Draft' to 'Proposed' and onward (you can see the steps in detail in CIP1. From side conversations that have occured with Matthias, he suggests that it might be helpful to rework how the flow currently happens so that the merging in the repository implies some acceptance. I believe Matthias is proposing we leave the PR setup as 'Draft' in itself, (so skip the 'Draft' Status) and rather redefine the merging as an implicit 'Active' or 'Proposed' Status. My personal opinion on this is that this will lead to issues down the line. I see the CIP platform as a place for individuals to jump in and agree/disagree but also harder to do if we were to leave PRs as 'Draft' (and implicitly establishing the merging as 'Active') is that when people discuss they would then be discussing PRs themselves as opposed to CIPs themselves. I feel this would make the conversation more obscure or obtuse. I do feel the Formalism right now might be overkill, but might be very much required down the line. Yes, it would be easier to move everything to 'Active' now but would probably become a hindrance later. **D** - I do not have a strong view on this 'Active' or 'Draft' conversation. Happy to move along either way. **F** - I feel these are important conversations that will come back in the future and that we might be taking shortcuts moving too quickly towards 'Active' for CIPs. On the other hand, there were vocal complaints about the CIP process being too slow. Still the risk (in setting too quickly to 'Active') is that people would be frustrated at observed "non-implementation" (on IO's part). The CIP is an ANCILARY process setup for visibility, not a DECIDING process. I feel that disconnect is there no matter what. And the 'Draft' status emphasizes that distinction. So (when we have a MERGED CIP with a 'Draft' status) we can point at it and tell people that "it is a 'Draft' proposal => it has not been implemented yet and there is no expectation of that happening". Meanwhile an 'Active' status CIP: it should have a colllection of specific adoption criterias that have been observed => Objectively verifiable. And then we can say "ok, it was proposed with those acceptance criteria, we observed them and it should be moved to 'Active'". For a Standard such as the CIP-0025 ("NFT Metadata Standard") maybe the proposed "observable criterias" could be that 'X implementations' follow that format. It's an extra hoop for people to jump through but the formalism might be useful: I feel we need something in-between ('Draft' and 'Active' statuses). I don't know if we have a clear (way) to make this (distinct) enough, so people understand that 'Active means one thing' and that we also have criterias that are objectively verifiyable. **D** - If we don't have consensus on these kinds of process changes, we should probably hold off on those. **R** - I think both views are fine with arguments either way. My Q is "Are the people outside of standards commitees going to have any input regarding the decision for shifting a proposal (from a Draft Status) towards 'Active'?" -> What is the process regarding determining which proposal makes it to active assuming all criterias have been met? **F** - Entirely up to IO - the 'implementer' really (whoever is implementing the proposal) - If we were talking about a wallet standard, then it might be according to whatever wallet implementers might decide. For Example a Wallet Standard CIP could be considered 'Active' if there were 10 wallets that enable it... Or something like that. **R** - So that intiative doesn't go in the CIP process - It applies to the party that is implementing that Standard. **F** - CIPs are not Standards by default, they are formalized suggestions for people to align on. Some of them might be Standards (some others might become standards 'down the line'). There are no Standards commitee, Editors are simply trying to clean things out and curate so the community can have the conversation and decide how they choose to proceed. I feel it would be fair of Matthias to push a PR change, so we can discuss further changes for CIP-0001. I think modifications are needed, but generally speaking there is a significant disconnect between the community's **understanding** of the transition from the conversation phase to the onchain implementation and the actual implementation. ### Close => **Merged** as CIP-0021 (Draft) - [PR107 - “Transaction requirements for interoperability with hardware wallets”](https://github.com/cardano-foundation/CIPs/pull/107) => **Merged** as CIP-0022 (Active) - [PR102 - “Pool operator verification”](https://github.com/cardano-foundation/CIPs/pull/102) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft | | 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft | | 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-09-21.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [September 21 2021 notes](#september-21-2021-notes) * [Triage](#triage) * [Last Check](#last-check) * [Review](#review) * [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 9/21/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## September 21 2021 notes **Attending Editors**: ~Matthias Benkort~, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair. ### Triage **Frederic** - No major items on agenda besides continuing PR88's discussion from last meeting if stable enough. Any items we should look in? **Duncan** - One minor item just filled at the beginning of this meeting ([PR131](https://github.com/cardano-foundation/CIPs/pull/131)), could be added to triage... **Robert** - A discussion that probably should be discussed is that we have had another justification for possibly altering the Cardano URI scheme (CIP 13), and change to a more general URI framework with separate CIPs for separate URI scopes doing particular things. Vicente suggested this back in April and I and others thought it was a good idea then, but had so much with the stakepool and payment links at this time that it was suggested to go with this. As now people are making suggestions for different URI frameworks, I think it might be a good idea to reconsider that suggestion (to break up the URI scheme and pass on one kind of framework document, with this specific documents for the applications) **D** - If there is to be an update to CIP 13, then we should make sure we manage this the right way.. **R** - I haven't conferred with Vicente since, but might have time next month to draft a proposal. (to change CIP 13 and cleans it up and or maybe post a new CIP to the framework itself - whatever makes more sense). **F** - Maybe add this to Discussion as specific PRs.. Any other PRs to discuss? By the way added labels as requested previously by Matthias, hoping that this is helpful, see if changes are needed (Currently Types and stage only). Doesn't seem we have discussion items that should be brought up to 'Triage' or 'Last Check'. [PR131](https://github.com/cardano-foundation/CIPs/pull/131) is adding two metadata labels, 88 and 87, for the Milkomeda chain. Are we fine moving this along? **Sebastien** - Can approve this. => Merged [PR131](https://github.com/cardano-foundation/CIPs/pull/131) ### Last Check ### Review ### Discussions #### DApp connector [PR88](https://github.com/cardano-foundation/CIPs/pull/88) - “DApp connector” **F** - The conversation is currently at 120+ comments, who can summarize the conversation? **S** - I think Rob wrote a summary in the PR conversation... There are so many opinions on this, it is hard to keep track of the parallel discussions, and also hard to keep track of the different opinions on this. I think somebody will have to write a summary of everything, there's just too much going on at this point. We do need to merge this at some point sooner than later, so we can modify these specs for Alonzo functionality. If you try to add Alonzo-specific to this PR, it would never end. This is kinda the problem I think. **F** - Who should do this? **S** - It's hard, nobody has the time. **F** - Everyone seem to agree that this is one of the critical/structural points that can really fulcrum the ecosystem integrations. **S** - Yes. I can say I'll do it but if I do it, but it would be next week at the earliest. **D** - If it's important maybe someone on the IOHK wallet team could be tasked with this. **S** - We need more than just reading and putting comments at this point, more like a project manager to review and setup the clear next steps for this CIP to be locked and merged. If the wallet team can spare a PM.. **D** - If it's important and needs to be done, then it should get done, you shouldn't have to take on the burden all to yourself. **S** - I'll bring it up to Alex (have a meeting tomorrow). **F** - It sounds like I could be involved in there as well, so feel free to involve me. **S** - If you feel you have the time to get involved into this, we could have a developer get into this but it's not necessary as it's mostly summarizing. **F** - I could get involved but it would be for next meeting, not next week, would that be too late? **S** - We'll find someone who can do it right away, there is just so much going on for everybody. **D** - This is an enormous thing. **S** - Non-trivial effort for sure. **D** - On the other hand, it looks like this is so obviously in the interest of the wallet team to implement.. **S** - Will bring it up, and depends how it goes, will try to get it done by next week to have a clear path for this CIP. => Sebastien to speak with IO to get summary/consensus #### Statuses **F** - looking at meeting 29 notes, the last discussion was about CIP statuses and how we progress CIPs through their various statuses. Currently merging a new CIP in the repo, it functionally goes in as 'Draft' but the proposal from Matthias was that the merging could constitute some kind of endorsement of the CIP and it should be merged as 'Active' directly. And so proposed we change the structure a bit. The counter-argument to that is that if we proceed and do that it makes it harder for users to Discuss CIPs themselves, ex: '[the CIP Metadata standard](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025/CIP-0025.md)' was not a CIP until it was technically merged.. Duncan you last mentioned that you preferred holding back unless active concern about the general process, Sebastien no strong opinion. Functionally waiting on a PR from Matthias if we want to change CIP 1 process. #### Labels **F** - We have added labels in the PR panes, you can now distinguish between the updates themselves and the new tentative CIPs, and the associated types(Standards, Informational, Process) as well as 'likely deprecated' (comment: liking the new CIP naming convention that is surfacing in the PRs). There is also the possibility of adding milestones for things, maybe where we might extend and add the statuses of CIPs themselves. **D** - That wouldn't work as well, The milestone feature in Github only covers the code. #### pre-merge CIP conversation **F** - As soon as we merge a new CIP we typically lose the conversation that happened on it outside of the PR itself. For example, [CIP 25](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0025/CIP-0025.md) does not appear to have a direct link to the extended PR conversations. What I propose is that the History header element be updated directly with the PR conversation direct link. so [PR85](https://github.com/cardano-foundation/CIPs/pull/85) (where much conversation took place) can be directly referenced in the CIP itself, so that readers can regress to the conversation easily. **D** - I agree with this, it's sensible to be able to refer to the direct PR or conversation (or see how users got to their ideas while drafting) **S** - If you want to share the link to the PR (conversation), it's like the PR itself. That's also fine (to keep the conversation). #### Update to CIP 13 **R** - I agreed I will work on this in the first time of next month. It should be done one or two ways ( I think logically only two ways) either change [CIP 13](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0013/CIP-0013.md) and dumb it down to a framework, and then add two separate CIPs for stakepools and payment links, creating space as well for the URL scope and the metadata and all the other stuff that has been requested. I however think it would make more sense to deprecate CIP 13 after creating a new CIP for the framework - which Vicente has offered to do, I could do this with him or instead, anyway preferred. And then both the URI payment scheme (that Sebastien and Vicente originally wrote) and the stakepool link scheme need to come along as new CIPs, and should be pretty much rubber-stamped (as copies of CIP 13 content). So basically, create a supplanting 'framework' CIP (deprecating 13), and write two new CIPs (URIs for payment links, URIs for stakepools) which would enable future CIPs for metadata or other extensions down the line. **D** - Can you elaborate as to why we would benefit or the downside? **R** - RIght now you can't suggest any application of a URI in Cardano without modifying CIP 13. So we have a bottleneck. **D** - That would still be true if we were to just split it now.. You would just be extending CIP 13 vs. Adding new CIPs. **R** - It sounds like we might be arguing for the same thing. Very simple framework CIP.. **D** - I mean what do you see as the advantages of doing it the way you're proposing. Trying to get some clarity of what the advantage it. **R** - I think there will be dozens of protocol extensions.. **D** - Supposed we add 'extensions' directly in CIP 13 directly? (as opposed to have them be independent CIPs..) **R** - (my proposition) bypasses the bureaucracy of process (for that one CIP) every time that someone changes anything. It would allow for a very general framework CIP to be mostly untouched, acting as standard that everybody can recognize, while new changes would be submitted as new CIPs (rather than modify the original CIP). We'd end up with dozens of CIPs applying to it, and dozen of authors. Everyone writing a little bit for that protocol, (see [PR130](https://github.com/cardano-foundation/CIPs/pull/130)). There then are questions about accountability and such. I think it makes more sense to have one untouched framework document that stays there and collects some dust while the new protocol changes would come as new CIPs. **D** - It makes sense for Authorship, but it's not clear it's worth it for the number of PRs that would have to be reviewed. Unless we're discussing conflict resolution. **R** - Authorship and the accountability that goes along with it. **D** - OK. **R** - If everyone is in agreement, thanks for flagging. I am looking at [PR130](https://github.com/cardano-foundation/CIPs/pull/130), and there's a thread in the Forums back in April, if there is any suggestion for how, else I will work on this in October and turn to the original PR authors of the Payments URI CIP to see how they want to go. **D** - Seem like a worthwhile pursuit. #### Deprecating PRs **S** - The CKD CIP probably won't happen, wouldn't mind closing the PR. **F** - Crypto 2099 and Tweag.io PRs should probably be closed. Also [PR104](https://github.com/cardano-foundation/CIPs/pull/104). Close or Deprecate. **D** - Deprecated is fine as tag. Maybe closing. The ledger team is thinking about changing the ledger specs for the next HF, and changing how some of those things work - and so to bring back this at some point would have to take into account the new ledger spec etc.. I feel this is pretty much deprecated at this point. ### Close Minor merges Discussions around [PR88](https://github.com/cardano-foundation/CIPs/pull/88) - “DApp connector”: Summary desired for next meeting (IO/CF) Discussions around URI scheme / CIP-0013 and approaches from here (Robert to look more into October) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft | | 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft | | 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-10-05.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [October 5 2021 notes](#october-5-2021-notes) * [Triage](#triage) + [PR136 - UPDATE / adding js usage for CIP-0014](#CIP-14-update) + [PR132 - CORRECTION - adjusting CIP-0003 text](#CIP-3-update) * [Last Check](#last-check) * [Review](#review) + [PR88 - "DApp Connector"](#DApp-Connector) + [PR116 - "Royalty Standard"](#Royalty-Standard) + [PR117 - "Monetary Scripts Serialization format"](#Monetary-Scripts) * [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 10/5/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## October 5 2021 notes **Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. Community Editor Robert Phair. ### Triage #### CIP 14 update [PR136 - UPDATE / adding js impl. for CIP-0014](https://github.com/cardano-foundation/CIPs/pull/136) **Frederic** - This is a minor update to an existing CIP ([CIP-0014 - "Asset fingerprinting"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0014/CIP-0014.md)) that provides a javascript implementation. Describing how to do asset fingerprinting in Js. **Matthias** - Approved. Also good to move towards Active when feasible (but separate conversation). **Duncan** - Where is this located? **M** - NPM link through the NPM site. **Sebstien** - Some background: We originally wrote this reference implementation between me (representing Yoroi) and Ishish (?) from CardanoScan. That is why Yoroi and CardanoScan implement this but most other wallets do not at this point. **D** - OK => Merged [PR136](https://github.com/cardano-foundation/CIPs/pull/136) #### CIP 3 update [PR132 - CORRECTION - adjusting CIP-0003 text](https://github.com/cardano-foundation/CIPs/pull/132) **S** - I think the two changes in this PR are independant: The first is a typo. The second change I have to double check, need to double check the work. It could be indeed correct and needs to be verified. **F** - Tabling this, added to 'Triage' for next meeting, Sebastien or Matthias to look at this to confirm. => Tabled, to 'Triage' (if it gets correctness confirm) [PR132](https://github.com/cardano-foundation/CIPs/pull/132) ### Last Check N/A ### Review #### DApp Connector [PR88 - "DApp Connector"](https://github.com/cardano-foundation/CIPs/pull/88) **F** - This was discussed at the last Editors meeting (#30). Discussion can be reviewed in the [notes](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md) from last meeting. This is the 130+ comments conversation - there was an ask about who might be able to summarize the conversation and how we might be able to move this forward. Has there been some support from IO? Should we go over this PR more carefully right now? **M** - Partly. Most of this CIP has been implemented by the [NAMI wallet](https://namiwallet.io/) I think and the CC wallet is also working on it. As far as I am concerned, it might not be finished/perfect and there might be more changes to this CIP, but I also don't see any reason why we couldn't merge it in as a 'Draft' right now while not finalized. It is mainly about the pre-Alonzo era, and now that Alonzo is here and there are more things with the scripts, those updates will come. I don't feel we need to reach them before this gets merged. Rather I think we should have new conversations about such modifications (in new PRs). **F** - Agree - I think this is a good example of the (Process) conversation we have had previously regarding statuses of CIPs (and here a good use of the 'Draft' Status). PArticularly with the background of a DApp connector concept that would benefit the greater ecosystem when out. **D** - Who is currently implementing this? **M** - At least NANI and CC wallets - so the two lightwallets out there. There is also plan within IO such as with the wallet announced at the summit to also integrate with that CIP and make it sort of ecosystem out of that. **D** - Do those two groups broadly agree with eachothers? **M** - On things that have already been implemented in this CIP, Yes. The discussions ongoing really are about addition of new features or elements, such as event APIs, or to react to a changing network or to a disconnected wallet. Maybe therefore the structure of the CIP could be split a bit and have a core part as the API and extensions that could be supported by this event API, the Alonzo Update... A bit like we did for CIP-1854 with one common foundation and extensions on top, which can be discussed independantly. **D** - If the people who have the current implementations of this agree on it, then it would be fair to set it as a 'Draft' standard. **M** - Maybe we can bring it to the spotlight again, and if people are happy with the current state, then merge and have the conversation on the event API on a separate PR. **D** - Yes, drawing a line would help. Let's add some comments to that effect in this PR. **M** - On it, need to ping the right parties involved, will look into the varied Github handles. I will draft a comment - just gathering the github handles. **S** - I think it's fine. => Moved to 'Last Check' [PR88](https://github.com/cardano-foundation/CIPs/pull/88) #### Royalty Standard [PR116 - "Royalty Standard"](https://github.com/cardano-foundation/CIPs/pull/116) **F** - This tentative CIP looks at establishing a standard for Royalties. This is also an active conversation, and can also be flagged early as an item for the next meeting. **D** - I am unclear as to wether this is a ledger change or if that is built on top of the existing one and is built as a convention. **S** - Convention - Just using Transaction metadata to let people know that "if you are operating an NFT marketplace, please reserve some of this sale to the author of the NFT" **D** - so purely Opt-In? I see. **S** - I think the CIP is fine as-is. There was one comment where I mention that the address is saved and reserved but they could decide to use binary address to save space (in the metadata itself). They were not sure wether or not to do this and haven't responded either way. There is another issue where the percentage field is a decimal value so 0.2 is 20% and I am not sure wether or not 0.2 should be 0.2%. They are suggesting renaming it. **D** - Probably should not be called percent **S** - Suggestion is to rename to make it clear. These are the two issues I see in here. Neither of those have been addressed yet. My understanding is that people have already implemented this. Unless they modify the CIP or respond to the comments soon, we should just merge it because it is already implemented and if they want to change things they can add to the backwards-compatibility. By the same logic we could just merge now and if they want to change the points brought up, can be done post-merge. => Moved to 'Last Check' [PR116](https://github.com/cardano-foundation/CIPs/pull/116) #### Monetary Script [PR117 - "CIP-0029 | Monetary Scripts Serialization format"](https://github.com/cardano-foundation/CIPs/pull/117) **M** - This is intent to put in the same place the CBOR serialization format that is used by Scripts. Phase 1 scripts are the ones that were introduced in the Shelley Era and later extended in Allegra. The binary format is already kinda fixed and documented in the ledger spec repository in a CDDL but there was no documentation of the JSON format. The idea was to document that, but also to make a recap of the rest, and locate in a singular place the CDDL for the binary format. There was an ongoing discussion with Duncan on one of the naming conventions.. I replied to the comment in there: there are visibly two different conventions used between the Cardano API and the ledger specs. I stick with the Cardano API as the most user-facing and what people will likely see, and also used for the JSON format. So i changed (retroactively) the CDDL. It really depends on how you look at the script - Either invalid or valid after (Semantically equivalent) **D** - I would suggest getting the CDDL changes upstream. **M** - Yeah, also, in the repo.. I did double-check the sourcecode and compared... It is a bit confusing in the end. **S** - We want to implement this. We have an implementation already, it just isn't public. We'd like to know if this might be the final piece before we push anything. **M** - The thing is this is one of those PRs that is specifying something that already exists. In retrospect. Something that could have been a CIP first, but now requires synchronization / a coordination spot for the varied implementations out there. It doesn't really change things, it's really a matter of putting on paper what is. It might be the Cardano API has also changed on those regards - I don't think so but maybe it has. Something we could do before merging if we want to move forward. Or actually merge it and do the changes in the Cardano API and bring it back to what they were.. I wrote that PR some months ago, I don't know if the Cardano API has changed in the meantime, I have seen a lot of work being done on the JSON format recently but I think it was mostly on the other parts (UTXOS..) **D** - I don't think it touched the scripts at all. **M** - It would be good to control if this is still the same. **D** - Ask Jordan to Review to make sure it is accurate - I am not aware of any changes in the JSON format. The other stuff cannot change because it is onchain (CBOR, hashing, ..) **M** - If this is fine for everyone I would prefer to move this to 'Last-Check' for next meeting, if it is still capturing the current state of things (will check with Jordan) **D** - Fine with it. => Moved to 'Last Check' [PR117](https://github.com/cardano-foundation/CIPs/pull/117) ### Discussions #### PR118 **M** - Actually dependant on PR112. If [PR112](https://github.com/cardano-foundation/CIPs/pull/112) (tentative CIP 26) doesn't make it there isn't much ground for [PR118](https://github.com/cardano-foundation/CIPs/pull/118) (tentative CIP 28).. #### PR112 **M** - This was touched to in some previous discussion CIP 26 is for finding a way to have offchain metadata that can be verifiable and can have some form of ownership attached to them and still be midly decentralized or not fully centralized. The idea is to have metadata that contains information themselves that makes them verifiable provided the user has some knowledge of some existing keys. Metadata in this context is just an object, which maps fields to values and all values are signed independantly with a set of signature by a set of public keys. The keys by themselves have no particular meaning. So there is a need for another mechanism to identify the owner of the metadata with those keys. This could be an offband communication mechanism (ex: advertizing your keys through your twitter or other, just as ppl do for GPG keys). There are also other mechanisms proposed such as CIP 28 which explains how to link keys and owners: through an onchain publishing which can then be discovered automatically. CIP 26 doesn't go that far, it stops at having metadata assigned by keys (where the keys come from is off-topic). It therefore decribes the structure and signing process: how to generate the signatures, hashes and how to verify. Also to give recommendations on how clients could be consuming this data and how servers could also be implementing this offchain. The idea is not to have one central server but rather **multiple** registries that could be maintained by the community to share all that metadata. One server does not actually provide any authority on the metadata, they are simply access points for the registries, which can then be replicated on any of the other registries in some way. So arguably more decentralized so. It is derived from an original abandoned CIP draft that was written by Michael and Polina some time ago. We made quite a lot of edits along the way as we actually started to implement that and that is the final version that we feel is currently quite complete and also implemented in the Cardano Foundation Registry at the moment. **D** - This is currently accurate with respect to the current [Cardano Token Registry](https://github.com/cardano-foundation/cardano-token-registry)? **M** - Yes, and it covers both the phase 1 monetary script approach that we used before, where the keys used for verification were actually the keys from the policy, which isn't the case for plutus scripts as you don't have the same. For the Plutus scripts, the association between the scripts and the keys needs to happen via some other mechanisms. This CIP puts out some ideas of how that might be achieved, while [PR118 / tentative CIP 28](https://github.com/cardano-foundation/CIPs/pull/118) shows a concrete approach of one such usecase. (Publishing onchain this mapping as part of the minting transaction, which is really just for mentary policy scripts, it doesn't cover a wide variety of Plutus scripts, rather just for the ones that would be minting policies..). I also asked Michael and Polina to have a look at that some time ago: they were happy with the results but only commented on Slack. I will ask them to weigh in directly on the repo to have a record of that. **D** - Sounds good. How long has it been hanging around for / have others had a chance to comment much? **M** - A bit - it was advertised on some platforms. We also discussed it in the Summit actually, with people asking about that and how we would do Plutus metadata. General reactions and comments were mostly emojis. **D** - "so non-controversial" **M** - More hearts, therefore positive. **D** - Let's get more technical architects to comment on this. => Requesting public reviews from MPJ/Polina - moving [PR112](https://github.com/cardano-foundation/CIPs/pull/112) to 'Review' #### CRC **F** - There have been discussions about possibly bringing in 'CRC' (Cardano Requests for Comments) as a category, do you feel this would be worth discussing, do you feel strongly about this? It was previously lightly discussed at the beginning of the CIP Process and at the time dismissed as non-urgent & non-necessary (as CIP as Standard is more or less what people mean by 'CRC'). Ethereum has that system of improvement proposals and request for comments - the most famous being the ERC-20 standard. This is an aspect of the general Cardano Ecosystem that we have put off as non-essential. We have standards, but nothing yet specified as "Cardano REquest for Comments. **S** - This came up many times in the past and confuses folks. Especially now that we have Plutus, people want to standardize their Plutus Smart contracts. This is a possible excuse for this. This is was folks do with Ethereum and ERCs, they standardize smart contracts interfaces. **D** - How is that different from a CIP? **S** - Basically there is no real difference, it's just a different track. **M** - I think it makes sense. **D** - What makes it require a different track, what qualitatively makes it 'needed' rather than having even more new tracks for things like wallets, or ... (Just want to elaborate). WHy should we treat it differently? **S** - The main benefit would be that if you are a Plutus developer you have a specific track to look at, and so when we are reviewing a CIP, you know that you can focus on that area. I think that is the main reason, because the expertise to look at it is different. **M** - It's not that we have been using tracks differently, we don't have a separate process for them. To me they are more like tags or categories. It makes sense for filtering and it makes sense to have another category for this one if we anticipate it to be the home of many future CIPs. I think that in itself justifies the creation of a new track. **D** - But if in practice all that is reflected in / has a different tag and one entry in the metadata and the PR it has a tag on github so you can filter..? **M** - In that sense then we could have one singular track and have varied tags as tracks. **D** - I understand it as a Tag. Searching by what's in flight, is good through Github Tags - I think I am agreeing with you that it's good to have in multiple places. **F** - There will be other meetings to discuss bringing it on this platform, This was lightly touched so people are aware the consideration is taking place, and likely added to next meeting's agenda. ### Close ([PR136](https://github.com/cardano-foundation/CIPs/pull/136) **merged**) [PR132](https://github.com/cardano-foundation/CIPs/pull/132) to 'Triage' (correctness to be reviewed and merged next meeting if adequate) => "Last Check" - [PR88 - “DApp Connector”](https://github.com/cardano-foundation/CIPs/pull/88) - potential 'CIP-0030’ - reasoning is that it is better to have it merged as 'Draft', and have newer conversations from there rather than rtying to summarize from here => "Last Check" - [PR116 - “Royalty Standard”](https://github.com/cardano-foundation/CIPs/pull/116) - potential 'CIP-0027’ - There are format issues to be addressed in the PR => "Last Check" - [PR117 - “Phase-1 Monetary Scripts Serialization”](https://github.com/cardano-foundation/CIPs/pull/117) => "Review" - [PR112 - “Cardano Off-Chain Metadata”](https://github.com/cardano-foundation/CIPs/pull/112) - potential 'CIP-0026’ - to be discussed with Polina and Michael. --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft | | 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft | | 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-10-19.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [October 19 2021 notes](#october-19-2021-notes) * [Triage](#triage) * [Last Check](#last-check) + [PR88 - "DApp Connector"](#DApp-Connector) + [PR116 - "Royalty Standard"](#Royalty-Standard) + [PR117 - "Monetary Scripts Serialization format"](#Monetary-Scripts) * [Review](#review) + [PR112 - "Offchain Metadata"](#offchain-metadata) * [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 10/19/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## October 19 2021 notes **Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson. ~Community Editor Robert Phair.~ guest: HuthS0lo. ### Triage N/A ### Last Check #### DApp Connector [PR88 - "DApp Connector"](https://github.com/cardano-foundation/CIPs/pull/88) **Frederic** - This was discussed at length during Editors meeting [#30](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md) and [#31](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-05.md). It has a lengthy 130+ comments conversation - but we felt it was good enough to merge in, have there been further updates since? **Matthias** - I think we suggested to remove the section about 'events' that was introduced recently with discussion, for the sake of merging what has been discussed and have the conversation about events be brought up in a separate PR/CIP. **Duncan** - I agree - let's merge the bits that are stable and carry on ongoing discussions in their own threads. **F** - About steering: Do we want to override authors in PRs or do we leave it up to the Author? **D** - In the first instance the author aught to decide - but Matthias Recommendation is very sensible: "Guys, get the main part in there, it's fine, and separate off that other piece and we can declare the main part cannon.." **M** - The author is very active/responsive. This was my last message in there because he asked precisely that. **F** - In that case, is this still another 'Last Check', awaiting Rooooob, the PR author to move that section out? **M** - It's on Rooooob indeed, we can make it a bit clearer, but he had a Q about that. **F** - So flagged as 'Last Check' or actually 'Triage', ready to be merged once removal of section, if Rooooob is ok with it merged. Would it be wrong/inappropriate if merged with Events section in however? **M** - No, given that it is a draft, but it would need a disclaimer that it (event bit) hasn't been fully discussed as much as core ideas maybe. **S** - I can ask Roooob to change that section so we can get it merged. If that's all people have problems with we can even have people approve the PR now so that when Rooooob makes his changes I can merge sooner... **D** - Were there any other major changes or things or was this all about the events API? **S** - I don't think so **M** - There was one change that was proposed recently but it was very minor, which can go through a different PR. It was more an additive change. Beyond that, no, pretty stable. => Moved [PR88](https://github.com/cardano-foundation/CIPs/pull/88) to 'Triage' #### Royalty Standard [PR116 - "Standardization of Royalties"](https://github.com/cardano-foundation/CIPs/pull/116) **F** - This tentative CIP is by [HuthS0lo](https://github.com/huths0lo) **HuthS0lo** - 45 days ago, there was a meeting with several community leaders, folks in the CNFT space and the goal was to create a community standard for royalties because the challenges with smartcontracts, they really didn't seem an effective method of creating royalties for the resale of NFTs. We all met and agreed on a standard, which is straightforward, with the goal to make it so that people cannot change out their royalty structure down the line. So we request that their very first token created of of a policy essentially identifies the royalty they are expecting from any asset created out of the same policy - that is functionally it. **D** - For clarity, what can you express in these policies: are they fixed, relative... and they are only 'voluntarily enforced' things by actors correct? **H** - Correct, this is not enforced at the blockchain level, and really meant to be enforced by the various marketplaces like cnft.io, token.io, artano ... Anyone who is active in that space. We expect they will align with the standard. As far as what goes in a policy is really two key things: the percentage expected from a resale and the address it should be sent out to. One of the things that was decided was that we only wanted one single address to prevent undue burden on the marketplaces. ALso there is a minimum ADA per Tx, so subvdivision and such was inconvenient. **D** - So it works as metadata and has to be attached to the very first minting with that policyID... **H** - Correct, your very first mint has to be this token. And the reason for that is so that people can't change it down the road. If we make sure they make it on the very first transaction, then it is very much identifiyable for any transaction that comes after that - plus it's not a major rist on creators: If they mess up their initial minting, then they can just do a brand new mint. **S** - This feels like there is overlap with Matthias's CIP proposed (CIP-0028) **H** - I have to look at it **S** - Besically a way to add to the metadata associated with a mint. They are associating an arbitrary keys so that you can refer to it in the future. My train of thought is that you could use this instead of tying the royalty information to the first mint, you could tie the royalty information to any transaction associated with a specific key... **D** - But the purpose here is to NOT have it modifiyable over time **H** - Correct, there were multiple proposals - the meeting held was by users influential in the CNFT space. One proposal wanted to setup an offnet repository and you could have a metadata tag pointing to that, like a SPO putting his pool info up in the cloud. But that was exactly it, we didn't want ANYBODY to have the ability to change it. You could bad actors that might sell at 0 royalty and later change to 100%... The goal was to protect buyers on the same token and create the ability to have royalties without requiring the extra layer of a smart contract. As long as there is a standard that any marketplace can enforce. **F** - The state of the conversation as understood is as a 'Last Check' are there requested changes? **D** - The extra metadata label as '777' has to be registered with CIP-0010's registry.json and should be done in this PR. **H** - I think someone had asked previously, but I can do that. **M** - We typically bundle those changes together so it is also reflected rightaway in CIP-0010. You had it as a separate PR, this should be in a singular PR. **D** - Change the existing PR so that instead of touching one file it changes multiple files: just add another commit that changes that registry file (CIP-0010) **F** - Also, the file should be in its own subdirectory, and the header is missing from the main markdown file itself, where number/type and such are defined. **H** - Happy to add header + move and touch the other file as needed. **M** - There is a template in the repo you can refer to (or existing CIP) => Moved [PR116](https://github.com/cardano-foundation/CIPs/pull/116) to 'Triage' for next meeting #### Monetary Script [PR117 - "CIP-0029 | Monetary Scripts Serialization format"](https://github.com/cardano-foundation/CIPs/pull/117) **F** - That was setup as a 'Last Check' and was ready to go. **S** - Good to go. **M** - Hasn't changed in a while, good to go. Maybe one thing we could change is the status from 'Draft' and maybe to 'Active'? It's capturing what exist. I don't mind making a second PR but we could also merge it directly (as Active). **F** - Partial to it but it might be worthwhile to have the status transition as a separate conversation. **D** - We have that general issue that we want to move a lot of the 'Draft' ones, so it might be better to deal with that all in one go. => Merge NOW [PR117](https://github.com/cardano-foundation/CIPs/pull/117) ### Review #### Offchain Metadata [PR112 - "Cardano Offchain Metadata"](https://github.com/cardano-foundation/CIPs/pull/112) **M** - I had an extensive chat with Michael, he cowrote most of this CIP and we mostly discussed the changes and additions. I made a couple of edits this morning based on his feedback and this was all discussed with Polina. But not much different from her on the PR. Generally it's pretty much in a state that is ready for 'Last Check': It's completed. I added this morning another 'Well Known' Property (the preimage) which is a very common usecase for the metadata, removed some sections that weren't relevant to that CIP and some rewording. It's a pretty large CIP. => Moved to 'Last Check' [PR112](https://github.com/cardano-foundation/CIPs/pull/112) ### Discussions **F** - Other items that we might want to cover - some CRC conversations, and the advancing of the CIP statuses. **M** - Let's go over the CIPs statuses: It's a question we could solve rapidly. **F** - I'm inclined to take more time to go through them, maybe we can see how far we can go **M** - What was said last time was we could go over a few of the propposals and see if we could advance them - maybe it is faster than anticipated and we can do them all. **M** - OK. [CIP-0002](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0002/CIP-0002.md) the coin selection - this one is implemented at least in the cardano wallet and the NAMI wallet. As far as I've seen they have provided their code opensource which is a javascript implementation of that one and the Cardano wallet has a Haskell implementation of it. It would deserve to be extended with the multiasset concerns which was introduced with Mary. Coin selection approach is very much the same but had to be tweaked a bit because there is no strategy for how to handle the multiassets. At least for the spirit of it (the self-organizing approach) still very much applicable. I think it could be set to 'Active' - I will chat with Jonathan, and maybe see if it is worth doing another new CIP making this one obsolete - it would cover multiassets additionally. I think this would be a good usecase for that - move this one as 'Obsolete' and have a new one that takes over. But in the meantime, it should be 'Active'. **S** - Agree. 'Active' is fine. **F** - Will reach out to Jonathan - Next is CIP-0003. **M** - [CIP-0003 - "Wallet key generation"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0003/CIP-0003.md) is definately active - the CIP was done retroactively and so is exactly what all wallets use today on Cardano to generate keys from recovery phrases and that includes Trezor, Ledger,Yoroi, Cardano wallet, NAMI, daedalus, probably CC wallet, Exodus ... every possible wallet is following that. 100% 'Active'. **F** - While all those changes are proposed directly to the statuses of those CIP it might be worthwhile to have that 2 week lag so folks can weigh in on the change to 'Active' - Pending any objection, 0003 is 'Active' **M** - What do you think about a PR changing the Status to 'Active' and pinging the respective Authors to react/aggree/give feedback? I think that's fair. **S** - That sounds like the faster option. **F** - There will be a PR to change the status, notifying the Author. I'll bundle something when I make the notes and go from that unless someone wants to jump in and change that. **S** - [CIP-0004 - "Wallet Checksums"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0004/CIP-0004.md). For the Wallet checksums, it is active. It's used by Yoroi, CC wallet, and also Flynt. **M** - 'Active' **S** - [CIP-0005 - "Common Bech32 Prefixes"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0005/CIP-0005.md). It's used by everybody. **M** - And is geting extended from time to time with new prefixes and units. Used by CLI and APIs as reference if only for the address prefix. **F** - [CIP-0006 - "Stake pool extended metadata"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/CIP-0006.md). **M** - I think it is used? **S** - Adapools uses it. **M** - I think it was at the time of the ITN and people wanted to have this ITN special 'tag' - I think it's still in use, have seen the pools using extra metadata that isn't part of the initial set? It would be good to confirm with the author maybe - unless 100% sure Sebastien? **S** - I know adapools is using a share model to modify things internally - I don't know if others explorers are using this still. I would assume that pooltool is using it since they contributed to this spec as well. Not sure. **F** - [CIP-0007 - "Curve Pledge Benefit'](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0007/CIP-0007.md) was setup as a 'Draft' to discuss, there has been no change I assume on IO's part. **M** - I think it should be 'Proposed' and not 'Draft' **F** - What is the path towards active for this PR? **M** - I get your point and I don't expect much will happen (to try defining a "path to active"), mostly because this deals with the Core team on the Ledger **F** - Can we suggest to the Author to add to the PR with the proposed path to Active "to have the Core team's implementation"? **M** - But he has no control over the core implementation. It's fair enough to propose it. Maybe a good time to change the status if other things have changed? **S** - [CIP-0008 - "Message Signing"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/CIP-0008.md) - it's implemented by NAMI and Flint. There are quite a few dApps and users using this. Good to change to 'Active' **F** - [CIP-0009 - "Protocol parameters"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0009/CIP-0009.md) this is the initial Shelley Parameters changes and the changes since. I don't know if this was updated since. **M** - There is one PR updating it with the Alonzo parameters and the new parameters introduced in Alonzo genesis. I don't think the parameters are updated that often: There is the d parameter that gets updated each epochs. Kevin is updating and keepingthis up to date aas far as I know. **F** - I thought there would be a CIP for Shelley, one for Alonzo, has this changed since or will we have one giant CIP with all the parameters **M** - I think we said we would have one per era (if relevant). There haven't been new parameters in Mary or Allegra so there was no need for new CIPs. At the same time it's good to have everything in one place, we should look back in the meeting notes. **F** - I believe the PR from Kevin is only for the Alonzo parameters, and last I checked with Keving there were 160+.. **M** - The thing about the Alonzo parameters, you have a dozen main ones or so and then you have the cost models params for Plutus. You could see them as one giant param, as values for individual parameters for each operation, so that takes some space, you don't have the give an extensive description for all of them, they refere to specific machine operations. **F** - Maybe reach back to Kevin on this one wether this should be setup or updated. **M** - For the Shelley one, it's definately 'Active'. Then we have to see what we do with the other PR. **F** - Maybe we should request the Title be properly bounded (and change the title to "Shelley Parameters"). **M** - But then it would be a bit confusing to have two CIPs describing the same thing on different Eras, but at the same time it would be clear. Ideally they would push a CIP BEFORE the HF to discuss the values upfront.. So yea, this one renamed as "Shelley Protocol Parameters" and for the next one have a third CIP. **S** - I agree with the title change but I think the content is fine. **F** - What about the status? **S** - I think Active is fine, as was mentioned, the next CIP would be a new CIP, so fine to leave this one active. ### Close => [PR88 / CIP30 - "Cardano dApp-Wallet Web Bridge"](https://github.com/cardano-foundation/CIPs/pull/88) to 'Triage' => [PR116 / CIP27 - "CNFT Community Royalties Standard"](https://github.com/cardano-foundation/CIPs/pull/116) to 'Triage' => [PR112 / CIP26 - "Cardano Off-Chain Metadata"](https://github.com/cardano-foundation/CIPs/pull/116) to 'Last Check' => **Merged** as CIP-0029 (Draft) - [PR117 - "Phase-1 Monetary Scripts Serialization Formats"](https://github.com/cardano-foundation/CIPs/pull/117) + We went over the 9 first CIPs to review and advance status, will out to Authors regarding to changing the status to either 'Proposed' or 'Active' (If agreed) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/CIP-0001.md) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/CIP-0002.md) | Draft | | 3 | [Wallet key generation](../CIP-0003/CIP-0003.md) | Draft | | 4 | [Wallet Checksums](../CIP-0004/CIP-0004.md) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/CIP-0005.md) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/CIP-0006.md) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/CIP-0007.md) | Draft | | 8 | [Message Signing](../CIP-0008/CIP-0008.md) | Draft | | 9 | [Protocol Parameters](../CIP-0009/CIP-0009.md) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/CIP-0010.md) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/CIP-0011.md) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/CIP-0012.md) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/CIP-0013.md) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/CIP-0014.md) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/CIP-0015.md) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/CIP-0016.md) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/CIP-0017.md) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/CIP-0018.md) | Draft | | 19 | [Cardano Addresses](../CIP-0019/CIP-0019.md) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/CIP-0020.md) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/CIP-0021.md) | Draft | | 22 | [Pool operator verification](../CIP-0022/CIP-0022.md) | Active | | 23 | [Fair Min Fees](../CIP-0023/CIP-0023.md) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/CIP-0024.md) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/CIP-0025.md) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/CIP-0029.md) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/CIP-1852.md) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/CIP-1853.md) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/CIP-1854.md) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/CIP-1855.md) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-11-09.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [November 9 2021 notes](#november-9-2021-notes) * [Triage](#triage) + [PR88 - "DApp Connector"](#DApp-Connector) + [PR116 - "Royalty Standard"](#Royalty-Standard) * [Last Check](#last-check) + [PR112 - "Offchain Metadata"](#offchain-metadata) * [Review](#review) * [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 11/09/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## November 9 2021 notes **Attending Editors**: Matthias Benkort, Duncan Coutts, Sebastien Guillemot, Frederic Johnson, Robert Phair. + guests. ### Triage #### Royalty Standard [PR116 - "Standardization of Royalties"](https://github.com/cardano-foundation/CIPs/pull/116) **Frederic** - This tentative CIP is by [HuthS0lo](https://github.com/huths0lo) **HuthS0lo** - This is a community-based standard based on a conversation started a couple months back prior to the implementation of smart-contracts. We worked together, pooled ideas and met as a group to take decisions on what might be the best implementation for the community and once that got solidified, the PR was finalized. If you look in the PR history, you can see it has changed a lot compared to where it is today - and a lot of that has to do with protecting people around NFTs, and essentially now the marketplaces will only honor the royalties defined in the first transaction - the reason for that is that we don't want people to be swindled at a later time (by changing royalties). By doing that we ensure that people cannot modify the royalties. A lot of significant individuals were involved in those conversations - CNFT.io, Artano... That's how we got to now, happy to discuss specifics, but this should be straightforward: we defined the specific metadata we would be looking for, and again it would be on the very first mint for a policy. **F** - We previously set this as a 'Triage' item, there were minor tweaks requested, but otherwise is it in need of verification? **Matthias** - I noticed something around the address in the metadata - I don't see any reason to add the address in Bech32 encoding since it's something that will end up on the blockchain anyway: it is causing issues because it goes over the 64 bytes length for the address, so I am suggesting here instead to encode the address as plain bytes (since it can be at most 59 bytes and would therefore always fit). That would also get rid of potential problems of having two representations for the metadata.. **H** - I don't have a problem with that per se, but a lot of that is based on the assumption that we wanted this to be simple for people to implement - I don't think the average person will be able to do that (the average person creating a NFT), plus this adds complication for marketplaces who'd have to extrapolate what the address should be. We're looking for simplicity, this is kinda going against the design the group was going for. **Mateja** - Why do we have 'rate' and 'address' as a string and not 'address:percentage'? What is the necessity to have rate and address as strings when we know that they would be key-values pairs / the actual value of the rate? **H** - This is what Clark was talking about - the original design is just two things, the address and the rate, nothing more. **M** - That is what I am saying, put the address on the left side, put the rate on the right side. That's just a suggestion. **M** - That would make sense but then you still have 'too long an address' issue on the key and you would have to account for that. **H** - In the proposal you could do an array if you have an address that extend beyond 64 bytes.. **Matthias** - Looking from the human perspective we want to look at the json and understand, but jspon is meant for machines. People writing metadata will use tooling and libraries to do so. And libraries will do the convertion between Bech32 and Hex and whatever is needed here / whatever is needed. I don't think this makes it much more complicated, however having to worry about two potential different formats for the metadata will add complexity, to check if a string, to recompose the address correctly: There is something wrong with that. **H** - We can't make everybody happy, we've had a lot of people that had oppositions and requests... We meant this to be something that is community driven and voted upon and it is ALREADY being used, there has already been 1000s of tokens. **Mateja** - The standard has not been approved though. Maybe we can touch to why it might be a problem right now: Here, you have to mint a new token as soon as there is a new policy **H** - But that is what you want to do.. **Mateja** - Let's say you want to donate to charity X, then charity Y, and collaborate with Z, then you have multiple policies. Imagine thousands of policies being created on Cardano. Then all the marketplace have to validate all those policies. That they don't know.. **H** - I understand what you are saying but you aren't offering any better solution on the table. **F** - This is a singular proposal and there is room for other proposals with different kind of implementations - any merging does not imply acceptance or endorsement by IO, CF or Emurgo. Is this PR good structure good to go, or are there strong opposition to this being moved along (as it has been discussed multiple times) **Mateja** - There are strong oppositions from Artano and others in the space... **Matthias** - There are no technical problems with using the string here, I don't think it's the right decision to make, because the alternative would simplify a lot of things for tools and applications. **F** - This would only be merging the CIP as a 'Draft' - the conversation can continue then. **M** - There was also a bit about the changelog at the end which I don't think is necessary, could use GIT rather. This is why we use version control and have a lot of the comments in the repo. Maybe rather use better commit messages in the changelog, could use better standardized messages rather than the H2 titles, which would look off in the auto-gen site. **F** - We can continue the conversation once merged, but worth moving this one along as it has been approved by Duncan and Sebastien already. Proceeding. => Merge NOW [PR116](https://github.com/cardano-foundation/CIPs/pull/116) #### DApp Connector [PR88 - "DApp Connector"](https://github.com/cardano-foundation/CIPs/pull/88) **Frederic** - This was discussed at length during prior Editors meeting [#30](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-09-21.md), [#31](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-05.md) and [#32](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-10-19.md). **Rooooooob** - I've recently removed the event API because we figured it was better to do that as a separate change later on. The only outstanding issue is the datasign endpoint. Alessandro and I had a discussion in the PR but have not seen other opinions. Currently in the specs the datasign endpoint is very vague, so we are thinking of making it a lot simpler, where it would use the CIP-0008 message signing spec but would use it in a very simplified way: the wallet would take the payload and construct cost-compliant objects from that. It seems Alessandro and I are on the same page, if no opposing opinions would assume that it would be fine to merge it in. **F** - Might be better in a separate PR? **R** - What is currently in the PR is not well defined for endpoint. Since no one else has had an opinion in the conv. & Alessandro and I are on the same page about it (and came up with a well defined change about it) would you recommend we take out the endpoint bit as a separate PR? **F** - I think we could merge this PR as 'Draft' and have a separate PR for signdata endpoint. **Matthias** - As a suggestion, just before merging leave a note in the endpoint section stating that "this section is currently being worked on (and should be updated in an upcoming PR)" and bring the conversation in that PR. I am still catching up to this conversations but it doesn't preclude this PR being merged as it is. **Sebastien** - I would like to merge this sooner than later, because there are changes we will have to make for Alonzo, for the events (ex NAMI supports events) but that should be its own discussion. We still have to discuss how to allow websites to ask the user Which DApp connector they want to use... We did some of it where we added the name and logo inside the injected data, but this isn't in the injected data, which doesn't help much the website get all the logos and names. **R** - Don't they already have acccess to the information they need? Sure you could add some library on top of that that the DApp could use.. But couldn't they just inject the cardano object (and have the list of all names and data..)? **S** - No because every wallet will override the entire cardano object. Right now NAMI override the Cardano Object. **R** - I thought they would just insert a field? **M** - There was the question of namespacing it at some point... **R** - But that's already namespaced in the Spec, it's been in there for quite a while, this change was done months ago. **S** - I don't know people implementing this, but I can try to force people to move to this. **R** - The current Yoroi implementation has moved to this at the very least, I am not sure about any other implementation like NAMI or other, I'll have to take a look at that. **S** - I can tell you for a fact that they (NAMI?) are just overriding. **M** - I see, it's mentionned in the initial API Intro that states that the wallet has to use their wallet name as a namespace, but then the API is given as wallet.enable, wallet.whatever.. Which is not really clear that this has to be the wallet name and not the **word** wallet.. Perhaps we could use curly braces around the word to show that it's templated? **S** - Point being is that we should have these other discussions in separate PRs, and would prefer this be merged today. **F** - Thanks for adjusting the dir structure, and adding checks in the PR to move this forward. Once we have the 3 signoffs this should be good to go, and conversations can reference this PR if needs be (notably for the discussion in the PR itself) => Merge NOW [PR88](https://github.com/cardano-foundation/CIPs/pull/88) ### Last Check #### Offchain Metadata [PR112 - "Cardano Offchain Metadata"](https://github.com/cardano-foundation/CIPs/pull/112) **M** - Nothing has changed since last few weeks and it was discussed with Michael (Peyton-Jones). We had a few iterations and removed some sections that were redundant. It hasn't changed in a month or so. **F** - Any objection to merging, else this will be merged. => Merge ASAP [PR112](https://github.com/cardano-foundation/CIPs/pull/112) ### Review ### Discussions #### Alternate CNFT Royalty format **F** - Mateja can you elaborate on the disconnect or distinction with the prior [PR116 - "Standardization of Royalties"](https://github.com/cardano-foundation/CIPs/pull/116)? **Mateja** - What our problem is right now is that the space is sortof skewed towards big (NFT) collections, the "10k's" and similar. What that doesn't account for is the '1-of-1' artists, who want to make unique pieces. For example we have artists who are going to sell for 10s of thousands of dollars one piece, and they don't want to have to scroll through 100000s policies just to find the right royalty they want to put on this NFT. There's a signature for the artist and a royalty policy dealing with funding. We want to find a way to decouple the artist signature and the royalties/policyID somehow. It's also burning the approval process, so if you have more policyIDs just for the sake of creating royalties, you will have more problems with marketplaces like CNFT.io: they need the policyID in order to prove specific projects.. So if you have more '1-of-1's which Artano will bring for sure (we have already 200+ NFTs in one collection, with 70 artists and each artist wants their own policy, which isn't a problem, but likely doesn't scale, and THAT is our problem. I understand that there is a skew towards not burning, the UTXO issues, and having the least text attached to the NFT itself... There might be better way to solve this but right now as we see it, the current prior PR linked is an overkill, and favors having one policy for many NFTs, which is not necessarily desireable for every creator. **Sandeep** - Let me add: the current CIP since the address is specified in the policy level, it makes it difficult to use skipaddress, our smart contracst, because the first token that we mint on that policy already requires the address which means we don't have flexibility to have more. The issue is with the smart-contract: we need to have a script address or a smart-contract address **before** we mint any of the NFTs, because according to this (CIP) standard, the first one that is minted is the royalty token, which needs an address, and all tokens minted afterwards and keys, will all use that royalty address. That means the tokens that are minted afterwards, we don't have any flexibility to have this logic incorporated in the smart contract specified in the policy itself. Because the smart-contract for the royalties has to be already created, at least we would need the script hash to obtain an address. It does not give up the flexibility to define the royalty logic for (individual) NFTs which is not good when you are doing collaborations, like in our case in ARTano. Let's say we are doing a collection with 10 artists. For each artists, we'd want to transfer different NFTs, so royalties for different policies. Whoever is the owner of that particular NFT. We could create different royalty policies for each individually, but I think it would be cumbersome / not flexible. What would be a common ground? We could specify the same metadata that is specified in the royalty token. We could put that also in the NFT yourself and give precedent to the royalty that is present in the NFT over the policy. It could be something like "If there is metadata present in the NFT, then it takes precedent - else it defaults to the policy metadata" - it could also work regarding smart-contract because we don't have to know, we don't have to define the logic for the royalty smart-contract before we mint any token. To me that doesn't make sense. Regarding updating metadata, this is NFT the one you want, we don't mint it anymore. I don't understand the part about overriding the metadata. That was one of the arguments in the previous CIP in a previous meeting, when we were talking about the royalties, we were noting the metadata could be overwritten as NFT. And because everything is in the blockchain we could always check what it was at that time. In short, we would prefer having individual level granularity control rather than covering groups, so that when you see the policy in the blockchain, you can see all the NFTs associated with that artist, which makes more sense in our view rather than have a growing number of policies. **F** - Thanks for the explanation, it sounds as though you have a valid (new) proposal emerging. Any other opinions that should be surfaced? **Duncan** - I don't have a strong opinion, but if people have different usecases and different solutions, it is perfectly fine to have different CIPs with different purposes, one optimized for people doing large NFT collections, and a different approach for smaller collections. I don't see issues with that. **F** - Is there a PR being in the works for this Sandeep? I saw a forum post linked... **Sandeep** - We don't have a PR yet, can create one and discuss more publicly. **F** - Unless if you prefer to engage more in the forum or elsewhere if wanting to engage with CNFT actors and preferences directly. #### CIP Directory format tweaks **Matthias** - I was pointing at PR125, which is not a CIP per say but a restructuring of the repository per say, which has a few merge conflicts but could be updated if relevant. The idea was to move all the CIP files naming and to update at the same time for the autogen site, which is functionally similar to the github UI and a readme rendering. If we want to proceed, I think we should move this sooner rather than later as the CIP repo is getting more and more traction, people are getting into it. Most folks land on the Github repo page which is fine. If you hit a deadlink you should still find you way back to the CIP github. I can also update the PR to touch all the CIPs that were merged since. **F** - Agreeing in spirit - but I was surprised that more than expected users were actually using cips.cardano.org. The breaking of the site might be something to prevent, but yes it would be in our interest to move the structure of the repo in that way. **M** - What might be a bit tricky is the linking to the prior files that would be renamed (the site should be easy). One way to do would be to preserve the old CIPs and duplicate as readme. And enforce the new format from then on. Then all the new CIPs would be in the new structure. **F** - Want to move this forward for better UX if we can translate that with the site this should be good. **M** - Not afraid of the website, it's more about the linking directly into github. **F** - Do you mean people referencing the markdown file in Github? As opposed to what? **M** - Right, then you can just link directly to the repository subdir rather than the file itself. and the markdown would render still. This (minor PR) is the kind of PR that is difficult to maintain because it changes as soon as someone pushes a new PR, so if we're ok to proceed, I will update and we should try to merge it ASAP and if not ok I can close and we stay with current structure. **D** - I think the idea is fine, breaking links is not a major issue either way. #### Looking for Community involvement **F** - Also wanted to flag that we are looking for people from the community to join and participate in the CIP Editorial process - Come join, promote, help curate and help surface transparency, facilitate conversation on forums etc... We do not yet have an onboarding process to editorship, but this effort is intently neutral, and your stepping up is very much welcome. **D** - On that note, I will be stepping down for a few months (from CIP Editorship), so this meeting will be my last meeting for a while. I will ask for individuals from IOHK to step up - yet the general point is quite true. #### CNFT and royalties **Clark** - I (and people that I have been talking to) want to express some concerns regarding the current CIP here (27) where they say it's a bit inflexible and one of the things that it is inflexible about is that under the same PolicyID the artist can configure different settings of their royalties for each token for example by just that alone and forcing to mint a new policyID where some artist has some opinion that a single PolicyID acts as signature, that's why some projects choose to collaborate and just stick to one, and also keep up single policyID open to mint more of their art - In summary, this current CIP does not support those usecases at all. **F** - a new proposed standard might be a good path to cater to those usecases. **HuthS0lo** - To your guys point it's by design, it's meant to be inflexible / to protect the buyer - a buyer has the right to know what they are getting into when they buy a NFT - with apps implementing CIP-0027, buyers are protected from changing policies post-purchase. It's meant to be inflexible and immutabe. It's not going to make everybody happy. **C** - I agree with the immutability and the not screwing ppl over but I think that NFT projects have this concept.. for example some artist leaves the policyID unlocked meaning that users buying this NFT trust this Artist to not duplicate their work or other weird stuff. If that's valid then why bring it up to the user of the NFT? **H** - We can allow it for one person but not for multiple ppl that migth use it for nefarious uses, that is the whole point. We did not have royalties prior to this. **C** - If someone changes their royalty from 1% to the 100%, the user can see the change and (that user) was duped.. **H** - I'm confused, not sure what you want. **F** - (Suggest the forum be used to elaborate and go into its own proposal). ### Close => **Merged** as CIP-0030 (Draft) - [PR88 / CIP30 - "Cardano dApp-Wallet Web Bridge"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030) => **Merged** as CIP-0027 (Draft) - [PR116 / CIP27 - "CNFT Community Royalties Standard"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0027) => Merge ASAP (needs 1 more editor approval on PR) [PR112 / CIP26 - "Cardano Off-Chain Metadata"](https://github.com/cardano-foundation/CIPs/pull/112) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Draft | | 3 | [Wallet key generation](../CIP-0003/) | Draft | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Draft | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Draft | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-11-23.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [November 23 2021 notes](#november-23-2021-notes) * [Triage](#triage) + [PR147 - adding metadata labels (to CIP-0010)](#labels) + [PR152 - moving CIP 7 to 'Proposed'](#cip7) + [PR112 - CIP-0026 | "Cardano Offchain Metadata"](#cip26) * [Last Check](#last-check) * [Review](#review) + [PR137 - "On-Chain Token Metadata Standard" (tentative CIP-0031)](#cip31) + [PR148 - Update to CIP 30 (signData API)](#cip30) + [PR150 - modification to CIP 19](#cip19) * [Discussions](#discussions) + [PR130 - Updates to CIP 13](#cip13) + [PR140 - "Protocol Parameters (Alonzo)"](#alonzo-parameters) * [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 11/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## November 23 2021 notes **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. ### Triage #### Labels [PR147 - adding metadata labels (to CIP-0010)](https://github.com/cardano-foundation/CIPs/pull/147) **Frederic** - It seems we gathered all the green ticks (approvals) for this to be merged **Matthias** - This raised an internal consideration here - should we be requiring more information from people adding labels to this? Because a lot of those are modifying this registry, but giving no actual justification or rationale for it. While at the moment there is no abuse, everyone appears to have an actual project behind the request, but should we start thinking of something a bit more standardized, asking what the project, background or reasoning, including some way of verifying they are indeed related to a particular project and so on. **F** - I think this is an issue we have with the Cardano Foundation's Token Registry, where there is leniency but likely a need for enhanced verification. A Registree registring with a Registror (in this case the CIP repo) has an expectation that there is some criteria of acceptance/validation that was passed: a modicum of validation? **M** - Yes. Not asking for a KYC or extended thing - but maybe ask the Author to provide some background behind that specific label and why it is being added, to filter out a bit.... So far no abuse so not a big deal **F** - Defining a threshold of Validation: Checking that the site exists or something like that? **M** - Yes, that's what I did for CardanoHub, Looked around, checked the Github and the user account seems legit. A weak verification still? **F** - As long as it gathers the approval of 3 editors this should be fine: we serve as the filtering mechanism. Hopefully flags get raised for dubious projects. **M** - OK => Merge NOW [PR147](https://github.com/cardano-foundation/CIPs/pull/147) #### CIP7 [PR152 - moving CIP 7 to 'Proposed'] **F** - This was proposed by Shawn as a CIP and he has pushed to move it to 'Proposed'. This prompted a concurrent conversation, the need for a "Path to Proposed" to be added in CIP 1. I would be inclined to merge this one as-is. We've had a conversation with Shawn and he agreed that a way towards active would be to have IOHK or whatever implemented have this, still in the current setup it would formally be better if there was a defined section in there as "Path to Active". **M** - I agree. It might also be a good time to do a second round of calls within IOG asking people to look again at this CIP and maybe give a clear answer on wether or not this will be implemented. It's fine to merge. That's part of the conversations we had a few meetings ago. I do think any CIP merged in the repository should have a status 'Proposed' (rather than 'Draft') as that's close to what the merge is conveying in a way, as "accepted by the editors". Maybe not in a final state. But it should have a "Path to Active" that clearly describes how that CIP would be considered active. There might be some exceptions such as CIP 30, where there are still points under discussion in new PRs, which would still have it be a 'Draft', because there are additions and people know they still want to make modifications. Short story: I agree to move this one to 'Proposed'. => Merge NOW [PR152](https://github.com/cardano-foundation/CIPs/pull/152) #### CIP26 [PR112 - "Cardano Offchain Metadata"](https://github.com/cardano-foundation/CIPs/pull/112) **F** - Needs one more review for this to be merged. **M** - Duncan has approved, we set it up to two mandatory so we could go ahead as I am the author. => Merge NOW [PR112](https://github.com/cardano-foundation/CIPs/pull/112) ### Last Check ### Review #### CIP31 [PR137 - "On-Chain Token Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/137) **M** - This is a follow on from the prior meetings discussions, by Matt Ho from SundaeSwap. **F** - Seems we're all new to this. **Sebastien** - I think it's fairly straightforward, it's just the registry but onchain instead. The core concept is nothing difficult. **M** - It's more almost a philosophical concept at this point: "Should you put metadata onchain or not?" We discussed it previously, the pros is that it's readily accessible if you're monitoring the chain, and the dev experience is a bit easier. The cons is that you make the whole blockchain bigger for storing data that in the end has no reason to be there (The blockchain making for a very poor database) So instead of storing the metadata onchain, it might be considered better to push a hash of the metadata onchain to precisely avoid putting metadata onchain. At the same time we don't prevent people from doing it - and if they really want to do that - at least it's good that they have comments turned off for doing it. It's also very similar to that other proposal for NFT - CIP-0025. And this one looks like an interation on top of that one, which makes it slightly more generic, to expand beyond NFTs, for broader metadata and at the same time still covering things like names, image, url... etc. **S** - This is also similar to the pool, which also had. This CIP tries to referate a website for authentication, making an effort to tie the metadata to the person that authored it. **F** - Regarding the Structure of this CIP, do you see anything wrong - should we push it out to next meeting to review? **M** - One thing that is actually missing is the rationale, which is esssential. Why is this a good idea and why would you do that? I can understand it and imagine, but maybe I would like to have a rebuttal for the cons (why it's ok to put all this data onchain.. etc) **F** - The motivation can serve as rationale if you look at it that way, It's similar. **M** - Similar but not the same thing. Motivation is why you write the CIP and the rationale is why the way that it is solved is ok (and why the decisions make sense in here). It could also be worth discussing CIP-0025 since they come ater, should it be reconciliated as one, coexist..? **F** - CIP-0025 is the NFT Standard they weren't aligned with a few meetings ago. **M** - And we've more or less already had that discussion about the on-chain or not conversation. If we take back the last comments from the CIP-0025 we can see all the suggestions we made at that time that are still likely applicable for this new PR. We had quite a few remarks on how to structure things, WHy putting things onchain was good or bad, and some suggestions such as "as for the schema" maybe use something more standard like a json schema (as could be found on schema.org) and how this references many things as schema, such as if you were an organization, here are all the fields and or references or semantics, types... Everything we said in there still applies to this one as well. If this is going to become a thing to have metadata onchain, let's try to have a very general approach and say "you have to pick one of the schemas that is in there" and have clear rules on what should and shouldn't be onchain. At the same time, you can also just hash it, put the hash onchain and a URL to that Hash and that's it... Then you avoid having to store onchain all of that data and you can still have the benefits. More complicated to update it, but that was the same problem with stakepool metadata. That was the spirit.Maybe someone else can comment. **F** - I see your point about not trying to store things on the chain but I feel it might be fine to have those as concurrent (yet opposed) CIPs and have that conversation on wether to merge or distinguish them at a later time: Enable people to see that there are different options and maybe speak up about that discussion. **S** - Personally I am in favor of making it easier of using Cardano as a Data Dump, and not have to jump through hoops to dump data on Cardano. And therefore am in favor of this CIP. I would prefer if we had an easier way to do this rather than Tx metadata, but it's what we have. **M** - For this PR, I'll comment in there asking for a clear rationale, I don't mind per say if this is merged, just "slightly" opposed. If folks are going to dump data on the blockchain let's make it in an organized way. Still I want a clear note that people have acknowledged the problems (and it mentionned in this CIP) that this is maybe not the best way to approach it and have it compered or noted that it differentiates itself from CIP-0025 and that we also will likely need to have this as a separate json schema that can be referenced and used. **S** - Makes sense. **F** - Moving this to Last Check and should be merged next meeting hopefully. => To 'Last Check' [PR137](https://github.com/cardano-foundation/CIPs/pull/137) #### CIP30 [PR148 - CIP-30 signData API](https://github.com/cardano-foundation/CIPs/pull/148) **F** - This is the continuation of CIP-0030 focusing on the specific section around the signData API, to help focus the comments without having to regress through the 100+ ones on the prior PR. Is this ready for review? **S** - This is kind of a tough one, there are many ways we could go about this. It depends on what people/authors prefer. It kindof runs into some issues with the rust lib as well. Created an issue to address this on the rust side as well. I would not merge this yet, and get people who are using the message signing spec and give feedback on the library and the implememtation and what they think should be changed. **F** - Looks like there has been an extended convo between Rob and Alex. If someone can step in the conversation to give perspective otherwise it will be part of the notes for this meeting and will be tableed towards a review next meeting. => To 'Review' [PR148](https://github.com/cardano-foundation/CIPs/pull/148) #### CIP19 [PR150 - CIP-0019 readability update](https://github.com/cardano-foundation/CIPs/pull/150) **M** - I had a small discussion with Heinrich and he said he would make a few updates on CIP-0019 to clarify the distinction that exists between human-readable addresses and the binary representations of addresses that are one and one thing but two different views of the same thing which wasn't clear from a potential newcomer perspective. ALl those are actually encoding of a binary representation that is simply described by this CIP. He moved one section, the user-facing encoding and clarified a bit that addresses can be encoded by bech32 or base58 depending if they are Shelley or Byron addresses , and that this represents a binary format behind the scene that is described by this CIP. I reviewed the changes and it's good to go for me. **S** - I'm okay with it too. => Merged **NOW** [PR150](https://github.com/cardano-foundation/CIPs/pull/150) ### Discussions #### CIP13 [PR130 - Updates to CIP 13](https://github.com/cardano-foundation/CIPs/pull/130) **F** - Robert who has been vocal about this has raised some considerations in this PR regarding the approach. He was pushing a URI framework CIP, unclear if he has pushed it yet, but the conversation has kept going regarding why we need Deadalus-specific approach. **M** - I think this draft is pretty old now, so we shouldn't spend too much time on this one and I know the team (including myself) are working on a new version for this one that isn't Deadalus-specific that basically extends the URL scheme with some new capabilities which would allow services like Deadalus to work with the PAB and for example partially pass Txs with payloads accross services to another services. I know the update is for "soon" so at this stage, this PR can probably be disregarded until that happens. **F** - This is two months old, and isn't a CIP by itself, just an update to CIP 13? **M** - Yes, but it adds a completely new capability to the link format. Still two months not that old but still old. It's being worked on weekly if not daily, and the team is also working on making it sure and usable within Daedalus. Maybe I can ask Nicolas to comment on the latest update on this one? But this PR is more or less outdated in that respect. I don't know if they will try a new PR or update this one but it will be significantly different. => Likely deprecated in its current form #### Alonzo Parameters [PR140 - Alonzo Protocol Parameters](https://github.com/cardano-foundation/CIPs/pull/140) **F** - CIP 9 was specifically the Shelley Protocol Parameters and that was the conversation of changing this to "Shelley Protocol Parameters" and effectively have a separate CIP for "Alonzo Protocol Parameters". **M** - Name it won't work and it might be worth it as having it as CIP32 (or 28). **F** - Might be worthwhile to reference it in CIP-0009. **M** - Definately cross-reference them. **F** - I think specifically we should make a separate CIP for the protocol parameters for the NetworkIds? We don't have that yet for the specific deployment places for Cardano, it would be good to have that kind of registry available. **M** - a few minor edits to do - change folder, add number, rename as readme... could just push changes on top really (Kevin has given go ahead). => Moved to 'Last Check' for next meeting (pending Edits) #### CIP statuses **F** - CIP-0010 **M** - Should be moved to Active, the registry speaks for itself. **S** - Fine to move to 'Active' **F** - CIP-0011 **S** - Fine to move to 'Active' **M** - Definately, being used by most of the tools. **F** - CIP-0012 **S** - I think this was added by blockfrost and I believe Emurgo also added this **F** - can setup as a Triage item for next meeting => Moved to 'Triage' for next meeting **F** - CIP-0013 - 'Active'? **M** - I would say yes, because some of those links are used I've seem that being used in Yoroi as well for sure **F** - when we were discussed the Proposed status, it might be worth setting it as 'Proposed' with a "path to Active" of (a few services implementing the proposal) **M** - Agree, we are doing that post-fact really => Tabling for now, to triage or 'Last Check' for next meeting **S** - Active is fine, depends on what the Daedalus team thinks. ### Close => Minor Merges (such as [PR147](https://github.com/cardano-foundation/CIPs/pull/147), [PR150](https://github.com/cardano-foundation/CIPs/pull/150) ) => **Merged** as CIP-0026 (Draft) - [PR112 / CIP 26 - "Cardano Offchain Metadata"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0026) => [PR137 - tentative CIP 31 - "On-Chain Token Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/137) to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked) => [PR148 / Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) to 'Review' (will be discussed more intently next meeting) => [PR140 - tentative CIP 28 - Alonzo Protocol Parameters](https://github.com/cardano-foundation/CIPs/pull/140) to 'Last Check' (should be merged in two weeks pending it receives appropriate approvals and structure reworked) CIP Statuses changes: CIP-0007 'Draft' -> 'Proposed' [PR152](https://github.com/cardano-foundation/CIPs/pull/152) & trying to advance existing CIP statuses --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-12-07.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [December 7 2021 notes](#december-7-2021-notes) * [Triage](#triage) + [PR156 - cosmetic edits and JSON rework (CIP 6)](#cip6) + [PR166 - advancing CIP 9, 10 & 11 Status to 'Active'](#statuses) * [Last Check](#last-check) + [PR137 - tentative CIP 31: "On-Chain Token Metadata Standard"](#metadata) + [PR140 - tentative CIP 28: "Protocol Parameters (Alonzo)"](#alonzo) * [Review](#review) + [PR148 - Update to CIP 30 (signData API)](#cip30) * [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 12/7/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## December 7 2021 notes **Attending Editors**: ~Matthias Benkort~, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guest Michael Peyton-Jones(IOG), Mateja (Artano). ### Triage #### 007 **Mateja** - I wanted to reference the [forum post](https://forum.cardano.org/t/cip-007-for-intellectual-property-licensing-legal-documents-inside-nft-metadata/86116) on 007 standard for basically licensing and IPs documents inside of NFTs. **M** - It's just a forum post, it hasn't been written on Github or other - I just wanted to propose a standardization of IPs, basically how we handle art and Licensing. **Frederic** - (Looking at the forum post) - this would propose two options to add, the properly generated json or in the [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) field. Do you feel this could be its own CIP or could it be tacked on to [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025)? **M** - Good Q. It could be linked to [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025). That's also somewhat my question here, if it should be linked. **F** - It matters wether you are the author of [CIP 25](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) or ... **M** - I am not, I beleive Berry (alessandro) is - I can reach out to them and ask. **Sebastien** - I didn't know this blogpost existed until just now. **F** - Let's move this to Triage for the next meeting. => Moved to 'Triage' for upcoming editor meeting 36 #### CIP6 [PR156 - cosmetic edits and JSON rework (CIP 6)](https://github.com/cardano-foundation/CIPs/pull/156) **S** - I think this one was approved by everybody - so we just need to merge it then. => Merged [PR156](https://github.com/cardano-foundation/CIPs/pull/156) #### Statuses [PR166 - advancing CIP 9, 10 & 11 Status to 'Active'](https://github.com/cardano-foundation/CIPs/pull/166) **F** - This is still lacking one approval but should be merged as soon as we get one more Editor approval. => Merged [PR166](https://github.com/cardano-foundation/CIPs/pull/166) ### Last Check #### Metadata [PR137 - tentative CIP 31: "On-Chain Token Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/137) **F** - There were some questions regarding the security of this PR. **MPJ** - I was looking at this and linked it to [PR118](https://github.com/cardano-foundation/CIPs/pull/118) which has some similarities with ?[137](https://github.com/cardano-foundation/CIPs/pull/137) (Matt Ho's? Matthias?) which share similar issues. In particular if we make the assumption that it only works if we mint a token follow a particular pattern: It's fine for those, but then anything that doesn't follow that pattern is effectively attackable, which is pretty problematic. It would likely be very bad to promote something like that if it doesn't work for ALL tokens, because then, for the ones it doesn't work for, we're actually encouraging people to do something insecure. Maybe I should write out my concern in the PR more detailled. **F** - Can you elaborate on the concern? **MPJ** - All of these schemes rely on associating a particular transaction with a particular token, usually the one that minted it or the first one that minted token of that currency or something. But not all tokens have a single minting transaction, certainly it's not the case that all tokens are minted by the party that organized them - there are quite a lot of interesting usecase where they might be created/forged by third-party,the issue is not that it be the norm or not, but rather if we make this here a standard, then for the ones that don't follow this pattern, it might be that someone else might spoof the metadata or tools might get confused (tools having no way to check that this is a "well-behaved version" ...) And the thing that is really lacking is a Discussion around that to begin with: we should think about this hard. It would be bad if we just said "oh btw, no one should ever do something that isn't standard because it might mean your metadata might get spoofed and your users might get attacked" **F** - In the CIP context, could we merge this as 'Draft' and have the conversation continue in the PR thread? (distinguishing between 'Draft' and 'Active') **Sebastien** - I don't think so. **MPJ** - Maybe if it had a security section such as "this proposal requires a security analysis" so that anyone reading it might understand that it comes without proper analysis. Merging this in without it is a bit too suggestive. **S** - It's a strong point. Without addressing it more substantially I don't feel the proposal is complete. So I don't feel merging it (even as 'Draft') is the right option for now. **F** - Should we get Inigo from IO to have a look at it? **MPJ** - The proposer should figure out what they are trying to achieve: I feel what they are proposing is fundamentally unfeasible. The proposer must do some work to explain how they see this working (without it being problematic for the ecosystem) **S** - I agree also that this is not fully solveable, but it should be more explicit about how to handle it, despite the fact it cannot be fully solved, as MPJ notes, it still handles some cases and it's not bad to have a proposal that fits "most" usecases (rather than all). There should be some section covering those aspects, the out-of-band assets that don't match the described creation pattern. **MPJ** - will try to add a longer comment outlining the problem discussed in the PR. => On Hold / Tabled [PR137 - tentative CIP 31: "On-Chain Token Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/137) until further careful consideration take place #### Alonzo [PR140 - tentative CIP 28: "Protocol Parameters (Alonzo)"](https://github.com/cardano-foundation/CIPs/pull/140) **F** - this is the Alonzo protocol parameters from IO, an upgrade continuing on [CIP 9](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) (Shelley Protocol Parameters). This should be good to merge, with two approvals.. Any opposition regarding merging this? **S** - One of the problems with this one is that it is no longer accurate (as of last week) because the parameters were changed again - not sure who wants to handle this as it was changed in the middle of Alonzo (Block size increase). I don't know if we want to modify this here, or merge this and submit another CIP that mentions the size increase. **F** - From speaking with Kevin he was intent on the "Protocol Parameters CIPs" being about the initial potocol parameters, as in the parameters at the beginning of the fork itself, which sounds to me as though this one would be fine to merge as-is: I don't want to have to be chasing for the current parameters continuously afterwards. I would prefer merging it and/or seeing how Matthias feels about it. **S** - I don't think this is a technical decision, more like a "how do we want to structure these CIPs for Protocol Parameters that happen by epoch". Probably in an idea world, we should have merged this earlier and made a change to update it, and in this spirit would merge this as-is.. And then remind ourselves to do a follow-up CIP to this. **F** - Why do we need an update/upgrade CIP? **S** - Because the protocol parameter already changed. **F** - I don't see us as having to keep up with the parameters themselves, just a snapshot of the parameters at the time of the fork. **S** - I disagree, I think the protocol change parameters should have a CIP at least to discuss why changing the protocol parameter makes sense **MPJ** - I think this is a broader conversation (i.e. "Should protocol parameters changes go through a CIP or not?"). => On Hold / tabled for now, will continue conversation offband. (Likely merge and add a new CIP re:change) ### Review #### CIP30 [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) **F** - The singData API update is a continuation of the conversation regarding the signData API for CIP30 which was tabled and doesn't seem to be evolving much. Thoughts? This seemed to be built out by Rob on his own and it seems to have leveled off a few weeks ago. **S** - I need to review this one but haven't had the time. I'm not sure if that will be feasible for next meeting either. For later. => On Hold / Tabled (for next meeting?) [PR148](https://github.com/cardano-foundation/CIPs/pull/148) ### Discussions #### Updates (Looking at the [meeting 34 notes and the discussions](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-11-23.md) there) **S** - Haven't been able to follow up regarding moving [CIP 12](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012) to 'Active' - Blockfrost ppl should be the ones to try to champion this. **F** - About [CIP 13](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) and the conversation.. **S** - Daedalus wanted to make a big change to it and we didn't know about moving to 'Active' in the middle of somebody making a large change.. **F** - Looking at the newer CIPs and the major discussions ongoing then. Potential CIP 31([PR159](https://github.com/cardano-foundation/CIPs/pull/159)) & 32([PR160](https://github.com/cardano-foundation/CIPs/pull/160)) & 33 ([PR161](https://github.com/cardano-foundation/CIPs/pull/161))? **MPJ** - Those three are series of CIPs that build on top of eachothers based on the design work happening. We hope they will alleviate the way some things are currently. **F** - What is the state of the conversation, any salient points? **MPJ** - A bit early - the PRs have been only out for a week, let's see what people say about these. In particular I would like to get the CDDL proposed / pinned down before we merge them **F** - Is that something you're working on through IO? **MPJ** - Yeah, with the Ledger team - I'm not a CDDL expert. I just want to make sure that it looks like for the Tx CDDL to look at. **S** - I commented on that point. The only thing you have to worry abotu the CDDL is that this is run through codegen tools and there's codegen tooling in Go and JS and both are not complete - but people have attempted to make them work. So any complex features would make it harder for the codegen tools to run, and if you don't provide name for fields, they get lost through the codegen process. It's a kind of art to write CDDL that codegens could code but at the end of the day (for the rust codebase) although we use the codegen process without having to work the kinks and end up having to manually fix issues because CDDL is a really bad language for codegen, it's not anything used so not a big deal. **MPJ** - It's not my favorite thing either. **S** - I wanted to talk about (tentative) CIP31/[PR159](https://github.com/cardano-foundation/CIPs/pull/159) the reference input CIP. One thing, the section on Hydra (it would be good to have Matthias sign off on that part - he's the expert here) **MPJ** - There was internal discussion about that, because Hydra makes a bunch of assumption such as the Tx set being a graph, but now it is bit weird, it can be looked at multiple times, what happens when you have conflicts... Certainly before this is implemented I have asked Manuel to talk to the researchers and make sure that the algorithm in charge of resolving double spend inputs would also work for reference spend inputs. I think if we get an ok with that, then it's fine - but we have to be careful about so that we don't accidentally screw up Hydra. **S** - And for the ability to log reference: who we can use reference inputs? Is this something you've seen other people try to do or want to do or is that a thought? **MPJ** - Obviously, you have to be able to lock them to control who spends them. To control who references them, we'd need another script field probably, because you don't want it to be the same one for spending, it's possible in principle, I am a little hazy on clear usecases (and it can be added later), because it would be changes to the change of outputs, in some way othogonal to this, the main usecase I have seen is "someone who wants to have an oracle for people to pay if they look at the data"... I think there is something a little dubious about this because all the info on the blockchain is public in some way and you'd be in some way charging for this and or looking at the authenticity of the data.. I don't know. An earlier draft of this design had some variants of that, where you could reference input, such as a "check" input that would look at if you can spend but without having to spend it. It could be a version of that. The design here is a bit open - a few options in the design space and so am keen to gather more usecases and think about ways we could go there. I think something like that would be rather incompatible with what we have here. I don't think we are blocking ourselves from any approach we take to solve that. **S** - That's an interesting idea, to prove one can spend but won't spend... I can think of a usecase for that if you want to build a sidechain embedded into Cardano: one of the problems we had with that concept is you can't do a rollback because the UTXO is not spent and so we had an idea of building a virtual chain with data inputs and then people can come in and unvirtualize the team after a timeout period to turn it into a real chain if that makes sense. **MPJ** - Sounds quite complicated. For simpler cases, it also lets you prove that you own something. Suppose you have a token and don't need to actually spend it. For example an authorization token, which would let you authenticate, without spending, a minor efficiency saving. A bit like reference inputs in some ways, which lets you avoid churning lots of utxos but appart from that doesn't add that much utility. **S** - It would be useful for the virtual subchain embedded into Cardano because you would then be able to move the subchain states by proving you have the ability to do that but with a rollback it still exists, so you could build a fork.. I'll have to think about wether or not this is actually something worth thinking into. **MPJ** - yeah. **S** - In general for these kinds of "Plutus-related CIPs", do we want to tie these CIPs to changes in the Plutus core specifications, do we want to merge these CIPs and make the spec changes later? I felt for the ledger changes we were somewhat embbedding it into the CIP process. **MPJ** - I was mostly viewing this as a pre-specification document because then there wouldn't be a spec. I don't know. We could broacast a process for that. If you want anyone outside of IOG to make proposed changes to the ledger that's a very high bar, and then it would be reasonable to say you do the full specification set later. In essence since the changes to Plutus are really only in the interface to the ledger, the changes would appear in the ledger specs rather than in the Plutus specifcations. I am considering making a CIP that is a bit like the protocol parameters CIPs that contains the conditions for changes to Plutus and maybe a list of (for ex) a list of all the builtins that are in the current version or so on, to provide a clearer way for those changes to be made... future work. **S** - That would be great. And for the Reference script PR (158), haven't had time to read that one unfortunately. **S** - We should be able to make a decision on the only design points needed for this one (reference spec? PR158?). The problem we have right now is that we are trying to bridge between networks: i.e. Cardano and other chains. And when building bridges you need to build testnet version of the bridges and so need to have some kind of protocol magic to be able to distinguish to which network this is bridging to and we have no standard to represent these protocol magic, so a standard way to represent these would be good to have so it can be embedded in packages and libraries and everything else. Some of the bridging software libraries on the ethereum all seem to reimplement KEIP2 that is linked in the PR and their standard prefixes the improvement proposal for your specific change as a way to do namespacing. In order to have the namespace for Cardano, we need to have an improvement proposal for Cardano that describes the format. **MPJ** - I guess the comment here is: would it be useful to have one CIP for the format and talk about a registry separately? as that would be a semi-centralized registry for this thing. The main thing even just to get started would be to describe that this is the format and how it could start **S** - We had the same discussion for other registries: a few exist in the CIP repo, there's the network registry, there's the chainID registry... I think there's another one and we've not been consistent for the chain registry we use json, for the other ones we embedded into the same CIP... **MPJ** - I guess it's up to you, the format part is likely less controversial. **S** - I'm ok with either options. I think for SLIPs they are all embedded into the CIP as well. I suppose the separate CIPs. Wether we want to cater to colon separators or something else. It's the minor trivial point but something we get to decide and be happy with. If anyone has strong preference in any direction, please make your voice heard. I am leaning toward not using BECH32 and just using a dash (as mentionned in the CIP in its current form). BECH32 feels good, but the checksum is a mistake in my opinion. The other point someone might disagree on would be the inclusion of the Genesis hash, as it was reset some two years ago and might not even matter if it ever happens again. **F** - Send that to next meeting - will add CIP number - 34 should be fine. ### Close => Minor Merges (such as [PR156](https://github.com/cardano-foundation/CIPs/pull/156), [PR166](https://github.com/cardano-foundation/CIPs/pull/166) ) => Extending conversation on [PR140 - tentative CIP 28: "Protocol Parameters (Alonzo)"](https://github.com/cardano-foundation/CIPs/pull/140) => Extending conversation on [PR137 - tentative CIP 31: "On-Chain Token Metadata Standard"](https://github.com/cardano-foundation/CIPs/pull/137) to explore security concerns --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2021-12-21.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [December 21 2021 notes](#december-21-2021-notes) * [Triage](#triage) + [007 forum post on licensing and IP](#licensing) + [PR140 - tentative CIP 28: "Protocol Parameters (Alonzo)"](#alonzo) * [Last Check](#last-check) * [Review](#review) + [PR148 - Update to CIP 30 (signData API)](#cip30) + [PR159 - tentative CIP 31: "Reference Inputs"](#159) + [PR160 - tentative CIP 32: "Inline Datums"](#160) + [PR161 - tentative CIP 33: "Reference scripts"](#161) * [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 12/21/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. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## December 21 2021 notes **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. ### Triage #### Licensing **Frederic** - This [forum post](https://forum.cardano.org/t/cip-007-for-intellectual-property-licensing-legal-documents-inside-nft-metadata/86116) was brought up last meeting as a topic surrounding IP licensing and ppossible approaches, such as tweaking CIP 25 (NFT Metadata Standard) or adding fields - There have been other conversations, this is a reminder to engage preferably on the Forum for now (as there are no PR threads yet). I recall some were concerned on possible vulnerabilities. **Matthias** - I think the idea makes sense generally. But if we are putting documents (or links towards documents) on-chain, then we should also remind people to add that document's hash on-chain next to it - this wouldn't allow updating the license afterwards (unless we think it through various schemes..) but for the purpose here might be sufficient. **F** - Reminder, this is Forum/post level, no PR out yet => weigh-in over there for interest or to support. => no action needed #### Alonzo [PR140 - tentative CIP 28: "Protocol Parameters (Alonzo)"](https://github.com/cardano-foundation/CIPs/pull/140) **F** - This is the Alonzo protocol parameters from IOG/Kevin, an upgrade continuing on [CIP 9](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009) (Shelley Protocol Parameters). Last meeting conversation centered around wether this should be merged or not. The PR has the appropriate number of approvals, but the discussion/holdout was about the parameters themselves having changed since initial Alonzo deploy (ex: increase in BlockSize). Question was should it be merge as-is or changed? My understanding is that this CIP is intent as the "initial" snapshot, and that updates should be pushed as separate CIPs/PRs.. **M** - A few things here, notably echo'd by Mark in the PR, asking if that CIP should be a Standard instead of Informational. The thing is this CIP is currently Informational in the sense that it gives a description of what was chosen for the genesis of Alonzo. If it had come ahead of Alonzo and been discussed, then it should probably have been a Standards track. And this goes with how we want to move the process for parameters, which effectively means defining how things go from discussion to implementation. Which is started with the new Plutus Core changes. For this one, as it is just describing the upgradeable parameters in the Genesis, I don't think we should actually mention the Block parameter update/change. If we do, it could be at a later stage, with maybe a section of all the updates, noting what/when. **F** - It describes "changes that have occured since CIP 9 (Shelley)" but remains vague **M** - Similarly, we updated the parameters for Shelley 'post CIP-0009 publication' and I don't believe we updated that one either. Perhaps we could clarify the message in both CIPs to make it clear values provided might not necessarily reflect the values for the protocol (for both CIPs) i.e. not sure we want to keep track of all the updates in the CIPs themselves - it would be cumbersome to manage over time, rather we have ways to query the parameters and that should be sufficient I imagine. To me the added value of these two CIPs are about providing descriptions and semantics for the parameters themselves: the values (from the CIPs) might be interesting (to get a general idea of magnitude) but should anyway not be used directly in any application. If you write an APP relying on protocol parameters you should properly query them directly from the network, so the CIP here is really 'Informational' in that sense. **Sebastien** - It's not like we should change anything now - it's really the order we pick things for now, so we migth as well stay with informational and maybe in the future switch the order up to properly reflect network params. **F** - This has been a 'Last Check' for 3 or 4 meetings, are we fine merging as-is? **S** - Fine with it. **M** - Same, we can always setup a PR after that to adjust the wording a bit. => Merging NOW [PR140](https://github.com/cardano-foundation/CIPs/pull/140) as CIP-0028 ### Last Check N/A ### Review #### CIP30 [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) **F** - The PR is a continuation of the conversation regarding adding the signData API to [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030). There were some conversations ongoing in this specific PR **S** - The conversation is still active **M** - I think the discussion is mainly regarding the format we want to use for the interface: the approach + the functions everyone is mostly ok with such as the intent, using COSE as a signing envelope. The question so far were more along the line of "what sort of format do we take for address, payload, response?" **F** - Can you expand on what COSE is? **M** - There are two distinct things in CIP-0030 really. For signing you have one thing, which is what wallets do. It was specified in the past and is clear. This PR is more about signing arbitrary payload (not necessarily a TX) it could be about proving your identity with your wallet: some server or app might send you a challenge and if you can prove that you own the private key by signing the challenge in a way that doesn't expose your keys or make your app vulnerable. For example you wouldn't want to accept any random string so you don't accidentally sign an adversarial Tx. So we need a protocol to define how it should be modeled and so we can have a result that is portable, and contains all the information that is needed for the application to verify how it was done, with what key etc.. This PR here is just about the signData endpoint which was left as a Work in Progress when we merged the [CIP-0030]((https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030)) before. **S** - (looking at the PR comments) I think this discussion is still too early to talk about merging here, a lot still in the air. => On Hold / Tabled (depends on activity, check-in next meeting) [PR148](https://github.com/cardano-foundation/CIPs/pull/148) #### 159 [PR159 / potential CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) **S** - For reference inputs, one of the problems we have is that it's really open how far we want to go on this, and we need inputs from companies and people that might want to actually use this, to get their feedback on how far we should go (re: inputs). There are a huge spectrum in this CIP here and scope for inputs. So I am not sure how far that is coming along. On my side I still need to spend more time thinking about different usecases we might want to make sure we consider, what level of functionality. We should get this out in front of people as quickly as possible so they can push out their opinions in the public space/PR. **F** - Conversation is ongoing and still seems to be going on from where it was two weeks ago. MPJ was with us last Editors meeting ([35](https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/2021-12-07.md)) and we touched to it then. This is another one that will likely get carried into the following meeting with the accompanying (potential CIPs) [PR160](https://github.com/cardano-foundation/CIPs/pull/160) & [PR161](https://github.com/cardano-foundation/CIPs/pull/161). **M** - I haven't followed the conversation close enough here - I am familiar with the ideas but not the conversations. Let's move it further out. => On Hold / Tabled (depends on activity, check-in next meeting) #### 160 [PR160 / potential CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) **M** - (Knowing that this CIP really only make sense on top of the previous one) it is "a" way to embed some actual information in the UTXO. At the moment one can't really encode into the hash, because the hash, requires some data that will reduce to that hash. With the idea of reference inputs, you can now think of those Datums as way to embed some level of information. Specially, the datums that you would want to put in that place are much smaller than an actual hash, and so more practical. An example usecase would be oracles: publishing some data onchain, so that it can be refered to by other scripts to leverage the oracle (whatever it might provide, such as price conversion, source of randomness... etc) **F** - Wondering, why aren't those "bundled" CIPs not one major CIP? **M** - That's something that was discussed with MPJ when they first wrote all those CIPs, but since they were quite isolated pieces of change in the end, we thought it made more sense to divide them into 3 different CIPs. The first two are definately related, and 32 requires 31. But CIP 33 is a a CIP on its own: it could exist without the other two, but it's part of the same batch because they are all related, the approaches are similar for 33 and 31 for example. => On Hold / Tabled (depends on activity, check-in next meeting) #### 161 [PR 161 / potential CIP 33: "Reference scripts"](https://github.com/cardano-foundation/CIPs/pull/161) **M** - This PR as (potential) CIP 33 is really to have a way to "import" some code, other validators in your validator: it's a way to reference existing scripts off the blockchain within your script, and that allows you to reduce drastically the size of a transaction because you no longer need to repeat a script every time you want to use it (currently done by embedding it in all TXs it is used). With this proposal, you would put in a reference to a script, so instead of having the full code, you'd have the hash plus some identifier (ex: TxID or other): A pointer to a script basically. This would be one of the most important addition to Plutus and the greater framework for Cardano in my opinion and would be something to pursue. **F** - The direct reference to CIP 31 and 32 is the relying on the reference inputs and the datum for script reference? **M** - No, it's rather a construct on top of that: it's sort of the opposite way of going about it. Similar but opposed to CIP 31 approach: CIP 31 gives you a way to reference inputs, this one here gives you a way to reference outputs (similar train of thoughts) **F** - Still ongoing conversation, please refer to the PR threads to participate. As it kinda functions as a bundle with 31 & 32, will roll this into the following meetings. => On Hold / Tabled (depends on activity, check-in next meeting) ### Discussions #### Network Registry **S** - [PR158 - tentative CIP 34: "Network Registry"](https://github.com/cardano-foundation/CIPs/pull/158) has been open for a month or so and nobody had any objections to the format as it stands it seems. This here describes a standardized way of representing a network in Cardano, such as when saying "My product supports the testnet" => Which testnet? There are multiple.. Currently people refer to them by name or some ad-hoc way of representing it, such as chainID, networkID or a human-readable format, and what we really need is some format that simplifies/lists all the network in Cardano and how specific networks might align with this format. Something that lets you understand the format. Other chains have that kind of registry for their testnets and such, Cardano hadn't needed it due to mostly using only two networks, but over time we are expecting different kinds of networks evolving, so we want to establish some standardized way of referring to Network. Here one of them is a longform json, which includes information, and the other one is kind of a key, so you can use it as a lookup in a registry. This CIP here defines both of those standards, which makes it come with a registry.json, to store future information, and the different networks of Cardano (right now with the two main ones). It also defines a standard for shortform notation, which is CIP34:networkID-networkmagic and this format follows the chain-agnostic improvement proposal that other chains are also following (everyone has essentially aligned to that format). **M** - Makes sense. **S** - There was one alternative where we could have used bech32, but it wouldn't make it readable: no real benefit to it, so I just kept things simple. I also created a json implementation of this CIP as well (that you can find in the CIP itself in the reference implementation section). If no particular objections, I would like to move this to 'Last Check'. **F** - Fine here: a reserve I have is the over-reliance on the CIP repo with all the varied registries being setup. **S** - We probably shouldn't have these registries in the CIP repo, but the other options were awkward (ex: dcSpark maintaining a registry..) This is an endless problem really: nobody wants to be legally responsible for registries (due to exposure and risks) => Moving [PR158](https://github.com/cardano-foundation/CIPs/pull/158) to 'Last Check' for next meeting #### Statuses **F** - Last discussed was [CIP-0012](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012), as 'Draft'. Reminder: it is up to the implementer to champion the drive to advance a CIP status. **F** - [CIP-0013: "Cardano URI Scheme"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013) is currently as 'Draft' -> should it be advanced? **M** - This has been fairly used in a few applications online and if I recall correctly even Yoroi supports it. **S** - Yes. **F** - Sebastien (as co-author for this one) are you fine moving this to 'Active'? **S** - The reason we are waiting on this is that the Daedalus team was about to make changes, and it hasn't happened yet. **M** - It's incoming - but I have no idea when.. There is an internal document, I don't know when the team is planning on making it public but it doesn't really change the core of the CIP, more like adding new constructors for covering DApp-related ULR sharing... A way to leverage the PAB as a URL, or as a partial transaction as URL so that it can be signed in an arbitrary wallet. You could also imagine using that in all the other wallets - for interacting with the PAB. But the other wallets have to be integrated with [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030) .. but that's irrelevant - I might ping Nicolas again. **F** - Fine to leave as 'Draft' for now ### Close => **Merged** as CIP-0028 (Draft) - [PR140 - CIP 28: "Protocol Parameters (Alonzo)"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0028) => Hold on [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) as still active conversation => Continuing discussions for [PR159](https://github.com/cardano-foundation/CIPs/pull/159), [PR160](https://github.com/cardano-foundation/CIPs/pull/160) and [PR161](https://github.com/cardano-foundation/CIPs/pull/161) ("Reference Inputs", "Inline Datums" and "Reference Scripts") => Moving [PR158 / tentative CIP 34: "Network Registry"](https://github.com/cardano-foundation/CIPs/pull/158) to 'Last Check' --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-01-11.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [January 11 2022 notes](#january-11-2022-notes) * [Triage](#triage) + [PR186 - link rework for cips.cardano.org](#autogensite) + [PR148 - Update to CIP 30 (signData API)](#cip30) * [Last Check](#last-check) + [PR158 - tentative CIP 34: "Network Registry"](#network-registry) * [Review](#review) + [PR159 - tentative CIP 31: "Reference Inputs"](#159) + [PR160 - tentative CIP 32: "Inline Datums"](#160) + [PR161 - tentative CIP 33: "Reference Scripts"](#161) * [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 01/11/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## January 11 2022 notes **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guests ### Triage #### AutoGenSite [PR186 - Tweaks for autogen site](https://github.com/cardano-foundation/CIPs/pull/186) **Frederic** - There isn't much to do in there and there is enough approvals already, we should be good to merge pending objections => **Merge** NOW #### CIP30 [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) **F** - This is ongoing (and has been discussed the prior meetings): has there been any major updates since the last time it was discussed. **Matthias** - Not for a few days. We are waiting for Rob to update, likely due to the Christmas lull - Hopefully Rob or Alessandro can follow up: the last point in the discusion was really about the format of the address in this interface, bech32 vs base16 and I see Alessandro commented in favor of bech32 but then we also would need to update the previous CIPs for consistency.. I will comment on that and try to restart/move the discussion forward. **F** - CIP 30 was looking at interactions between dApps and the Chain.. (And this PR here is just the addition of the signData API). (Asking community:) If you agree on one path versus another, add your feedback so the PR author can adjust the proposal (still, can be as new CIPs if others prefer different ways) => On Hold for now ### Last Check #### Network Registry **F** - [PR158](https://github.com/cardano-foundation/CIPs/pull/158) - Tentative CIP 34: "Network Registry" **Sebastien** - This here is because Cardano only has up to 16 values for the networkID which is not enough to represents all possible (Cardano) testnets/ChainIDs of the future (for example, Ethereum has hundreds of testnets/chainIDs). So we need to expand the number of networkID that Cardano supports. We already have a mechanisms that supports it: the protocol magic. Combining both of those into a single value/object that libraries could pass as an object around would benefit everyone (as a machine format item). **F** - Any reasons to delay or open this conversation or could this be merged? (Requiring green ticks..) **M** - Approved. Note that this is the second or third "registry-like" CIP that we setup in this repository. It might be worth highlighting some aspects of Governance in the (registry-like) CIP itself so users know how/when/why things get merged or added to that specific registry. Other questions are around the role of Editors in regard to said "registry-like" CIPs... For this one it is rather unambiguous, but it is not as clear-cut for future ones: What if you are planning to build a network, and you aren't there yet... More of a greater consideration: Who decides what goes into (a) registry? **S** - Good point, but this is likely a higher level discussions regarding the Registries and the CIP repository itself. I wouldn't block this PR itself about it, but it could be a discussion to have 'soon', maybe modifying CIP 1 in some way to highlight how we'd want to handle registries directly. **M** - Either that or explicitly mention it in the CIP itself, it could define and decide how items could be merged or not merged and what the conditions should be - But it has to come from the author of the CIP him/herself, because otherwise we're making our own arguments. It would be better if it is explicitly stated in those CIPs. For future ones, Conditions for inclusion should be explicitly stated in the CIP. => Merge NOW [PR158](https://github.com/cardano-foundation/CIPs/pull/158) as CIP 34 ### Review #### 159 [PR159 / potential CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) **M** - "Reference Inputs" are an extension of the Ledger so we can actually put inputs in a transaction that do not get consumed at the end, and are solely available in the context of scripts. This is useful in multiple scenarios, especially in conjunction with the other two associated PRs (160 & 161) because it can pave the way for 'importing scripts' or additional data without making it unavailable for other scripts: It can make concurrency a bit easier that way because we can share data on the chain and we can turn UTXO as a data source and not just a transfer of value. This here gives all the details on how to do that, what the changes would look like, how a transaction would be modified, what the rationale behind that change is. As I said, I haven't plugged into the discussion and what aspects were focused on lately. I saw MPJ did a poll at the end about one of the features/aspects.. (if we could remove that or not) and people have been weighing in. **F** - Feedback seems to be that "Reference inputs without control is useful but also would be good to have control". **M** - "I don't need it, but I want it" - The question that will follow from that result would be "Can this be done in two steps?" i.e. "Not having control referencing" is easier, can it be introduced afterwards? In a way that could be a separate CIP, or an extension of that one.. **M** - "Controlled referencing" is explained in a later paragraph in that CIP about it (MPJ explains it better). For example an Oracle might want to only allow a transaction to refer to a particular output if some other contract gets paid.. As explained, you make some data available, you might not want to do it for free: you still want to enable some cost, because it cost you something to make that data available. I suspect any Oracle is strongly in favor of that here. Maybe Andre (Knispel) could chip in? If it's feasible as a two step, or other Q. **Maksymilian** - WRT to Oracles being "dead in the water" it is partially true because controlled referencing essentially allows Oracles to work in a similar way that ChainLink does, where you pay for the use of the Oracle and the data is assumed to be correct and up-to-date. Without Controlled referencing (but with Reference inputs) it is possible to have a business model, but then people would be paying to "refresh" the Oracle instead of using it, which I suspect would be cutting into the profits significantly, unless you do some manipulating around - but who knows. In my opinion, this is the most important CIP in context of architectural aspects. **Matthias** - I prefer CIP 33. **Andre** - It is possible to have controlled referencing even with only this proposal, where if you control the script that would use the reference, then you can add a built-in mechanism that would at least control fit us right. Of course anyone can reference an input, but let's say I run some kind of service and I provide the script for interacting with this service, and I also provide the Oracle. Then - in my script - I can require some kind of token that proves that I have access to this input. For some usecases, we don't even need this controlled referencing, to have this kind of usecase supported. **M** - Is it relatively easier/feasible to have that done in two steps? I can definately see a usecase of CIP 31 "without controlled referencing", and that being introduced at a later stage. **A** - The problem with Controlled Referencing is that there are still many questions, notably around what it even means: If I want some kind of control over the referencing, how would I even get it? What would I do? Where would I put the conditions to referencing? We could maybe add a new kind of address, not a spending address but a reference address or something like that, and check if we can reference from that address in the UTXO. Maybe we could do something like that, but then this would be a pretty big change to how we do the things normally. In principle, it's feasible but it's not clear how we would do it and how exactly it should be possible to control the referencing. There is no reason why this couldn't be done in two steps, this CIP isn't super restrictive for future propositions. **S** - One thing to consider is timeline: We have the Babbage Hardfork coming up, but right now I am not sure if it would include reference scripts to an extend. If simplifying this could help include this in Babbage (rather than further out in June), I would be in favor of including this so. **A** - The plan is to include all of it in Babbage and we are pretty much on track. Of course if someone really really wants controlled referenced inputs then I don't know if that can actually be done. **Maksymilian** - I want to say that even if Oracles, like Charli3, want controlled reference inputs, even without control it is still worth it, because the oracles can maintain it themselves, even if it is a static piece of data changed every epoch or something, without neding payment for that because they themselves maintain it.. **F** - CIP 31 is part of the conversation with 32 and 33, should this be rolled into the follow-on meeting as a review item? **Benjamin Hart** - If this were to be accepted with the Controlled References, is it necessarily required that a single release implement the entire proposal? or could it be implemented in phases? **M** - That's what we are discussing: Merging the whole proposal doesn't mean it has to be implemented in one block, especially because in the proposal it is actually already divided in multiple parts. I think it might be better to split it in two proposals - CIP 31a & 31b maybe? So that you can release it and say we have implemented that and not that yet. For a few proposals this already happened, and we've seen that phased rollout, with a later add. If you know that this is going to be implemented in mulitple steps then you could already split the proposal more outwardly. Proposal does not imply any kind of target or future implementation really. => On Hold / tabled (depends on activity, check-in next meeting) #### 160 [PR160 / potential CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) **M** - This one is probably the least controversial of the grouping, and is about the ability to embed directly a datum (that isn't a hash) in the UTXOut. This can be useful with CIP 31 because you can then use the datum part to embed information in a UTXO that you can then cross-reference in a different script, which can then be used in some other flow. The hash is currently 32 bytes long, so it gives you 32 bytes of space available, it wouldn't make the UTXO bigger with that, and the proposal is limiting to that size at this stage, so the idea is not to enable arbitrary size for the datum but rather set it as 32 bytes, so what if you were to put only 2 bytes in there, not hash it, and make it available? You can already do that with padding in some sort - putting 0s in front of that, but the side effect is that you cannot spend that datum afterwards because it would mean you'd have to reveal (..) guess the preimage of that hash. It's useful, but the least discussed of the 3 proposals because it is not controversial and also relatively straightforward to implement compared to the other ones. Without CIP 31, CIP 32 is a lot less useable, or the usecase is less on the table. **S** - For "Inline Datums" I don't mind if it's merged as-is. There is some discussion on the CIP, but none of the proposals require actual change of the file, there is just a small TODO that could be removed, but nothing stops us from merging this PR. **M** - I think it is pretty clear, moving to 'Last Check' is definately fine. => Moved to 'Last Check' #### 161 [PR 161 / potential CIP 33: "Reference scripts"](https://github.com/cardano-foundation/CIPs/pull/161) **M** - I am surprised this one is not more discussed compared to CIP 31. To me, this is **THE** CIP that will make it possible to scale the Plutus Ecosystem in a way. It makes it possible to have a sort of 'module' or 'mechanism' OnChain, as you can import a script, and reference a script from your script.. that reduces the size of your transaction as well, and you can start splitting your scripts or validators into multiple smaller ones, and have more mobility in a way. It makes Plutus more extensible without having to go through hardforks to modify the built-ins and without having to embed your entire codebase in every validator. From a useability or developer experience perspective: this is VERY useful. From a pure capability perspective, it's true that it doesn't give any new capability to the chain (except maybe run bigger scripts than before) and that might be why it's hardly discussed. It's part of the things that will not revolutionize things, but it will make the dev experience much much better. **Andre** - This does (not?) let the scripts reference other scripts directly, it only lets transactions mention scripts that don't have to be included in the Tx but are mentionned in the UTXO via the reference. **M** - And then your validator can insure this particular script gets executed... **Andre** - By doing some extra work it is possible you make these scripts do something.. But it's not like I put some scripts on the chain and then simply call functions.. **M** - Right, It's not Automagic, yet it makes it easier. **F** - Do we need the other ones before moving this one to 'Last Check'? **M** - It's independant, and could have been implemented by reference inputs, but the proposal is not doing that, it is introducing a new component to every transaction output, it's fairly independant. We can move it to 'Last Check'. **Andre** - It's technically independant, but to be useful it needs some kind of referencing mechanism. **S** - I think this is fine for 'Last Check' **Las Safin** - I can tell you about 33 but I have already outlined my thoughts in the chat - this seem to be dependant on 31, but is not quite obvious, in the text it mentions refences inputs. You could implement it without, but it might not make sense: you would have an output and you would consume it. And you could use that script to consume another output that uses that script: It would be very weird, but you could make it independant, although it kinda is dependant. **M** - Eventually we understand you'd use it in conjunction with CIP 31. It doesn't really give you anything in there. You could say that this gets implemented first, then CIP 31 gets implemented later. And that's all this is, we can implement without, despite its use really meant to be used in conjunction with the others. **L** - You want the 3 of them to get the whole power. Can we merge 32 and 33 before 31? Both have no discussion ongoing it seems. **M** - reminder: "Merging something in the Repo" has no implication for implemetation or roadmap or endorsement by implementers! Therefore how these things are implemented, is out of scope of the CIP program. The CIPs are more like a collection of solutions to some problems, they aren't authoritative. We merge proposals that seem fine - If changes need to happen, that can still happen when in 'Draft'. **L** - So how do we reach consensus, for example to implement CIP 32 (as a non-controversial CIP)? **M** - Right now that is up to the Core team. Having a CIP here makes it clear that "This is a Proposed change" and people have time to voice their concerns or support of, then the core team can proceed accordingly (Likely going along the CIP as proposed). As of now the proposal looks legit/feasible. From here should be moved to 'Last Check'.. **M** - If you take a CIP that refers to 'Wallets' for example, users can externally align on varied standards as they desire. For the nodes, right now there is only one implementer (IOG), but there might be other implementers down the line, for example if all parts of the nodes are captured by a set CIPs, then someone wanting to implement a node might look at that collection of CIPs. This is how a new addition to the node, is planned, and IOG wants to open it up and align with the community and have people open on it, such as the feedback on CIP 31, which also allows the team to adjust the scope and the implementation, ahead of the implementation (rather than post-fact). Now we are having the discussion upfront, which is better. **L** - I also want to touch to 33 and it seems there isn't anything to discuss there either: basically things are settling. **S** - re:CIP 33, (just to make sure I get the usecase for combining with reference inputs) If you wanted to combined a shared module, you would create a UTXO entry that is possibly unspendable output, that contains the scripts for your output and then you get people to reference it and that's the main usecase right? **M** - Yes **S** - Fine to merge then, I have approved it and we can move it to 'Last Check' => Moved to 'Last Check' ### Discussions #### Royalties re: [CIP 27 / on NFT royalty](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0027/README.md) **Maksymilian** - This proposal is just a consensus and yes, if a participant is not a malicious actor then it works. **Matthias** - This might be a misunderstanding of the CIP process itself: Someone made a proposal that was merged and it leaves the room open for someone else to come and make a proposal that supplants or deprecates CIP-0027. For my mind if there is a clear disagreement between what this CIP would do? There is room for a different CIP that explains the roles and explains the two different perspectives? **Maksymilian** - That is a good idea. Essentially we / I are creating an NFT platform that wants to ensure that Royalties are "every single time followed." I have designed it, and it is compatible with CIP-0027, it just adds a single field.. **M** - As an editor, I would suggest you push it with the rationale as another proposal, then it would be fine to merge as well (as a separate CIP) **Maksymilian** - I don't fully agree that this solves it - malicious users might still avoid the royalties, and if we as a community come together (if not the solution that I am proposing) then I'd love that. I should make this as a CIP. **M** - Encouraged: highlight the flows and then push a proposal. You might also obsolete or get in touch with the Author of CIP-0027 to figure if worth or desired to add in the changes (rather than have a competing CIP). Over time, it's up to implementers, and the market can decide. #### PR188 [PR188 / Update to CIP-0015, re: Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188) **S** - Currently you only have a choice of delegating to a single person to vote. This here is adding the ability to spread your delegation to multiple addresses. The idea being that being that you might want to delegate to a set of people.. I think the change is not that big and I feel the way they changed the CDDL may be off - but other than that I believe this is what the Catalyst team is already implementing and presumably the reason it is done like this, is due to it being the same format that Jormungandr (Rust-based chain, which powers Catalyst) supports. **F** - I was pushing back on this one re:naming, feedback from the community would be great. Can we move this to 'Review' for next meeting? **S** - I am not sure of the timeline for this one but I wouldn't mind moving this ahead... I don't think the change is that big. => Moved to 'Review' for next meeting ### Close => **Merged** as CIP-0034 (Draft) - [PR158 - CIP 34: "Chain ID Registry"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0034) => Hold on [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) => Hold on [PR159 - tentative CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) as conversation continues => To 'Last Check': [PR160 - tentative CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) => To 'Last Check': [PR161 - tentatice CIP 33: "Reference Scripts"](https://github.com/cardano-foundation/CIPs/pull/161) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 34 | [Chain ID Registry](../CIP-0034/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-01-25.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [January 25 2022 notes](#january-25-2022-notes) * [Triage](#triage) + [PR148 - Update to CIP 30 (signData API)](#cip30) + [PR159 - tentative CIP 31: "Reference Inputs"](#pr159) * [Last Check](#last-check) + [PR160 - tentative CIP 32: "Inline Datums"](#pr160) + [PR161 - tentative CIP 33: "Reference Scripts"](#pr161) * [Review](#review) + [PR188 - Update to CIP-0015, Multi-Delegation](#Multi-Delegation) + [PR183 - Update to CIP30 - Experimental tag](#experimental) * [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 01/25/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ 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. ## January 25 2022 notes **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guests (MPJ, Mark Stopka) ### Triage **Matthias** - (On Process) Michael Peyton-Jones (MPJ) is saying CIP 32 requires attention, but it's already on the agenda. Mark is also suggesting we discuss “delegated voting” instead of particular PR with that. And also the onboarding of new editors… (answering to MPJ chat ask) “Proposed” if there is a ‘past to active’, which is clearly outlined. It should be the case in this. **Michael Peyton-Jones** - So, in that case I should put them as ‘Proposed’? Not clear on what is needed, what to do in terms of the process.. The changes we think we need to CIP 30, 32 are sort of details (how are we going to represent it on the ledger etc… )? My understanding is that you merge things(CIPs) and then add edits to them? I am not really sure what the process is, happy to leave it open… **M** - If you still anticipate few (substantial) updates, probably best to merge it as ‘Draft’ to indicate that it's still being worked on. If rather updates are anticipated to only be simple rewords, merge it as ‘Proposed’. **MPJ** - For 32, Hopefully we can address the comments that came out just straight out. The other two, I think are fine. I'll do a last pass today. **M** In principle once it is ‘Proposed’ you do not really anticipate changes to it, the final design before ‘Active’.Why you are implementing it, you discover new things and then from propose to active there are still changes. **MPJ** - That is basically what's happening. So it's just a question of how we want to represent the current state. #### CIP30 [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) **Frederic** - Jumping into the triage items: First one is PR148, the signData() API. Has that conversation continued? **M** - A bit, Yeah, I saw a few updates and Alessandro also commented on the issue… but it's also now in a state where it needs to be updated. Not much more than last weekend. In terms of progresses. So, the discussion made some progress, but not the CIP per se. **F** - Um, Yeah. PR148 adding signData() API to CPI 30, i.e. “how a DApp would connect to the chain”. If you have strong opinions on this, please do weigh-in on PR148 directly. **M** - Yeah. There was also a discovery by Alesandro last week. I think, regarding the codes assigned to one of the signing methods, they were not matching, between the stake and the library. I think he opened a PR.. Not completely related to CIPs but … **Sebastien** - Yes, We are aware and are looking into this, the repo belongs to Emurgo FYI. => [PR148](https://github.com/cardano-foundation/CIPs/pull/148) being looked into and to be followed on for next meeting (should it be moved to 'Last Check') #### PR159 [PR159 - tentative CIP 31 - "Reference inputs"](https://github.com/cardano-foundation/CIPs/pull/159) **F** - Do we want to extend this? Is the conversation still going on? **MPJ** - I didn't even spend much in the way of substantial additional conversation. Recently. There's one point of contention: The scope of this could be expanded to include an additional feature (which it doesn't currently include). I made some attempt to check community sentiment on that. I think it is something that people care about, but I don't think it's feasible to do the design work and implementation in the timeframe that we'd like to do this in. So I decided to revisit that in future. I don't think there's actually been any discussion that changed the substance of the proposal in a while: fairly settled now. => [PR159](https://github.com/cardano-foundation/CIPs/pull/159) On hold for now, revisit later #### peripherals **M** - (now that we are over with Triage) some peripheral CIP bookkeeping: There were just minor changes and corrections to the existing CIPs: PR195 is adding another reference implementation for the CIP 3 (the master key generation algorithm) from seed to wallet BitBox02 key format. Which also uses this format that is specific to ledger. if we added it to the CIP which is very much welcomed. So we both approved Sebastien, I guess we can merge that. Small update to CIP 30. It's pretty minor change. Also PR193 re: CIP 25 (on NFT metadata): a precision by the author about the asset naming, coding which has to be UTF-8 which does not make me happy yet is approved, because it reflects what it is. I think we can merge this as well. Additionally, we did discuss another small one two meetings ago requesting a clearer “path to active” section in PRs, so we know what the author has planned in order to move their CIPs ‘Active’. (also relevant to MPJ’s earlier Q). **F** - Again, the CIP’s “Proposed” state is intent for when the author (or authors) deem the CIP PR complete and there is a community-verifiable explicit (Editor-approved) path to “Active”: This could be a working implementation (where applicable), or a set of observable metrics on the network, but it should be clearly worded out in the CIP as its own section for all to refer to. **M** - PR182 could be merged also, it is fixing links. ### Last Check #### PR160 [PR160 - tentative CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) **MPJ** - That is the one we discussed earlier. We need to see a bit more activity: it just needs a bit of attention, but I think that's resolvable. Inline Datum is about allowing you to put datums directly in outputs instead of datum hashes. A lot of things are fairly uncontroversial, the only question at the moment, is about how this is represented in the script. So I think there's fairly good reasons to make this distinction visible to scripts because then scripts can assert inline datums to be used. But then the questions become “How exactly do we do that?” in the representation, which is really a detail, and “What do we do for Plutus V1?”. We could do a sort of “backwards-compatible thing” where we pretend that it is in the witness map (which I'm somewhat partial to) or (what we really shouldn't do) just “Omit the information”. To just silently drop the information would be a bad approach. A realistic option would be to effectively ban transactions which contain inline datums. We just do on-script. This wouldn't be so bad, except we create a new way you might make things unspendable, by creating an output via Plutus V1 script and inline datum, because you wouldn't be able to reference that output to itself.. There are already a lot of ways to make things unspendable, better not to add more… **M** - This is something the ledger would catch very easily right? **MPJ** - Not really, you can not catch that. When you create an output, you only have a hash, which does not tell you a version, or a language tag: At output-creation we do not know those.. I think Alex summarized most of that pretty clearly in the PR comments. It's not clear what the best resolution is from here. **M** - Would it be out of the question to introduce new address types for that? **MPJ** - If we are going to change the address types, adding an address type that generically included a language tag, would be reasonable. But I don't really know how much work that would be. It's also somewhat orthogonal to this: We could in principle do that separately. I think you're probably more likely to know the answer to how difficult that might be. **M** - It wouldn't be too complicated probably. **MPJ** - Okay. He doesn't think that solves the problem. The ledger forbids your transaction and transaction creation time. So you wouldn't make a spendable output. **M** - It doesn't completely solve the problem in the sense that you would still have the old addresses available to use. You could migrate to this new addresses and recommend deprecating the old ones into new ones… **MPJ** - I suspect this won't be a problem, but feel bad about introducing a new way to make things unspendable. Not the end of the world, but a better option would be nice. **F** - Ok, that’s setup as a ‘Last Check’ item, tabled for now TBA until the conversation evolves from there. CIP 32 / PR160 moved off from ‘Last Check’ and back on hold depending on the state of conversation. a Triage item for next meeting, depending on the state of conversation. **M** - Let’s not put PR160 on the agenda until we have an update (from MPJ). The discussion might take time, So we can just put that PR on hold and put it back on the agenda when there is an update. => [PR160](https://github.com/cardano-foundation/CIPs/pull/160) Moved off the agenda (and off from 'Last Check') until we have update from MPJ on the conversation (check in on it in a few meetings) #### PR161 [PR161 - tentative CIP 33: "Reference Scripts"](https://github.com/cardano-foundation/CIPs/pull/161) **MPJ** - That's the one we were just talking about. Shouldn’t have substantial changes **M** - Let's merge that one. I suggest moving its status to ‘Proposed’ as soon as we have fleshed out the CDDL (and surfaced the details / path to ‘Active’) **MPJ** - I think for some of these, we could merge them as ‘Proposed’. Stuff like the CDDL, will ultimately come out of the real implementation. I will defer to the Ledger team on what is the right way to do this CDDL.. => Merge NOW ([PR161 as CIP 33: "Reference Scripts"](https://github.com/cardano-foundation/CIPs/pull/161)) ### Review #### Multi-Delegation [PR188 - Update to CIP 15 / Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188) **S** - Last time I talked about this was mostly around backwards compatibility. I haven’t had the chance to check their edits for this yet. There is also a question whether if people are actually going to implement this? Because we're modifying an existing CIP - So we need to know who actually wants to implement this thing. This is something that the Catalyst team is supporting: If nobody wants to support this, it might not be worth changing the CIP. So far, I haven't heard of anybody that wants this change. I think that the voting purpose it's fine. It is not a backwards-compatible change any wallet needs to take care of. Again, It can be used by random folks.. But a change to allow delegating your vote would also be something that should be taken care of, but not sure there are any wallets that signaled that they want this. Maybe someone from the community wants this. Nobody from IOHK will submit this proposal. We need to figure out if they really want this feature. This is my main concern. Obviously from the CIP perspective, It's a valid CIP and it can be varied from that. But the fact that is modifying an existing CIP, it makes it slightly different from merging a new CIP. **M** - Perhaps it's really better to be a separate CIP. Because indeed it seems like a fair extension of an existing one. But it modifies it quite substantially, which could fit better as a separate one.. And it would make it clearer for wallets (or clients) who could then implements CIP 15 “and CIP X” **Mark Stopka** - As far as CIP 15 / Multidelegation goes, I think it is a long awaited feature. If it's going to be a separate CIP or the same CIP, I don't care. The community has been calling for the ability to get Cardano whales who are too lazy to download/vote in the app via Catalyst for quite some time. It is critical. And we would like to have it asap. Maybe by Fund eight (about three months from now). I know it’s suboptimal. When thinking about governance and delegation we've been expecting something completely different… I don't know if there is a plan to use this as a temporary solution, and later implement something more cryptographically sound and less traceable - using some zero snarks, or zero-knowledge proofs or something… **M** - The idea here would be to let people register the set of keys they are delegating their votes to. **Mark** - I have friends that have about 10 million ADA, none of them votes, except for me. So they would be happy to give me their voting power and let me decide, and I buy them yours and I will have much more voting influence to support technical proposals that make sense as opposed to some that don't for example. **S** - From a technical perspective, I have no opposition to the CIP after the modifications. After I read over it, I think it's fine. Still, I think he is probably right. I believe it's better if this is a separate CIP, because it requires explicit support from wallets and backwards compatibility. Make this as a separate CIP and then wallets can choose to support this change. **Mark** - Happy to propose a new CIP. I will setup a CIP to complement this one, add authors, and submit it by the next editor's meeting so we can push it through. **M** - Yeah, that would be better. As for delegation currently, It also changes: there are like two changes in one. Before that there was a single delegation / a single vote. Now it is a list. So in terms of tooling - or for the Catalyst process by itself... **Mark** - Not sure how IO does it, but if I were doing it, I would just scan the chain for all the voting registration certificates. Then make a new genesis for the Jormagandr sidechain that would reflect the respective voting power. **M** - That is exactly what happens. There is a snapshot on a given date that takes all the registrations.. **Mark** - So in this case, you would look for the registration certificates that has multiple staking keys and you would pull those together. That would be a temporary solution. As we roll out Voltaire, I think there would be lots of changes to such a CIP overtime **M** - That sounds fair. Given that Jormagandr supports “multi delegation” in the first place. There is also something to be done there. **Mark** - Multidelegation has been thrown around for about a year: Is it something that is actually coming? As a community we sort of develop the work around with enabling wallets so we'll have multiple accounts. People who want to multi delegate currently split their wallet into multiple accounts and allocates each to different pool… **M** - I don't think there is any plan right now to support that “natively” in the protocol. There is a clear willingness to have (delegated) voting supported by more clients on the line: that's exactly the way this has been done. I think there are at least two other CIPs that are also approaching this question.. **Mark** - I don't think that there are bad intentions, just limited available resources or prioritization, with things like script preferences or other more important things. **M** - Also about complexity: there are features that would add so much complexity as to make the feature itself undesired. Here, the consensus has been that the complexity compared to what it gives, is best handled in the wallet rather than the node. **Mark** - In the ledger rules in the repository. The guys started to update the foremost pack. I think they are expecting this CIP to be approved soon so they can roll on to the chain quite soon. There is a difference between LaTex specs, executable specs and actual code in the HASKELL node but I think that they are at least expecting an early merge… **S** - We are getting off topic right now. We're trying to finalize what to do about updating CIP 15. **Mark** - We agreed that I would submit a new CIP, which would be more specific... I will do it today, tomorrow, and we can then merge it. I will copy the CIP 15, removing what doesn't make sense and refocusing on multi delegation. That way wallets can signal support, for CIP 15 it itself or “15 plus (new one)”. Also I've been hearing from colleagues in American time zones they feel it is difficult for them to participate. So what I was thinking since we have CIP meetings at the every two weeks, what we could do is that we could have one that we'll be better suited for Asia. And one that will be better suited for America. And both of them will be suited for Europe. **F** - Let’s add to the discussion section: We have one more item first though. => Re: [PR188 - Update to CIP 15 / Multi-Delegation](https://github.com/cardano-foundation/CIPs/pull/188) requesting a resubmit **as its own CIP** (rather than modifying existing one) - to review as appropriate #### Experimental [PR183 - Update to CIP30 - Experimental tag](https://github.com/cardano-foundation/CIPs/pull/183) **S** - Right now there are multiple wallets implementing CIP 30: Flint, CCVault, Nami, and others. Now that multiple wallets try to implement this CIP, they are trying to stay aligned on a standard. It makes it hard for DApp authors to know what is supported by “all the wallets” and what is something that's supported by single wallets. At dcSpark, we want to create a website that explicitly lists what can be used for browsers, and which wallets supports what. To effectively do this, we want to be able to mark APIs as “experimental”. That would allow devs to know an API is “experimental”, and devs writing code could focus as needed. We could have a set of stable functions and then the experimental flavors: this PR basically just explicitly adds this experimental field inside the CIP30 data structure. **M** - The difference between the global and the per-wallet namespaces would be exact ‘X’. For features that are “experimental” but agreed upon globally, they would go under “experimental” but a feature for a particular wallet would go under the wallet namespace. **S** - The global and the wallet namespaces are for different reasons: for registration purposes. One of the goals of the dApp connector, was to prevent monopolies ala metamask - basically nobody can compete with metamask because metamask overrides everything: There's no way to specify which wallet you want to connect, It is a mess. So we want to make it easy for wallets to list themselves as supporting CIP 30. The Cardano object at the start has no functions in it, only a list of wallets. Then whenever you use a dApp, if you call ‘enable()’ on a specific wallet, then it injects it into the space. These are two valid separate things. The wallet namespace being experimental is just for meta-information about the wallets. And then the global namespace is for actual functions... **M** - This could be the next version or the extensions of CIP 30, for instance, that are still being worked on as CIPs? (S - “yes”) **F** - So, could this be a standalone CIP, or what is the reason for riding this on top of Rob’s CIP 30? **S** - This is fully backwards-compatible and is currently experimental. It's currently supported by CCvault, Nami and Flint. **F** - Should Rob (PR Author) be pushing this? Is he on board with those changes already? **S** - I will ask him. (Rob works for dcSpark) **M** - It sounds good to me. I've approved. Alessandro seems to be positive about it. **F** - Considering PR183 as ‘Last Check’. Rob is working on this, for experimental APIs. => [PR183](https://github.com/cardano-foundation/CIPs/pull/183) moved to 'Last Check' ### Discussions #### CIP Editors meeting time **F** - Next discussion item is as per Mark: “can we move this meeting so US-based folks can attend more?” **Mark** - We keep seeing bigger and bigger changes coming in: In order to facilitate a global community, as well as enable a bandwidth enabling the amount of changes coming in, and have a proper debate over all of it, I propose that instead of having the (CIP Editor) meeting every two weeks, we have it every week and one be catered more towards Europe and America. And the other one towards Asia and Europe. (Let's set up a mailing list + onboard more editors too..) **M** - The current problem with doing that is that we as editors would have no bandwidth to do it. Scaling the number of editors and people would definitely make the communication harder. Sometimes synchronizing things takes much longer. Re: mailing list, we already have the notes published after each meeting and the actual recorded meetings. Maybe it's more about advertising the notes more than we do? **Mark** - There is a magazine called ADA pools.io... I'm going to try running a monthly retrospective of the CIP process: that would help drive community engagement that way. As far as the coordination for the actual CIP editors, I feel Github is too messy unless we make like one issue where we can have a discussion, I think Github supports discussions, right? So we could move it into the discussion part or in a Wiki part, or somewhere where we can have threads, which won't be cluttered with both technical stuff and the process operational stuff. **M** - That's something we mentioned in the past, indeed. I would really like to give a try to github discussions. I think they are well suited for the CIPs. Especially for discussions that are not necessarily technical, but more like political debates or changing the process, or onboarding new people etc. We discussed that in the past. About onboarding of new people. We have Robert now, but he's also US-based so often halfway to join meetings. Um, but we still haven't defined the formal process for candidating for the editors (currently a majority vote) **Mark** - I see several gaps around the process and I think we should update/review it. The process we currently has just three tracks for the CIPs. **F** - We are very aware that many process areas could be improved.. Can we focus on the timeframe for the meetings (Conversations will get lost a bit otherwise) **M** - Probably why we’d want to have this “GitHub discussion” open. We also have been in the past meetings where we had á list of ideas of things we wanted to change probably in this API. I mean, the process. So one we discussed today was this little thing “path-to-active”. It's still minor thing but something we want to change for others. We don't have enough time in a crowdcast meeting to discuss all, so might be better to have proper discussions written down to discuss and bring them into an actual synchronized conversation. **F** - Every 10 meetings there is an actual retrospective that happens behind the scene. For the sake of making sure that we go through these discussion items as put out in the agenda during regular meetings, it is very condensed. But for the sake of conversation, regarding potential US meetings. It is more a problem of time availability. Matthias and Sebastien have been pulling most of the editorial work. Finding a time that works for Mathias (FR), Sebastien(JP) and myself (TW) with US is really hard.. **Mark** - The question is how big of a quorum do we need to make decisions on CIP meetings? Matthias is in France, so he can cater to US as well. I am in Europe, so I think I can cater to US. And then you have one more person, you mentioned one more who is the new CIP editor based out in the US. So that makes three people. **M** - I don't mind alternating. We can do two things. The thing I just want to confirm is if we want to double the amount of CIP meetings.. **S** - If we want to double the CIP meetings it does not seem reasonable to me at this point of time **M** - And although we do not need to double them. Lets do one meeting in Asia, US and. Europe time zone We can alternate them.. One was a meeting in the US and Europe. And we'd have two meeting amounts. So that means once a month, um, every, everyone goes at least able to speak in a friendly time zone… Otherwise they got to wake up early or wake up late. I think that's a good step in the right direction maybe. **F** - For the sake of consistency, prefer to have the meetings at the same time. It's difficult to juggle. **M** - In a way that would be “at the same time every month”. Maybe we can run a poll to see, and have proposed times, then take the time that has the most votes? And if we see there is clearly a pattern of “two times”, adjust new times.. **S** - I am not sure a mailing lists adds more value, in terms of enabling email notifications from github and considering we are low on resources for managing CIP stuff. I would rather not add what we can not manage. **Mark** - We can tap into the catalyst resources I believe: they have an entire team dedicated to admin stuffcalled QADAO:we should use them. We pay them, we should use them. They have all sorts of different fancy names for doing different stuff… I can reach out to them and we can ask them to provide us with that for doing meeting minutes for example. They already do meeting minutes for the catalyst circle. Circle. Things that are recorded and so on and so forth, so we should be able to tap into these resources. And they already have some automated AI based tools for transcription. **M** - I would actually do nothing more than publication of weekly notes. If someone wants to build a mailing list on top of the CIPs, or adding things to ADAPools as you suggested, that would bel welcome, but adding this to our busy schedule is too much. #### growing editor panel **F** - At this point, we're also looking at adding more people to the editorial board. If you are interested please reach out to either Sebastien, myself or Matthias via email or social media. ### Close => **Merged** as CIP-0033 (Draft) - [PR161 - CIP 33: "Reference Scripts"](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0033) => Merged minor changes to CIP 15 - [PR183 - Updates to CIP 15 / Experimental Tag](https://github.com/cardano-foundation/CIPs/pull/183) => Hold on [PR159 - tentative CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) as conversation continues => Hold on [PR160 - Potential CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) - will be revisited as needed => Hold on [PR148 - update to CIP 30 / api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) (to Triage again!) --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 33 | [Reference Scripts](../CIP-0033/) | Draft | | 34 | [Chain ID Registry](../CIP-0034/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-02-15.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [February 15 2022 notes](#february-15-2022-notes) * [Triage](#triage) + [PR136 - metadata onchain standard ](#pr136) + [PR153 - moving CIP 23 status to 'Proposed'](#pr153) + [PR157](#pr157) * [Last Check](#last-check) + [PR148 - Update to CIP 30 (signData API)](#pr148) * [Review](#review) + [PR159 - tentative CIP 31: "Reference Inputs"](#pr159) + [PR160 - tentative CIP 32: "Inline Datums"](#pr160) + [PR163 - Tentative CIP: "Dynamic Saturation based on Pledge"](#pr163) * [Discussions](#discussions) + [Pr151 - CIP30 event API](#pr151) * [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 02/15/22 Editors meeting notes taken during that day's CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Notes might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-39) 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 15 2022 notes **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, ~Robert Phair~. + guest (MPJ) ### Triage #### PR136 [PR136 - metadata onchain standard ](https://github.com/cardano-foundation/CIPs/pull/137) **Matthias** - Before I begin also, I would like to present Maria who is with us today from the Cardano Foundation. She will be taking over Frederic Johnson on the project management for CIP Editors sessions. We will jump right in to the first PR on the Triage list, which is PR137 - metadata onchain standard, which has been approved for a while. As I recall, we left to comment on that back in November. Regarding a few points in this pull request. The general idea here is the proposal about defining a standard for using the Cardanol blockchain as a data store. When it comes to specific data related to transactions or DApps. And it comes obviously as an alternative to storing metadata off chain. And it's currently proposing a few other CIPs. The main concern on the onchain metadata is that the blockchain is probably not really suited for that kind of storage. So that's what I started to outline back in November. There are also some security concerns with that, because if you start adopting the standard and then not everyone is following that standard,, there is a good chance that there will be some misinterpretation of this data. This was actually outlined by Michael PJ also back in November in another CIP. So there is a comment linking to that. There have also been some recent comments, which I haven't got time to go through. Sebastien, did you have time to look at this PR, because it's pretty old? **Sebastien** - Yes, I remember we looked at this a while back. We had some concerns about the ability of these and then also backboarding existing tokens. These were two concerns. I'm not sure what to do about this one because although it's not perfect some people are really early using it. At the same time some other people are not using it, and they're using the 7.21 proposal. Even though they're not making NFTs. It is just because wallets are currently implementing this 7.21 version. Wallets are now stuck having to look at a token and see if it is saying 7.21 token. Then based on the supply of these tokens then decide if it is NFT or not, instead of just policy or standard. We can either double down on these routes or just cancel the CIP in a sense, and then double down on CIP-0025 which is this 7.21 version and extend it for tokens. This is how we stay backwards compatible with those people who took that route, or we just acknowledge that this standard is not perfect, but it is something and move to merge it. **Matthias** - There is no perfect solution, and that is a potential liability for some projects and the risk that it may include. I mean, it seems we've already reviewed that proposal, a while back, and most of the comments we made haven't been addressed. I would just ping Matt on that and see if they can provide any updates. I guess they made a proposal at a point where it made sense to them as well, but they reverted the decision later on. I don't know. We definitely need some updates from the author here. I guess there is something to do regarding onchain metadata. I don't think that proposal is it. I hope there is someone that can rework if possible. I am just too afraid to have two standards that are not completely compatible. But they can also cover different use cases, that's fine. Michael pointing out, actually these comments we had before. And this is the same. Yes it is poofing, as outlined in the previous proposal. So, I guess we can simply go back to this one. In the meantime, contact the author Matt and see if he can provide any additional feedback on what we already provided or maybe reviewed. That will make more sense. **Frederic** - Would we put it back for Triage in the next meeting? **Matthias** - No, I would wait for another update. I will write a message on the pool request asking for updates. Then we can reconsider it for Triage when there is an update. Otherwise it will just be there. => [PR136](https://github.com/cardano-foundation/CIPs/pull/137) Moved off the agenda (and off from 'Triage') until Matthias have update from Matt and see if he can provide any additional feedback (check in on it in a few meetings) #### PR153 [PR153 - moving CIP 23 status to 'Proposed'](https://github.com/cardano-foundation/CIPs/pull/153) **Matthias** - CIP 23 - Moving to status proposed, which is PR153. It should be draft to proposed. I have approved this one while back, there has not been a recent date. I don't have any rejection regarding moving it to proposed, since it was actually proposed a while back. I was reaching out to research this morning on a few CIPs including that one. To get back on while trying to review this. A few of those CIPs which involve core changes. Most of them are actually regarding stake pools, pledge mechanisms, rewards or ranking. As this last comment highlights, there are concerns and secret reasons why some of these CIPs may not be implementable. Stil, I would like to get very clear answers from the research team on that. Just to be able to label those CIPs as not doable or obsolete. If they are not doable, or if they are not then try to see how we can start a process to get them implemented in the core part of the code base. Any comments on Sebastien, Frederic or Maria in terms of moving this from draft to proposed? It was merged as a draft almost a year ago. **Frederic** - I approve it would be good to merge this or to move it to the last check. I do not know which is more appropriate. I think that it'd be fine to merge it as it is. How do you feel about giving it like two weeks to review it? **Matthias** - No. I mean this is a pretty old CIP and it should be merged as proposed already. Still, we won't be merging it as easily. Because the pool request is quite weird. There are five commits there which are unrelated. Only the last one is changing status. I'll do a bit of github cleanup before merging that. So we can just get one status change and not have a heavy weird history out of it. => [PR153](https://github.com/cardano-foundation/CIPs/pull/153) being looked into and to be followed on of next meeting (should it be moved to 'Last Check') #### PR157 [PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157) **Matthias** - This PR is adding multisig changes to CIP-0021 which describe all the requirements for the hardware integrations, what the hardware supports and what are the capabilities. Back when this was written, there was no support for multisig native scripts and phase 1 monitor in scripts. I think that's what this is referring to. Which has now been implemented by the hardware team. It is quite a minor update. **Frederic** - Maria can you scroll up and click on the file changes, to show the changes? **Matthias** - Yes, it will just give us a summary of what's being changed. So it is stating that many things which were not supported back in the days, and now it is supported correctly. I think there are still limitations on the hardware devices. Obviously. The VacuumLabs team has been updating this CIP regularly with their progress. It is a dynamic change log of what the hardware devices can do. Which include both tresor and ledger, as I recall. I guess we can merge this one then. **Maria** - Shall we move this one to last reviewed? **Matthias** - Well, given that this one is a small update on an existing CIP, there is no need to do like the last review, last cheek, for this kind of minor update. We can just proceed with merging that one. I see Sebastian has already agreed. **Maria** - We have both approvals. **Matthias** - I will just ping Robert on that. Now we can move into the last check items. => Merge NOW ([PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157)) ### Last Check #### PR148 [PR148 - Update to CIP 30 (signData API)](https://github.com/cardano-foundation/CIPs/pull/148) **Matthias** - So we had PR148 - Update to CIP 30 (signData API), which we already reviewed last week. And before that even it comes with few changes, and I guess the remaining one was this format for the addresses in the API. Which was here “It was merely hex-encoded bytes of the signature or what.” We decided it would be better to actually favor take through encoded addresses. This is how we manipulate the addresses and facing interfaces. I don't think Rob has done anything. Yes, he was probably busy with other stuff. Because last time we pointed that out it was back in January. I think there is not any progress on that one. I would just ping Rob and see if we can move that one to the Last check on the next CIP meeting. Is that fine for everyone? **Maria** - We are moving this one to Last Check for the next meeting? **Matthias** - Yes, I am pinging him on github, and we can move this one for the Last check for next week. To check if there are any updates. => [PR148](https://github.com/cardano-foundation/CIPs/pull/148) moved to 'Last Check' for next week ### Review #### PR159 [PR159 - tentative CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) **Matthias** - Next one is CIP 31, which we've already reviewed quite a bit. There has been a recent update from Michaele. Here in the chat, we can also invite him onboard. I think the update was mainly about forbidding the usage of these new features for old scripts. Plutus V.1 script that is already ongoing on-chain. That racional for doing that is actually quite good, because you do not want to silently be failing, and silently be deconstructing the transactions that already look different from what they are. That could lead to very interesting but bad behaviors **MPJ** - Not really, the discussion was mostly around the same topic of old scripts. **Matthias** - From my perspective, this one's ready to go as a draft at least? While the implementation is also going on, there might be still a few changes. Maybe a few things got discovered, forbidding it for the old scripts. I actually approved that a while back. What is your state of mind on that, Sebastian? **Sebastien** - Yeah, I think it was also good to go. **Matthias** - Okay. So Michael is saying, “summary: the ledger would like to maintain the principle of "constructing the transaction context is as injective as possible", i.e. we don't throw away information silently. That's what's guiding the changes to all of CIP-31 to 33.” Okay, that's good. And I guess maybe that's a bit off record, but while we're at it, for the Plutus V2, we might also consider the case of biome addresses, by silently omitting stuff that would be maybe good or maybe completely remove biome from the ledger at some point. **Sebastien** - Well, I have a question about the banning of old scripts. Is the definition of old scripts Plutus V1, or is the definition of old scripts native scripts? **Matthias** - No, Plutus V1 here. So that would be really the Plutus V1 that doesn't support or not yet aware of these capabilities. So the idea is to say, " If you want to use these new features, that would be a reference input, that would be a reference outputs and inland datums, all those things, you would have to use the V2 version of Plutus. And if you try to construct a transaction that contains a Plutus V1 script that is making use of those new features, that should be a ledger of failure and your transaction should be rejected in phase one. Right, Michael? That's the goal? Okay. Phase one failure. So that's good. That's really contextualizing the transaction correctly before you start validating it and running the validators. So I guess we can move into last check for next week, unless there is any major changes that should just be kept in Ripple as draft until the implementation is sorted out, and then we can move it to propose or active. So Les is saying, "Should it be treated phase one?" It has to be a phase one. "Yes, I do agree with that."" It is sad that Michael doesn't have any microphone so that would be nice to bring Les and Michael on the voice. But maybe then if that's actually not quite clear, Michael, could you add a justification of why this should be added as a phase one validation failure? What would be the rationale for that? So that it is clear from the proposal. => [PR159 - tentative CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) moved to 'Last Check' #### PR160 [PR160 - tentative CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) **Matthias** - Good. So next one on the agenda is CIP 32, inline datums, which is also quite simple. I thought we merged that one already last meeting. CIP 33, right? So CIP 32 is about using this datum field that we currently have on output, which currently can only contain the data hash to use it, to contains actually non hash data, which would be suitable for small datums, actually, and really transform the EUTXO as a ... really give it the ability to carry a bit more data than what it currently] does. That's particularly useful for [inaudible 00:20:57], for instance, and a few other use cases that needs to just publish some very short data onchain. This one has been through far less comments than the others, but there were a few comments from Sebastian back in December. So I'm not sure if you want to continue and take that one on, Sebastian. I haven't watched following in the discussion on this one. So I will be glad if you can give us a summary. **S** - No, I think everything we've answered already. **Matthias** - We'll move to Last check. I would give it a proper read also again for the next meeting, especially all the conversation that has been going on. I had looked at the CIP a while back, but there has been quite a few comments. Okay, if Michael have any comments to say, otherwise, we can move to the next meeting as last check. => [PR160 - tentative CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) moved to 'Last Check' #### PR163 [PR163 - Tentative CIP: "Dynamic Saturation based on Pledge"](https://github.com/cardano-foundation/CIPs/pull/163) **Matthias** - The PR 163, which is CIP not yet assigned. So that's also one of the CIPs I've written to the research team's attention this morning, as I would like them to chip in a bit on how this would impact our current reward mechanism and other assumptions. So the core-ID here is to limit the amount of the pledge cap that is currently fixed to in away proportion of the total stake divided by K, K being the protocol parameters, currently fixed to 500. So instead of limiting the saturation by the whole stake of a K, we want to limit it by a proportion of this amount based on the amount of pledge such that pools with lower pledges have also lower saturation cap. And the goal is actually to sort of favor state pool operators to use bigger pledge instead of duplicating or splitting small pledges into more pools. And the goal of that CIP is to avoid the multiple construction that's currently happening on Cardano and try to favor a bit more single pools. On the comments on that CIP, there was actually a good remark from Jerry, asking for what are the thresholds and what are the expectations for the thresholds? Currently, the threshold is 500K ADA, you got to 100% of the K saturation level. For 250K ADA, you 50% of that, and so on. The thresholds currently are a bit arbitrary, although they have been, I guess, calculated from what's currently observable from the main chain. There may be a good argument for saying that the threshold could be a protocol parameter, in the very same way that K is a protocol parameter, so those things could be adjusted dynamically to react to market changes or what's happening on chain. Anyone has any comment on that one? Sebastian, Frederic or Mario? I guess that's no. So from now, I would like someone from the research team to chip in on that. From my own perspective, I find the proposal interesting. It should be also relatively simple to implement as a first maybe step in that direction if this is also something that is wanted by the community. Which brings us to another question regarding CIPs like that, and that are quite opinionated, is how can we tell whether or not some changes are actively wanted by the community or granted by the majority of the people on the network. So that's maybe a good topic for discussion to get a few people from a panel and see how we can approach these kinds of changes, because there are many CIPs like that, that would be sound and fair and good ideas for many, and that would be terrible ideas for others. So yeah, I would very much question that, how we can get consensus on this sort of thing. I see Kevin saying “I'll point the research team at it” I did it this morning, Kevin, so hopefully we should get someone to review that and to get some feedback. And I would like to sort of have a more streamlined way of doing that, generally speaking, with the CIPs, because there are at least, I think, six or seven ones that have prompted me to research this morning, which I would like to get research inputs. And once we have actual research input, we can bring the discussions into engineering to see the feasibility of implementation. And then there is this other political aspect, which is deciding on whether or not a CIP, a proposal, should be implemented. I don't have the answer yet on that. So something to be discussed within the community. **Maria** - So right now, we are going to leave this PR on hold, until we get the input from the research team. Right? And start thinking next steps if we want to bring the store conversation within the community, right? **Matthias** - Yeah, but that's a bit out of scope of the CIP process here, but more of a general work on organizing changes around Cardano. So as a CIP editors here, and as part of this process, our goal is really to tell whether or not proposal is sound, secure and holistic as an implementation proposal, but it doesn't give any form of authority on whether or not a proposal would be implemented. And that step is still a bit missing. So because we insist this proposal is sound and we want to get it merged, that doesn't mean it will immediately be implemented as part of a whole major change. And I know that a lot of people have been frustrated, but that's the second step because there are many things involved. And as I said, some proposals which are sound from a technical perspective, that will please some people, some other will disagree with. And this is where we need to find how to reach consensus on that. But this is also not our role as editors. So that is just what I wanted to point out. => [PR163](https://github.com/cardano-foundation/CIPs/pull/163) Moved off the agenda (and off from 'Last Check') and put on hold until we have update from research team and from community (check in on it in a few meetings) #### CIP 35 - Plutus Core Evolutions **Frederic** - Also, just to flag for this meeting, we have 25 minutes left. We're getting to the discussion section of the meeting, but maybe there's still pull requests that should be brought up that we didn't get on the agenda? **Michael** - So yes, there are a few small ones that we can actually resolve probably synchronously. There have been a few ones, actually. There is one I would like to talk about because it's also root PR or root CIP that would give birth to other things which is tentatively the CIP 35, which is called Plutus Core Evolutions. Since we have Michael here, that would be a good opportunity to talk about that. So that CIP's proposing a process for proposing changes into produce and actually getting them implemented. Right. So it's sort of a way to ensure that this can actually happen and have a process for that, which involve also the ledger team so that people can start making proposals to Plutus. There have been quite a lot of comments on the CIP and conversations going on. So maybe Michael, not sure if you have sorted out your microphone issues, you can give us a small update. Yeah, not about implementation, but still it gives a process for reaching out to implementers, right. **MPJ** - The actual reflection, probably it's not time for the editors to look at this because there have been some comments and hasn't been opened for very long. So probably we should wait for more people to weigh in. **Michael** - I'm not asking for review now, I'm just wanting to bring it to the lights so that people can actually go and see comments. **MPJ** - So a couple things that would be useful to have comments and things on, one is this is a process CIP. I'm actually not sure if there have been any other process CIPs? **Michael** - It has been. **MPJ** - There have been? But in particular it's proposing tweaks to CIP process, not necessarily to some other process. I'm not sure whether the form is ideal. You know, I'm basically saying you should propose these changes in CIP themselves, and also you should do the following things. I'm saying, "Well, it's up to the editors to make sure that it happens", stuff like that. I'm not sure whether it is totally appropriate. The thing about implementation has proven a bit contentious. So there was some good comments from calls, but who was really very interested in and who would really like to pin down the contribution process. And in some ways this would be a more useful document if it said, "Well, in order to get your change merged, you need to have good testing and have blah, blah, blah, blah, blah". But as far I can tell, that's just really out of scope for the CIP person. It's about the design. This says what you have to do to get the design document approved. And then in order for it to be active, you have to get that implemented and how you do that is really not covered. And we have to improve our documentation about what is required for actual contributions elsewhere. This just says what you have to achieve, which is still useful to people because they can see what they have to achieve one way or another. Part of the point of this is to make people sort of take a step back and think, "Hmm, can I do all this? Do I have a good argument that people want this? Do I have a good implementation? Do I know how this thing would be costed?", whatever. Otherwise people just open issues on the Plutus core. Which is not a bad thing. But I think we can say, "Look, if you really think this is a good idea, show it." **Michael** - Regarding the implementation, we already have quite extensive contribution guidelines on the Plutus repository. Which maybe could be extended also to cover a bit more of this process. **MPJ** - It's also going to be context dependent. Right. So, for example, there's this thing the club has been working on, their new cryptography that they wanted into Cardano base. So we could use it from there and then it's contributed in a clear place. And then it has to pass whatever gate keepers that are on that repository to make sure that's acceptable before then it can get to Plutus.. You still need to work out where to make the changes and then get people to accept them. I think probably we will then write something like this, a guide, for implementers of built-ins in the Plutus repository, which hopefully will provide a complement to this. **Matthias** - Yep. And that sounds like a good step in the right direction for open sourcing this whole thing really. **MPJ** - It's certainly about making it public, but also giving people ways to implement things in it, to work with it. The guidelines currently are already pretty extensive and you can definitely extend that to include a few more steps. **Matthias** - But as you said, it's always been dependent on the context and on the features, right? You don't look at the same things, depending on what you're trying to modify. But at least the CIP, I think, already gives some steps and some things to think about before actually considering making a change to produce, which is good. As you said, there is a cost model taking to into account our hard fork, there are Plutus version changes and all those things, right? Once you have carefully considered all of that and you still think your CIPs or your proposal makes sense, then you can move it to the next step, which is implementation and proposing that to the Plutus core team, following the Plutus guidelines. Or maybe we'll just do it because you convince us it's a good idea and we schedule it or something. So, I think some people are like, "You're saying, we're just like going to just say your problem. You sort everything out." That's not necessarily true. The process of implementation might be that the person who wrote the CIP does all the work because they're really on it. Or it might be, they persuade IOG that it's a super great idea and we schedule the work to do it, or whatever, or we help them, you know? **MPJ** - I don't think that belongs in the CIP. **Matthias** - Exactly. And that's what I was raising before. There is another step after CIP, which is getting the work implemented. Or you can, as you said, get, IOG convinced that this is a great idea that should be implemented. **Matthias** - I don't think this is really in scope of the CIP team per se, but I still want to have this conversation. Not necessarily be part of it, but at least have that conversation set up somewhere between relevant people. **MPJ** - But I think that if we made that clearer...For example, you could have a mandatory section in the CIP for implementers. And then you say, "Look, this is where you edit this, when you find someone who's going to implement it. And if it's blank, you don't have anyone to implement it." **Matthias** - That's sort of what the past two active, currently is in the CIPs. It should highlight clear steps that can bring the CIP from proposed to active. And that includes an implementation for the CIP, that algorithms, some are not related to code necessarily, right? But yeah, some step might be get that implemented in Plutus by X or Z. And then you have either to have already reached out to the Plutos team for that. If you can reach the Plutus team for instance, and they clearly tell you, "No, we won't implement that proposal, even if it's technically sound because this and this and that," then you can go back to the CIP and make it obsolete, right? Or duplicate it because the past to active is actually not...You cannot act, but you did it. You cannot realize it, right? If there is no way for you to implement it and to get into the active position, then you might as well not give your CIP as proposed forever, which is you turn it off. **MJP** - Okay. In my opinion, this isn't totally easy to understand from CIP-001. **Frederic** - So let me step in on this one. By past to active, really what we mean is observable criteria that we agree as a group reflect the active status of that CIP. So whether those criteria are observed, it should be something that someone external to the editorial panel can go and verify. So it's something that people will push into the body of the pool request or the CIP, and say, "I want to see five implementations of this to consider it active". And the past to active agreement on the PR by the editors is effectively saying, "Yes, we agree. Those criterias will be observable". And if they're observable, it should effectively mean that it's active. **MJP** - Sounds like the editors should get together to decide what path to active means. **Matthias** - I hope I didn't imply anything else, but yeah, that's what we stated in the CIP-001, actually. **MJP** - In that case, maybe just elaboration that adds, for example, that might mean naming an implementer, but that doesn't even fit there, right? I think there's a useful thing to be able to say, which is to say this CIP either has someone who's agreed to do the work or it doesn't. And at the moment, the path to active, as I understand it, might say something like "Here's a checkbox saying there is an implementation" or something. But I think that, as someone looking at the CIP or considering its status, it'd be quite helpful. If you just see an empty check box saying "implementation", it's not complete. That doesn't tell you very much. But if you see an empty section where it says "implementer blank", then you're like, "Okay, no one has even agreed to do this", right? And it's meaningfully different to see there is an implementer, but they haven't done the implementation. Okay. That tells them something else. **Matthias** - Yeah. So Kevin is also saying in the chat maybe that we could add an extra status to the CIPs. For those that are relevant like the Plutus core changes, or the ledger changes, right? After the proposed date and before the active state, we have the state that is accepted or adopted, meaning the identified implementer has accepted to implement the CIP, and will work on implementation. That's similar to this past to active is, or it's maybe the step before the past to active, right? Past to active would be: reach out to those people and then have actually the implementation done that you can review and see. **Maria** - So what do you want to do with this CIP 35, do you want to still discuss it at the next meeting or? **Matthias** - Yeah, we can move it for review for the next meetings maybe. I mean, we'll see when we create the agenda. I would also like to leave a bit more time for that one. I mean, the next things will be in two weeks, but maybe we want to have it in the next meeting, but in a month from now. => [CIP 35 - Plutus Core Evolutions](https://github.com/cardano-foundation/CIPs/pull/215) put on hold and wait for more comments ### Discussions #### Pr151 [Pr151 - CIP30 event API](https://github.com/cardano-foundation/CIPs/pull/151) **F** - We have PR 151, Is this worth reviving to CIP30 event API, or should we move this in? **Matthias** - I revived it some time ago, I think. That wasn't that one, actually. The event API, yes, it doesn't seem to have gotten a lot of changes recently. #### PR 211 - Add reference implementation CIP15 **Sebastien** -- Can we look at 211? Add reference implementation for CIP15. A simple change. So basically, I was looking into how to get catalyst support for Flint, which is our new wallet, and I noticed there's no library for this, so I created a reference implantation. This is based off the same core idea we had for [inaudible 00:44:01] originally, so it is used in production networks, although this library is not used by [inaudible 00:44:06], so it's not the same. **Matthias** - That's your reference implementation by the author, right? You also want that CIP back, so I guess that's fine. Okay, well, let's also ping Robert about that, I guess, but yeah, we can take that off. It's fine by me, and since it's a quite minor change, we can also merge it synchronously. Any questions in the chat? No, no questions asked either on the platform. **Sebastien** - We also merged 207. Seven updates came, you take care, Max said. But what I'm saying, this has already influenced it, and they're just updating the CIP. **Mathias** - Well, yeah, I kind of disagree with that one, but I see that four of you agreed. I mean, I don't disagree with increasing things in particular, right, or changing, but hear it sounds more like an implementation detail of the implementation rather than CIP. **Sebastien** - Yeah. I mean the other changes we could have removed this line from CIP. **Matthias** - Yeah, and that actually implemented ... Several implementing that decides on where they want to draw the cost out, and at the same time, if the implementation is based on that, right, that's also breaking change per se, so, yeah. Anything else from your side, Sebastian? => [PR 211 - Add reference implementation CIP15](https://github.com/cardano-foundation/CIPs/pull/211) put on hold and wait for more comments **** Collateral CIPs **Sebastien** - If there's nothing else, I'd like to talk about the collateral CIPs, so we have three collateral CIPs, collateral key, collateral output, and collateral reward. Collateral key is an old one. We can close it. Collateral reward is a new one. We can close it as well. I'm not going to push for this, but we can leave it up for now, and close it at a dedicated time, so it might be good. Collateral output, so I'm gonna give you some backgrounds, final stuff. So basically, for the past hard fork, last time there was no hard fork, for Alonzo, we introduced the concept of collateral. I was not happy with the way it was implemented, so I talked to the IOG team about how I think it should have worked instead. As this was happening, the IOG people also took my feedback into account, talked to other people, like Beck Labs, took their feedback into account, and brought the specification for it, and I in the parallel wrote the CIP part. So there is still four months-ish, until a hard fork, so I guess I'm good changing, so there's no rush to merge it, but just the background on this collateral output specification is just the write up of what we discussed internally. I mean, this is before the hard fork happened, like leading up to the hard fork, and I don't remember who was involved because there's a lot of people involved in this. I could go back in my slack history. I put Jared because he's the one managing the spec, and myself, so I put the CIP which I had like three months to do this spec. I don't particularly mind removing myself, as I'm just the person who is capturing the discussion right on Slack, and just only having Jared as the author because he's still managing the spec change, but it's how it's set up. The collateral reward was purely included for ... Yeah, I did update it to match the spec by the way. Andre, I believe that your discussion with the feedback from the Harvard Law guys was after I brought this discussion up to Jer, and I told him this won't work with a Harvard wallet, so you're gonna have to go talk to Beckley Labs about how to get this; and that discussion was included in the collateral key discussion, so basically, collateral key was the old CIP. One of the problems I laid out in the collateral key was that we need this approach because the current approach doesn't work with Harvard wallet. That's how that discussion started. So collateral reward is purely included for your completionist purposes in different ways we could have it. And this is basically saying, instead of saying the collateral output to a new address, the collateral output instead gets sent to the reward account. Now, obviously, this is not doable in current implementation of Cardano, I mean, it's doable, but I would not suggest it as a good idea for many reasons. I mostly brought this up because one, it is technically speaking doable, but also two, because there's been some discussion about primary ledgers, and how primary ledgers could affect stuff like drip drops, SPOs. And I was just mostly writing this up to say, hey, if we bring back primary ledgers, they would affect these SPO cases, and could be a way we could do collateral output and so on. I don't think anybody would've push for this. **Matthias** - So if the intent is actually to show that this was a path that was discussed, but sort of rejected, there is always the option of merging it as a rejected CIP or obsolete CIP. So that it can really show that, yeah, this was discussed and this was really rejected for these and those reasons. **Maria** - Could you make a quick summary? I think you said there's three collateral PRs, but I've only been able to locate two of them.. **Matthias** - I think the first, or third one should be, or will be closed anyway by Sebastian. Yeah. It's the PR 104, which is now labeled as likely deprecated, and then, so Sebastian, since you also the author of that one, I guess you can move forward and close it. **Sebastien** - This is from before the hard fork, before we discussed collateral output and collateral output **Matthias** - I remember that. There was also the case of merging that one as a rejected obsolete CIP. Just to keep the discussion recorded. **Maria** - Okay, so we have this collateral key that is going to be closed or marked as obsolete? Then we have a collateral reward that is going to be closed, but we have time to do that? And then there's the collateral output, that it needs to be done before the hard fork, so there's no rush, but ... Shall we put them on review? **Matthias** - We could probably put that on review for next week or next month, at least, to also give you a bit of time. It seems like the spec is being worked on by the ledger team in parallel, so that already gives a more streamlined path to implementation, possibly. It is quite observable from past to be active. I'm not sure if they will be done in two weeks from now, but yeah, maybe we can have it as review for the next meeting, and if it's still being cooked, we can look at it back. Yeah, more weeks for the next one. I think we'll just stop it here, and thank you everyone for joining, coming, and commenting. It's good actually, to see more and more people joining these meetings, and see you in two weeks. => [CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) moved to Triage for next meeting => [Collateral reward #217](https://github.com/cardano-foundation/CIPs/pull/217) moved to Triage for next meeting => [Collateral output #216](https://github.com/cardano-foundation/CIPs/pull/216) moved to review ### Close => Merged minor changes to CIP-0021 - [PR157 - Adding multisig changes to CIP-0021](https://github.com/cardano-foundation/CIPs/pull/157) => Hold on [PR136](https://github.com/cardano-foundation/CIPs/pull/137) Moved off the agenda (and off from 'Triage') until update or any additional feedback => Hold on [PR153](https://github.com/cardano-foundation/CIPs/pull/153) being looked into and to be followed on of next meeting (moved to 'Last Check') => Hold on [PR148](https://github.com/cardano-foundation/CIPs/pull/148) moved to 'Last Check' for next week => Hold on [PR159 - tentative CIP 31: "Reference Inputs"](https://github.com/cardano-foundation/CIPs/pull/159) moved to 'Last Check' => Hold on [PR160 - tentative CIP 32: "Inline Datums"](https://github.com/cardano-foundation/CIPs/pull/160) moved to 'Last Check' => Hold on [PR163](https://github.com/cardano-foundation/CIPs/pull/163) as conversation continues => Hold on [CIP 35 - Plutus Core Evolutions](https://github.com/cardano-foundation/CIPs/pull/215) put on hold and wait for more comments => Hold on [PR 211 - Add reference implementation CIP15](https://github.com/cardano-foundation/CIPs/pull/211) put on hold and wait for more comments => Hold on [CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) moved to Triage for next meeting => Hold on [Collateral reward #217](https://github.com/cardano-foundation/CIPs/pull/217) moved to Triage for next meeting => Hold on [Collateral output #216](https://github.com/cardano-foundation/CIPs/pull/216) moved to review --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 33 | [Reference Scripts](../CIP-0033/) | Draft | | 34 | [Chain ID Registry](../CIP-0034/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-03-01.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [March 1 2022 Transcript](#march-1-2022-transcript ) * [Triage](#triage) + [PR211 - Add reference implementation for CIP15](#pr211) + [PR104 - CIP-1856 | Collateral Key derivation](#pr104) + [PR217- Collateral reward](#pr217) * [Last Check](#last-check) + [PR153 - Fair min fees](#pr153) + [PR159 - CIP-31: Reference inputs](#pr159) + [PR160 - CIP-32: Inline datums](#pr160) * [Review](#review) + [PR148 - CIP-0030: update to api.signData() ](#pr148) + [PR216 - Collateral output](#pr216) * [Discussions](#discussions) + [Add support for Catalyst multi-delegation](#pr200) + [PR208 - CIP-0030 Adding getCollateral function to the connector API](pr208) + [PR209 - CIP-0030 Adding optional networkId parameter to .enable](#pr209) + [Moving meeting 41 to US time zone](Moving-Editors-Call-Meeting-41-to-US-time-zone) * [Close](#close) ## Summary Rough transcript of 01/03/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-40) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. ## March 1 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, ~Sebastien Guillemot~, Frederic Johnson, ~Robert Phair~. + guests(Kevin Hammond) ### Triage #### PR211 [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) **Maria** - Welcome, everybody, to the CIP editors meeting number 40. My name is Maria Jover and I am a project manager of the Cardano Foundation and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today and please feel free to use the chat or the ask question in order to engage with the conversation. It's my pleasure today to introduce you our editors, Matthias Benkort and Frederic Johnson. So you want to make an announcement or a request, right, Matthias? **Matthias** - Yeah. So we've been discussing in the past a bit getting the CIP into a more US friendly time zones so I've been discussing that a bit with the other editors and we would like to try to have meetings more often in these time zones. So what we're going to do is to move maybe to a weekly cadence, where half of the meeting will be still at the current time, so in the Europe based, at this daily hour, on the same day, and the other half of the time, it will be on the same day also, but later, or more around six, seven from European perspective, but then it'll be a more convenient time for the US people to join in and chip in. And also, it will double basically the frequency of meetings. So hopefully we'll get to move a bit faster on the triage and the discussions on some of the CIPs. That doesn't mean that the process per se will be faster per CIP, because we still want to allow time to discussions and time for people to actually chip in. But at least we'll be able to cover, I hope, much more items faster. The CIP has gained traction over the past months. A lot of people are using it. And yeah, so we have to keep up basically with all the request proposals and changes that are going on. **M. Àngels Jover** - Good. So shall we start with our items on triage? PR211: Add reference implementation for CIP15 **Frederic Johnson** - Maria, one second. So first, when we check in, is also if there's any long-lasting items that needs to be followed up on, that needs to be added to the agenda. I don't believe there is, but just want to make sure that we look into this, Matthias, if you have anything you want to bring up outside of the announcement. No CIPs? **Matthias Benkort** - No. Or maybe yes. There is a small Pull Request I did some days ago, which is just clarifying a bit the README on the CIP, because I saw a lot of people getting confused in the community about CIP31, CIP32, CIP33, and their adoption in Cardano. So I wanted to clarify a few things. That's for request number 227. It's mostly for editors to chip in here and Robert has already checked that. Not sure about Sebastian, but it's clarifying a bit the wording, clarifying the intent by explaining really what is CIP all about, and in particular, that it's not a process that is blocking implementations or that is mandatory for an implementation. And it's actually going often at the same time that you do an implementation and you propose also kind of the rationale for that implementation as a CIP. And they are both helping each other because as you implement, you discover new things. And as you discuss with people, you might adjust also your implementation. And I also added on the CIP on the README, a table with all the CIPs currently under discussions, that are still in pull requests, just to ease a bit the navigation so that it's easier to find. And to keep in mind that this README is also part of the website, the cips.cardano.org website that's the front page is actually our project README. And a lot of people are actually going through that website as an entry point for the CIPs, and many were surprised not to find the CIP32 or CIP33, which were still in pull request and not merged in the repo. So of course, since they are not merged, they are not in the audit table, which contains all the CIPS that we have discussed and reviewed. But I think it's still worthwhile to have them under README just to have to a link to them and to be able to easily jump on the conversations. So that's the change. **M. Àngels Jover** - Perfect. So now we have PR211: Add reference implementation for CIP15. This one, we had a conversation last meeting, and according to my last notes this was going to be merged asynchronously, but it hasn't been done, I guess. **Matthias Benkort** - Yeah. We were waiting for review from Robert. It came two weeks ago, but we then kind of forgot to merge it. So this is just a small update on CIP15, adding a reference implementation, which I've also reviewed. So this one is fine to go. Now it has two check marks from a editors so I would just proceed and merge that one. Good. => Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one #### PR104 [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) **M. Àngels Jover** - PR105 Collaterall Key Derivation **Matthias Benkort** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastian, who is not there today. So there has been a lot of discussions on top of it. And I haven't been following quite closely that one. So I would very much like Sebastian to walk us through a bit the discussions and the outcome. So the general idea here is really to have a ... it is proposing a dedicated key for making the management of collectables easier and hopefully remove that version from the end users, which currently has sort of to define a collectable in their wallets to make sure that they can execute scripts. And it's a bit cumbersome at this stage. So yeah, I see the proposal has been discussed by the people from the Ledger teams. So it's interesting. But yeah, let's see when Sebastian is back to walk us through that change. => [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it #### PR217 [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) **M. Àngels Jover** - Good. So it will happen the same with PR217 and PR216, right? **Matthias Benkort** - Yeah, one of them is actually duplicated. I think that's PR217. Sebastian said last week he wanted to remove that one, I think. **M. Àngels Jover** - The previous one was pretty old, I think. **Matthias Benkort** - Yeah, I think what he said last week was that this one wasn't really useful. He just did it for the sake of reporting what had been discussed with the Ledger team in the past. I think he wanted to duplicate it. So we'll also wait on that, maybe ping him back on the pull requests. I've dropped in the comments. => [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate ### Last check #### PR153 [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) **Matthias Benkort**So moving to fair min fees, maybe. The PR153. So this one is actually just exchange of statuses, right? If I recall correctly or not. **M. Àngels Jover** - Yes. What was talked last meeting is that you want to do some with github cleanup on it. **Matthias Benkort** - I don't think so. **Frederic Johnson** Yeah. The merged ... The comment history just has some weird back and forth and you wanted to- **Matthias Benkort** - Ah, yeah, yeah, you're right. You're right. Indeed. It has more comments than it deserves with only one word change. So indeed, hasn't happened. So my bad. So okay. Still ready to go. Will merge it then. But I will make a note for myself to do it at the end of this call. So yeah, to adjust the git history, just to make sure we have only the last comments in there because the other ones are from a wrong rebate or something, it seems. Yeah, I guess it's been there for a while and that's probably what happened. At the same time, also, I was going back through the CIP1 process and in particular, what it means to be proposed for a CIP, and currently, in the condition for semantic, for propose, we are saying that there is a clear path to active, which brings the question of the core CIPs, like this one, that are actually changing Ledger roles, or really addressing changes in the Ledger. What's a proper path to active. What does it mean? Because there is ... how do you get something to be active? There is no process formally defined criteria with the Ledger team for that, as the Plutus team is trying to push forward. They sort of outline the process for contributing to the Plutus code base, what it would take for a CIP to go from just a draft to an actual implemented and active CIP. But I guess we need to work something out with the Ledger team also for those kind of CIPs. **Matthias Benkort** - It's a bit more ... well, tricky for a Ledger, obviously, because it touches the core part of Cardano, so you don't want to do anything wrong with that. But okay, I will also keep a note for that, but I will definitely need to bring the conversation with the Ledger team and IOG on that, to make sure we have an actual way for bringing the CIP up front. I reached out to the research last two weeks ago on various sort of topics. I haven't got a clear answer so far, so I will keep on chasing people. But yeah. **M. Àngels Jover** - So we can put this on hold until you have an answer from the Ledger team, right? **Matthias Benkort** - No, no. For this one, it's fine. We've already discussed this one a few times. It's also been reviewed by the Ledger team back in the days, but there is still this question of, even if you're moving to propose, that doesn't mean it will ... There isn't currently a item on the roadmap of the Ledger team to address that particular proposal. I'm not sure that's shown as also the willingness or capability to implement the change in the Ledger code base itself. So it has proposed already an implementation, but more like a separated one. So yeah. I will bring that back again to the attention of the Ledger team to see what's up and if they have indeed no plan to implement that and it's a few unknown because these and these reasons. I don't know. Then we'll report back and maybe make the CIP obsolete. But for now, we can move it to proposed, and I will just modify the git history to have a clean history of commits with the Ledgers after the meeting, since it's a fairly small thing to do. => [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it #### PR159 [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) **M. Àngels Jover** - We have PR159: Reference Inputs. And for this one, we comment in last meeting that it was good to go, but we asked Michael to add a justification for phase one. And I don't think that that has been added. **Matthias Benkort** - So yeah, it was a small thing, right? That he added recently an extra check, again that was on the forbidding usage of referenceinputs with old scripts with the V1 versions. And I guess there's someone in the chats was discussing why was this done in the phase one but additions of phase two? But I guess we answered that in the last meeting already. Michael didn't report it back on the CIP. Yeah, just drop a line in there. I see it has also the insert, so we can maybe just clarify with him. I will just drop a comment on the pull request. And once we have that, this one would be ready to go and get merged as we discussed last time. **M. Àngels Jover** - Perfect. **Matthias Benkort** - So we'll just merge it with just the conditions as we add this little rationale, just one small line change. And I will state we can get that done today as well. => [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed #### PR160 [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) **M. Àngels Jover** - We have PR160: Inline Datums **Matthias Benkort** - Yeah, this one is pretty much. Also it was in the last check, it was under last check... No, it was just ready for review. **M. Àngels Jover** - Yeah. I think that we have a comment here. It's not in this one. This was for the last check. **Matthias Benkort** - Yeah. And that was a bit with some spirits. Yeah, this one is also fine. It should go as a draft towards the implementation. It happening also concomitantly. **M. Àngels Jover** - We have all the approvals here, I am going to check. We miss one approval, right? In order to merge it? **Matthias Benkort** - Yeah. So, Sebastian, Robert or Fred maybe later when they are up. I will just CC them. Okay. => Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) ### Review #### PR148 [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) **M. Àngels Jover** - Cool. So we will go into the review items. We're going to start PR 148, because the other one, we will wait for Sebastian **Matthias Benkort** - Yeah. So, 148. Yeah, I asked last meeting to have an update from Rob. He said: “I think it's read for review now. I just updated the spec to use an Address string type which can be either the old hex bytes or bech32. I think that's is it for comments on this besides out-of-scope large changes like not using cbor anywhere mentioned above. I changed the Address format in other endpoints for consistency, but we can do that in another PR if we feel it is necessary. There's also the issue of the API version. Should we be incrementing this by a major version here or do we only want to start doing that once CIP-30 moves out of draft status?” That's a good point.- There's one comment from Martynas: “How about adding a "content type" argument? Wallets could try to display the message being signed to the user” Not sure to get it. **Frederic Johnson** - So we will get changes that occurred since Rob actually pushed that comment, or show right before he post that comment? So, my issue goes to- **Matthias Benkort** - Yeah, that is what he said. We were discussing in the past, to change the API, to accept not the address as a hexacoded string, but actually as bech32 strings, which is the way it actually displays in most interfases. That's the way wallets manipulate them, and it's a bit more coherent with the entire presenter API. So, what we discussed was to do that for the same data, of course, but then reflect that on the entire API or to keep consistency. But since that would be in principle a breaking change, the idea was to support both formats. It has wallets that actually accepts either hex or Bech32 encoded strings, and let them figure out basically which one it is, which is pretty straightforward to do for a wallet implementer. So, as it is for now, at least from my perspective, the proposal is fine. This was not a proposal per se but just an addendum on an existing one, for the CIP 30. So we can probably move this to the last check for the next meeting, and see if people still want to comment on it or not. So, there is actually one comment, which is asking about something I don't quite get. So we can try to divert that with that person in the next two weeks and see where it goes. **M. Àngels Jover** - Okay. So, this was what we have from the agenda. Let me check if there's any questions in the chat. => [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting #### PR216 [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) ** Matthias ** - I would like to maybe postpone a bit this one, because it's a proposal from Sebastien, who is not there today. => [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it ### Discussions #### PR200 [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) **Matthias Benkort** - Kevin wanted to bring up the votes delegation CIP, which I think was proposed by Mark some time ago. That was initially proposed as an extension to Catalyst to the CIP 15 proposal I think. But then we decided that it was better to move it as a separate proposal, in form of like an extension of CIP 15, instead of modifying CIP 15, which is already complex enough, and it has undergone a lot of changes. **Matthias Benkort** - So, the idea was to say, "Okay, we want to have this extension to a line which you have multiple... or just do multiple keys for the Catalyst proposal, such that on the side chain can be multi-delegated to different pools, and therefore enables more like a split routine in the real. **Matthias Benkort** - We have Kevin around, so maybe we can bring Kevin on the voice chat, and he can give us a walkthrough. I think Kevin you've been discussing that with Mark a bit. **Frederic Johnson** - If I recall correctly, I think Mark was adamant on pushing his own pull request or own CIP. And I think Kevin did his own CIP, and I think there were two competing CIPs doing the same thing. **Matthias Benkort** - Okay. But I didn't see the CIP from Kevin actually. There was an original request which was changing CIP 15, which is still actually open as a pull request. ** Frederic Johnson** - But the decision on that specific PR was that we'd scrub that PR, effectively closing it, and instead request a standalone CIP just for simplicity, as opposed to trying to modify the old one. **Matthias Benkort** - Yeah. Because it was modifying quite substantially the old one, effectively making it a completely different proposal. So we asked Mark... Actually, we asked to create a number of PR, and Mark volunteered to do so, but haven't still closed the old one. I'm not sure actually who opened the old one in the first place. Do we have Kevin online? Oh no, Kevin is not here anymore. So let's actually go through the comments ourselves then. Oh, Kevin is there. **Kevin Hammond** - I lost the window. Happy for this to be a separate CIP if that’s what you want to progress. What we do need is a dedicated CIP number that we can just refer to this internally during the developing process. We're trying to use CIP 36. I understand that number that Mark assigned to it, there is path for confusion developing. On terms of content the we've been commenting the new PR that Mark had put in. **Matthias Benkort** - Yeah, okay. So that's [crosstalk 00:23:13]. **Kevin Hammond** - What else now needs to be done? **Matthias Benkort** - Well, discussing, obviously, right? Making sure people agree. I think that's fairly the case on that one. The number assignation, that's part of why I did this little change in the read-me I was mentioning earlier. One of the reason why I wanted to move also the current PR under discussions to the read-me, was to pre-allocate them a number already, to avoid these clashes. And this one is in this number 36, so there is a good chance that it will stay exactly like that, unless it gets not merging in the end and ends obsolete. But I don't think this will happen, so we'll probably proceed with that. Move it to the last check as well for the next meeting; it's been reviewed already quite a bit. And yeah, I take it from there basically. So those two discussions... No, I think let's check with maybe too soon, we haven't properly given time to discuss it in any little meeting. We can move it to the next meeting for review. **Kevin Hammond** - Okay. **M. Àngels Jover** - Is this one PR 188 we're talking about right now? **Matthias Benkort** - No. This one is the old one. That's the one modifying CIP 15 that we asked to split as a separate pull request. **M. Àngels Jover** - So which one is the one that we're going to add to review in the next meeting? **Matthias Benkort** - PR number 200, right? Yeah, the 200 one by Mark, which we'll have a full complete review of that one. **Kevin Hammond** - That's slightly go over authorship it should be attributed Giacomo to who wrote the original proposal rather than Mark. I don't know if there's a way to [crosstalk 00:25:22]. **Matthias Benkort** - Yeah, it's not attributed to Mark, right? It currently has one, two, three, four, five authors. You're actually one of them, by the way, apparently. Giacomo is also one of them. I guess Mark just wrote the PR, and he didn't even credit himself as an author. He just credited the original. It's just that he did open the pull request. **Kevin Hammond** - I'm actually trying to get some attribution. So, if Mark created the PR, he'll be attributed with creating this. **Matthias Benkort** - No, no, no. If you look at the author of the CIP, they are actually listed here, right? ? So it's Sebastian Reno, Mikhail, Giacomo and you Kevin. Github is always referring to the person who has created the PR as being [crosstalk 00:26:17]. **Matthias Benkort** - I see what you mean. So maybe what we can do is tweak a bit the GitHub history so that this full request is made as a change on top of Giacomo one. So that in the history we can see that one. This first thing it was reverted, and then this new commit was created. I can do something like that to have the above authors actually be contributors to the repository. **Kevin Hammond** - Exactly. That will keep the history straight and fair. **Matthias Benkort** -Yeah. Fair enough. **Kevin Hammond** - Like proper credit. **Matthias Benkort** - Yeah. **M. Àngels Jover** - So Matthias, you will be able to do that yourself or... **Matthias Benkort** - Yeah. I will just push on the branch only if Mark actually have authorized people to push on his branch. If not, I will see with him if we can just do that updates. Right? So the ideas is really not to change anything to the current result, but change the history. Right? So that it better reflects what happened, that there was a first change by Giacomo, and then it was on top of that extracted by marking a separate PR. Right? **Kevin Hammond** -Okay. **Matthias Benkort** - So in the history we keep the right history of how things happened. **Kevin Hammond** -Exactly. Yeah. I think it's important to make sure the history is recorded properly, right Matthias? **Matthias Benkort** -Yeah. I mean, in the end, that's why we have this metadata on top of CIPs. It's also, you have the list of authors here, and if you want to refer to one of those people, should be someone from the list. It doesn't quite matter who made the change on unbeatable when you think. But I mean, for some people, it does matter so I can get that. **Kevin Hammond** - It matters. It matters to some people. **Matthias Benkort** -Mm-hmm (affirmative). **Kevin Hammond** - Great. And in terms of status, we're working on this, we are taking into account any comments that have been made. If people like to make further comments, happy to respond. And not seen any major issues coming up through the commenting process. **Matthias Benkort** - Yeah. **Kevin Hammond** - If anyone would like to add anything to that, very happy to do so. **Matthias Benkort** - Okay, good. **Kevin Hammond** -That you. => [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review ### PR208 [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) **Matthias Benkort** - Let's see, maybe if we have other call request we could bring up to discussions here. If there's anyone in the chat that has a suggestion, otherwise we'll just pick one from the existing ones. I see there is another update on, or two other updates actually, on CIP 30, which we could maybe quickly go through. One is for request 208 and one 209. So one of them is Adding getCollateral function to the connector API: getCollateral given an amount, it gives back a UXTO to spend as collateral. The value to use for collateral? Because... yeah, okay. There is an amounts to be passed, but in principle, this amounts depends on the transaction script execution units. Okay. I guess that's an interesting one. We should also bring maybe for review for the next meeting. There is quite a fair, rational extension here. => [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review ### PR209 [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) Then on top of that, there is also the CIP... Sorry, the pull request 209, which is Adding optional networkId parameter to .enable: a DApp for test net or main net future networks. Okay, interesting too. And it probably echoes... Yeah, CIP 34 from Sebastian, which was about providing a chain identifier. So maybe there is something to do here. Have the network ID be provided as non-chain identifier. Yeah. Providing it as zero or one. Feels a bit untied, or not really user friendly from a developer perspective. So Sebastian had already a good proposal for identifying networks using a proper string of characters, I think codes the network ID and genesis. So we could go for that. So I would be happy also if we maybe this for review, for request 209. CIP 30 seems to be creating some discussion with IO... Of course. some additional functionality being needed. Yeah. So I guess the whole point of CIP 30... I mean the whole issue with the CIP in a way, is that it was created pre Alonzo, so there was a lot of things in there that didn't account for scripts and Plutus. Although it is now mainly used by wallets that provides that functionalities. And therefore, yeah, it needs a couple of extensions in that regard. So I guess the collateral is one of them that's get us in the right direction. The network ID is definitely also a cool one to be able to support multiples networks and have also... Well, I test wallets. Test CIP 30 capable wallets for testnets. If there is any other one, Kevin, if you can get the people in IO to make a proposal with those changes, that will be good. And the sooner better, right? Because we can start the discussion earlier then. Another CIP maybe, that I would like to bring to review our discussions next week, is the Plutus Core built-in of... Sorry, the Plutus Core changes CIP. Plutus Core evolution. So PR number 215, which gives a framework for actually proposing changes to Plutus and getting them through the entire process also including implementation with the team and all that. I think that's a very nice initiative for Michael to really lay that down and have a clear process for proposing Plutus changes. There have already been a couple of proposals on top of that one, following that exact process. So it would be nice if we could get this one approved, or at least discussed. I've already been reviewed by me, already reviewed it, because I already made a proposal on top of that one. And I definitely see the value of this one. So I would very much like to have it as an active CIP as soon as possible to be able to then move on and have proposals on Plutus. Exactly. That follows this standard. So they can bring it for reviews also next week and then last check. Hopefully we can get it into the repro quite fast. Since there is no implementation for that one even, we can probably move it almost directly to active. Because the sole fact that there are already two or three proposals on top of it, well, qualifies it as an active CIP. **M. Àngels Jover** - Okay. Anything else that you want to discuss Matthias? **Matthias Benkort** - I'm not sure. Keep getting the same stuff in the chat. Yes, I'll try to get people to comment on that. It seems to be some divergence on this. Of course, that's why we want to have a CIP. Because then discussions can happen on the CIPs publicly, and people can share different implementations and different wallets. Yeah. **Kevin Hammond** - That's right. So we need to get some standardization, I think, on this Matthias. And as I've said in the chat, I think there's some additional functionality which isn't original CIP proposal, which we'll need for the vote delegation. So we need witnessing capabilities as well as signing capabilities. **Matthias Benkort** - What do you mean witnessing capabilities? **Kevin Hammond** - I mean, we'll need to... Because the way the CIP 36 is to find, there are two distinct keys involved. One of them to provide a witness from a voting key... Sorry, from the stake key, and the other to sign and submit a transaction using a payment key. So we need sort out the different elements of witnessing using stake key, versus signing and submitting using payment key. **Matthias Benkort** - Yeah. I'm mean, okay. But in both cases that remains, it's still a signature. But it's just a signature from not a human key, but a staking key, right? **Kevin** - Yes **Matthias Benkort** - Because I thought you were referring to witness as in being able to add full scripts or datums or redeemers, or whatever's going for [inaudible 00:36:42] that. But that can already be done by a DApp in principle. They don't need the wallet for that. So how is actually currently... Well, I need to refresh my mind now. On CIP 30, how does the signing works currently? What does it provide? Sign TX, does the wallet determines automatically what the key test to use? Yes. Ah, yeah. Okay. Yeah. The sign, we give it the TX and the wallet figure out the transaction, witness it. Wallet should be able to figure out it's the staking key, right? But surely the staking key comes from the wallet? **Kevin** - As long as it knows it needs to sign with staking key, Matthias. **Matthias Benkort** - Yeah. So, okay. I mean, maybe we could use an API that is a bit more explicit, like the Ledger or Tresor devices works, right? For signing to device you give them the transaction body, but also the derivation path of the signing key you expect. And then they produce the signatures cross going to do his path. **Kevin Hammond** - Yes. **Matthias Benkort** - So I guess the API here could be extended in that direction to say... Well, you take also a list of derivation path and you make sure that you can produce a signature for them. If you don't provide that list, then it's up to the wallet to figure out those keys needed for a single transaction. **Kevin Hammond** - Yeah. And then the question is, how does the Dapp knows the derivation path that it needs to have enough information [crosstalk 00:38:12] of it. **Matthias Benkort** - Not necessarily. But yeah, okay. Because it's internal details of the wallet in here. **Kevin Hammond** - Exactly. Yes, don't want to [crosstalk 00:38:24]. **Matthias Benkort** - But ideally, wallet can probably figure out the signature already. **Kevin Hammond** - Sorry? **Matthias Benkort** - I mean, if you need to sign by a staking key, then surely there is something in the transactions that identified as staking key, right? It has to be in the required signature of the transaction. **Kevin Hammond** - Yeah. That's right. I can identify what I have is information about the public. I have the public stake key hash. I won't have the stake key itself, I think. **Matthias Benkort** -Yeah, yeah, of course, of course. **Kevin Hammond** - So I'll need [crosstalk 00:38:57]. **Matthias Benkort** - But, so a wallet that's receiving this transaction for signing through this CIP 30 API, right? **Kevin Hammond** - Yes, correct. **Matthias Benkort** - It's received the whole transactions and there is some point in a transaction, something that says you need a signature from that key hash. And that key hash is known of the wallet because it's a state key. **Kevin Hammond** - Yeah. Correct. So as long as I identify the fact that I need a signature from that key hash, as long as the wallet can then determine the derivation path from that, then that would work fine, I think. **Matthias Benkort** - I think the current API is fine. What we maybe need to enhance that CIP is a list of test vectors with a specific test case, where you can actually provide a transaction that has a staking key as a required key hash signature, and the resulting signature contains witnesses for that stake key. **Kevin Hammond** - Right. **Matthias Benkort** - And as we make sure that wallets that implement that CIP would have also to satisfy the test vectors and that's it. **Kevin Hammond** - So I propose is why don't you and I take this offline materials with the IO, we can discuss this with other people and why io wallet team, and then make sure that we have something concrete to this committee. **Matthias Benkort** - Yeah. And then make a proposal out of it. That will be fair. **Kevin Hammond** - Yeah. That seems to be the correct presence. **Matthias Benkort** - Okay. **Kevin Hammond** - Thank you. **Matthias Benkort** -Fair enough. => [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review #### Moving Editors Call Meeting 41 to US time zone **Frederic Johnson** - Do you not consider maybe the rest of the time for discussion regarding moving to a US time zone for the meeting or to try something like that? **Matthias Benkort** - Yeah. Maybe, to be a bit more on the process. There is also one thing I would like us to give a thoughts, maybe not in this current meeting, but that is for you, Fred also, and other editors I will reach out, but we have 12 issues open on the repo. So it seems that people are using issues to discuss things. And it's something we are actually, we haven't included the part of the process currently. Right. So we had issues and no one is really taking care of them at the moment. I actually just noticed last week that had so many issues because I was so far focused on the pull request when it comes to the CIPs, but there is a fair amount of discussions happening in issues, which is interesting. Right. We never really stated that as part of the process, but it just happened organically, I guess. And maybe we should start also, including issues, issue triage as part of the editors meeting or spend some time offline to go through them. **Frederic Johnson** Yeah. I agree. I've seen those grow and I think that it's good that we're actually paying attention right now as they've pretty much propped up functionally like the past few month. And it's a matter of just keeping on top of it, the same with the labeling of the issues right now. So I think this is all project management really, Maria is going to be able to cover a lot of that ground. I think that's like a new added step. I don't want to overextend a little bit into committing to too many things, like too many meetings and covering issues and adding too many PRs, just because a lot of that is functionally being offloaded mostly to Maria. And I'm just thinking that if we're doubling the meetings, it might be something, have you also coupled with other people that are involved in transcribing the meeting notes and everything like that. **Matthias Benkort** - Yeah. Sorry. I was not actually implying that. We shouldn’t double the workload for Maria as well on these US based time zones that I'm actually thinking that the US crew could be possibly different from the European crew. I don't mind bridging the two crew for now, but for sure for the US base, we would Robert onboard and maybe we can also have someone that help with notes and whatnot. Or I can take that. I can take that part maybe on me and let Robert conduct the meetings for the US based one. And there was also the question of recruiting more editors, getting more people on board. So maybe we could start discussing an actual approach to that. How do we get people who join us and help us with that task? Maybe that would be interesting. **Frederic Johnson** - I agree. I think we have a meeting like that coming up with Maria on the side of the retrospective, every 10 meetings we have that, I think that's totally a good place to have that. If you want to try something regarding US time zones, what our propose is that we do something at 10:00 a.m. PST, which equates to, I think like 7:00 PM your time. So Maria and yourself, I think both of you are in the same time zone. If you're able to do a 7:00 PM meeting, that might be an option. But I don't know if we want to do that for the next one or for like 42 or something like that. **Matthias Benkort** - I would like to try for the next one. Definitely. So next week have that up. That will work for me if it works for you also Maria, or I can try to take some notes on that. **Frederic Johnson** - Can we try the next biweekly one? So in two weeks, rather than one week. **Matthias Benkort** - Oh, so you mean to move the next biweekly as a US based? **Frederic Johnson** - Yes. Just the next CIP meeting because those meetings are biweekly. So every two weeks, so the 40th right now is up on Tuesday. The next 41 will be in two weeks and it will be happening functionally at a US time zone slot. **Matthias Benkort** - Yeah. Okay. Okay. I guess it's also maybe fine for even European time to be at 7:00, because I imagine if people are also not joining because they just have work to do at 10:00 AM and maybe it's more convenient to join at 7:00. **M. Àngels Jover** - Maybe that's right. **Matthias Benkort** - So maybe it's also all better for even European time zones. **Frederic Johnson** - Yeah. The only **M. Àngels Jover** - Maybe we can test it and see how it goes. **Matthias Benkort** - Yeah. Yeah. Test for a couple of weeks. So last time I asked on Twitter actually, a bunch of people, it was pretty much 60%, 40% that there was a lot of people I wanted to have meetings in the US time zone. So I was out of like 400 people. That's still a fair amount of four segments to join. I imagine I'm not sure how about the actually distribution. It's all the people that answer "yes, we're actually in the US', or even if there were some European that were interested to have meetings at the US base time zones. But yeah, maybe let's try it, let's have the next one in, at 6:00 UTC. Right. And I don't know the time zone, like the UTC to be franc, but it much easier for me to think just in UTC time. And that that would be... **M. Àngels Jover** - The 15. Right? **Matthias Benkort** - Yes. **Matthias Benkort** - 6:00 pm UTC. **M. Àngels Jover** - Do you want to do a wrap up of what we have for next meeting? So we have PR 153 that you are going to do Matthias some github clean up and it will be ready to go and can be merged before next meeting. PR 160 also is ready to go and can be merged. Then for next meeting, we will have PR 148 for last check. And then we have a pretty busy review section. We will have PR 215, 208, and 200. And we are waiting for Rob answering 211 in order to identify phase one. If this is done, you are going to merge it asynchronously, right? **Matthias Benkort** - Yep. **M. Àngels Jover** - And we have on hold, all the collateral PRs that we want Sebastian to be commenting on them. **Matthias Benkort** - Yeah. Work us through the changes. Correct. Okay. Thank you. **M. Àngels Jover** - Perfect. Thank you very much. **Frederic Johnson** - All right. Thank you everyone. ### Close => Merged as CIP15 (draft) [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) waiting for Rob answering 211 in order to identify phase one => Hold on [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) put on hold and waiting for Sebastien to discuss it => Hold on [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) put on hold and waiting for Sebastien to discuss it, possibly removed as duplicate => Merging it [PR153 - Fair min fees](https://github.com/cardano-foundation/CIPs/pull/153) this PR has a weird git commit history so Matthias will clean up the history to keep only the last commit that is actually the change proposed by the PR (moving it to proposed) and proceed with merging it => Hold on [PR159 - CIP-31: Reference inputs](https://github.com/cardano-foundation/CIPs/pull/159) moved from draft to proposed => Merged [PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) => Hold on [PR148 - CIP-0030: update to api.signData()](https://github.com/cardano-foundation/CIPs/pull/148) moved to Last check for the next meeting => Hold on [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) put on hold and waiting for Sebastien to discuss it => Hold on [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) moved to next meeting for review => Hold on [PR208 - CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) moved to next meeting for review => Hold on [PR209 - CIP-0030 Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) moved to Review --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 33 | [Reference Scripts](../CIP-0033/) | Draft | | 34 | [Chain ID Registry](../CIP-0034/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-03-15.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [March 15 2022 Transcript](#march-15-2022-transcript ) * [Triage](#triage) + [PR160 - PR160 - CIP-32: Inline datums](#pr160) * [Last Check](#last-check) + [PR148 - CIP-0030: update to api.signData() ](#pr148) * [Review](#review) + [PR200 - Add support for Catalyst multi-delegation](#pr200) + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208) + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209) + [PR215 - CIP-35: Plutus Core Evolution](#pr215) * [Discussions](#discussions) + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218) + [PR222 - CIP-42? | New Plutus Core built-in dataHash](#pr222) + [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](#pr220) + [CIP-45? | Decentralization: Using Pledge as a Bidding Param](#pr229) * [Close](#close) ## Summary Rough transcript of 15/03/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-40) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. ## March 15 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, ~Sebastien Guillemot~, Frederic Johnson, Robert Phair. ### Triage #### PR211 [PR211 - Add reference implementation for CIP15](https://github.com/cardano-foundation/CIPs/pull/211) **M. Àngels** - Hello. Welcome everyone to the CIP Editors meeting number 41. This is the first one that we are holding in the United State time zones. The idea is to hold those meetings bi-weekly, and we will do one in United States time zone, which is today. And in two weeks we are going to do it in European time, and we are going to alternate those meetings since now on. And well, my name is M. Àngels Jover and I work as project manager at the Cardano Foundation, and I am here to facilitate this meeting. At the top left, you can find the agenda for the meeting today, which I will share with you now. And today I have the pleasure to introduce you to our editors, which is Matthias Benkort, **Robert Phair** - and Frederic Johnson. Well, first of all, I would like to check with you editors, if there is any long lasting item that needs to be follow up and it's not on the agenda. **Robert Phair** - Checking now. Okay. You said the agenda is in the upper left? The "I" button. I see. Yeah, there's an "I" by the main title. I just had a question, if there's a process for dealing with issues that get submitted against the CIP repository? Because I've never really known how to jump in with those. **Matthias** - Yeah, so. That's something we mentioned in the last meeting actually. **Robert Phair** - Right. **Matthias** - I was just noticing also that there are, quite many issues being created by people. So as for your question, no. We don't have any process with dues, so to speak. So, I think we should start including them on the CIP editors review maybe, or just, yeah. Start going through them asynchronously and try to resolve them. **Robert Phair** - Yeah. **Matthias** - So, some issues can be resolved pretty fast, right? Because they are about the updates on existing CIP or minor adjustments, and some are actually discussions. Proper discussions of people at thoughts, or seems to want to push up the CIP, but they not know necessarily in all the details yet so they stop with an issue, which I think is also fine. Some people do that on the forum as well. Not sure if we should favor one or the other way. But, let's maybe just start going through those we can address immediately and keep the other one for the CIP Editors Meetings. **Robert Phair** - Sure. **Robert Phair** - And I know that Kevin also posted a suggestion that they not use the next CIP number. I noticed a couple of them actually came in with the CIP as a flat file, rather than in a sub directory. So there were other types of naming conventions, not just for the files, but for the directories themselves. So, I was thinking that maybe a paragraph about that format could be added to the CIP one, or maybe the read me of the CIP repo itself. Just to tell people to put in a directory, to tell people to satisfy the naming convention of the CIP number in whatever way that we agree upon, but maybe another could be added to settle on those questions. **Matthias** - Yeah. I think we could even do with a small continuous integration check with that. If you submit a full request, it's got checked by editor scripts that make sure you've got the right format, but yeah. Adding it to the CIP one, definitely. We have also CIP templates, which may be up to date, because it's also at the root of the repository. So, maybe having an example folder, which shows how CIP should be structured. **Robert Phair** - Okay. **Matthias** - I did some addition to the read me also last time. I got to discuss that a bit with Sebastian, but we didn't come up with an agreement so far. But this, I think should be more on the safety one, right. It really about a process itself and the CIP. **Robert Phair** - Mm-hmm (affirmative). **Matthias** - Mm-hmm (affirmative). **Robert Phair** - Sometimes the CIP drafts come in on the Cardinal forum first. So, it would be nice to be able to link to the section of that document, and just post it in the forum, so that people can go over the material, and edit it before they submit it as a PR. **Matthias** - Yeah. Yeah. So we can get a section easily if we just put a title. Then with the link we can refer to. **Robert Phair** - That would be perfect, yeah. **Matthias** - So also a quick reminder for anyone in the chat. If you have specific questions, also you want to ask, there is this ask question feature on chrome cast. Don't hesitate to use that. So, at the end or somewhere during the meeting, we can go over the questions that were asked. But, it's sometimes hard to see all the questions in the chats. So, exactly. Okay. ### Last Check #### PR160 [PR160 - PR160 - CIP-32: Inline datums](https://github.com/cardano-foundation/CIPs/pull/160) **Matthias** - Should we start with the first item on the agenda CIP 32, tentatively? I think it is... It was just a last check, right? This one. Because we did review it last time and it was just making sure that there was no final questions on this one. It's also on... Yeah, Implementation I think has started, and has been planned for that one. So we should be able to move it to the other stages later on. But as a draft, it's also fine. Been discussed, reviewed, been through a few changes already. We're good to go. Yeah. Robert also commented already weeks ago, so they just merge it. #### PR148 [PR148 - CIP-0030: update to api.signData() ](https://github.com/cardano-foundation/CIPs/pull/148) **M. Àngels** - Nice. So, in last set we have PR 148, an update to API signdata(). **Matthias** - Yeah. So what's the latest status on that one? I did ask for Robert to update... **Frederic** - I think at the bottom of this one, there was a request to... never mind I'm actually looking into the 200 and 148. I think 148 was good to go. The conversation has died down between Sebastian and one of the other editors on there. **Matthias** - Yeah. I cannot load it somehow. Okay, now it's good. It was a change of the address signed data. Yeah. Yeah. And there was also a bug discovered in the email edition that was fixed. So, I think that one is good to go for last check. There is a last comment from someone, but I actually don't get it. He's talking about adding a content type, arguments, or I could try to display the message being signed to the user. Generally speaking to display messages, to sign for users, it's a bit more complicated. Plus you need to have some comprehension of what the app is actually doing, the kind of scene. Which is probably something better left to wallet implementers and not put in the CIP itself, not putting the interface. If a wallet wants to show SundaeSwap or ADAhandle, or whatever that they're injecting with some specific details because they understand the problem, and how that is working, that's up to them. Probably a good marketing argument for wallets. So yeah, I would say we can move this one to last check from next round. There is no issue. It's already last check actually. **M. Àngels** - Yeah. **Matthias** - So that's why we already did that discussion last week, 2 weeks ago. So, okay, then what's the problem? There is CI failure. Because probably the headers is wrongly formatted or something like that. But did Rob changed actually? It didn't change the headers, so. But if I say what build fail, blah, blah, blah, cannot fit properly much of undefined. Ah, yeah. Okay. That's one of the thing we fixed two weeks ago, but the pull request hasn't changed since then. So, we need to revise it on later on the master and it should work. Okay. So, I can just do that and we can merge that one on the go, unless objections. Part, you follow these stories a bit or not much on your side maybe? **Matthias** - Robert, you still here? If you speak, you're muted. **Robert Phair** - Sorry. I was muted. OK. **Robert Phair** - I was wondering why nobody... I knew you were looking for something from me. Okay. Yeah, so following the stories on those... the technical issues are fine for me. I just... **Matthias** - Yeah. **Robert Phair** - Which one in particular were you talking about? Just so I'm sure. **Matthias** - Yeah. Just the CIP 30 addition for sign data. There was a few changes to the existing CIP 30, to make sure that you could sign arbitrary data, and that change also included a change on the address format, that you provide to the CIP 30. It used to be basically HEX encoded addresses in simple format. But now we just pass a vector 32 strings, which is more consistent with how addresses are usually manipulated on Cardano **Robert Phair** - I've been reading the comments, but they've been above my level. So, that's not my place to make any objections about it. That sounds good to me. **Matthias** - Okay. And then we'll just have maybe Sebastian to vote on that. But, I think he was also on the same page. Okay. So we'll just re base the pro request under most recent changes, which should fix the CI failures, have the checked class, and yeah. Keep going. **M. Àngels** - Good. So shall we move to the next one? **Robert Phair** - Yeah. ### Review #### PR200 [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) **M. Àngels** - Okay. We have a pretty busy review section. So, first one is PR 200 Add support for Catalyst multi-delegation. I would like to ask you, before we deep dive in the details, if you could do a brief summary of what this PR is about. **Matthias** - Yeah, of course we can do that, as we often do. So yeah. This one, which is PR 200, it came after another report request, right, which was PR188. And so, 188 was updating and existing CIP, CIP 15 to add support for registering multiple keys, as part of the catalyst voting process. When discussing this first update, we thought that it would be better to have it as a separate CIP, which is an extension of the existing one. Because it was quite substantially modifying the existing CIP, which makes it basically a completely different one. That was more appropriate to make a separate, which Mark did. And yeah. So the spirit is really to say, enable people to register multiple CIP's, with their catalyst registration votes, such that behind the scene, that can enable multi delegation, and therefore multi votes within the catalyst process. Right. I think we have also Kevin here on chat. So you could definitely... **Frederic** - And at the same time, Robert just posted the notes for the meeting 40 that were merged. That was two weeks ago where we discussed this one briefly. **Matthias** - Yeah. **Frederic** - So, this pool request, I think has reached equilibrium. It just needs some extra derivation path that Kevin pushed in the comments. But, I think that Mark stop had the initial lot of this PR and is currently away. So, it's really a matter of either we merge this in without the path as draft for right now, or we wait for Mark to come back, and adjust it, and then we move it back to review. I don't know how you want to proceed on this. **Matthias** - Yeah, we can probably also do the change, and add the change to it. Ask Mark for a review agreement. I think there was also a question of mentioning the original author of the PA, the update. Not sure if it was done, but I remember that from our last discussion, to just give credit to the original submitter, who was, who? Yang. Yeah. So, that there is no conflict. That everyone gets credited for their work, in this little other addition. And then, yeah. So, we could maybe do that. Flag maybe Mark for a second review, and then get it merged as a draft. I've understood that this is being also worked on in parallel, in terms of implementation. Yeah, of course, Kevin. That's what I'm saying. There was this... Yeah. Rewriting the history to include Giacomo commit. I still have it on my tool to do here. It's a suggestion [inaudible 00:15:30] want team? Yes, indeed. And in terms of implementation, was anything I started on that could also help us move the CIP into maybe proposed at some point, there is a clear implementation path? The question for Kevin. **M. Àngels** - Do you want me to bring him on stage so you can have a conversation? **Matthias** - No, maybe not. I think we've said it all. I'm just giving you one to come and say something. **M. Àngels** - Okay. So to summarize it, we are going to flag Mark for him to review, and if it's okay for him, it is going to get merged, right? **Matthias** - Yeah, we'll put it as Last Check for next time. And yeah, next time merge it if there is indeed nothing also surfacing. **M. Àngels** - Good. **Matthias** - Yeah. So I will add the change actually to the CIP itself, these little comments, and then ping Mark about it to make sure that he is also in agreement with that change, which is more of an addition than an actual modification. It shouldn't be any problem. **M. Àngels** - Good. So if Mark agrees, I can put this on last check next meeting? **Matthias** - Yeah, definitely. #### PR208 [PR208- CIP-0030 Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) **M. Àngels** - Good. So let's go to PR208- [CIP-0030] Adding getCollateral function to the connector API. Would you explain us, Matthias, what is this about? **Matthias** - This is another extension of the CIP30, which is the adapt connector that is providing this interface between wallets and DApps. And this is about adding a function to get, or ask the wallet for a collaterall. Collateral is something that was introduced with the Alonzo Hardfork, which is necessary every time you want a transaction to execute a script. So the collateral has some special hold, right? It's an input of the transaction that is only spent and consumed if the transaction is failing during the script execution, which normally doesn't happen because you have plenty of ways to find if the transaction is correct before submitting it. But still, you have to put a collateral on that. And that collaterall is a special input because it must not be a script input, it must be ADA only. So that means for that it's quite practical to have way to just ask the wallet for such an input. Say "Don't give me any EUTXO, but give me a EUTXO that satisfies all the collaterall preconditions." So yeah, that's extending the CIP30 in that way. Which, the CIP30 was treated before Alonzo. So it doesn't contain a lot of the details or the function necessary for actual DApps integration. And this is one of the few one that we'll get in. With a simple addition, semi-function, you get it as it's shown here in the mounts. And once you get back, it there is a EUTXO it's a satisfying condition. Or nothing there is no EUTXO that will satisfy this condition. **Frederic** - So if you check the conversation on this one, you can see that this is actually the one that I was discussing earlier when we had that conversation with Sebastian, and they seem to have [inaudible 00:19:13] that agreement on the work on this. So it seems as though it's ready to move forward. **Matthias** - Yeah, there is also a good comment from came in on the chats. CIP30 is at the center of many, many things at the moment, many, many decisions and changes. There is this notion of versioning on CIP30. So in principle, every new changes should come up with a new version number change, so that DAPP's and wallets can properly negotiate between each other which version of that CIP they already are using. And not quite enforcing that at the total level yet. Maybe we should start doing that a bit more, doing that structure a bit during the evolution of the CIP. [crosstalk 00:20:04] with addition of other things, of course, addendum to existing CIP. It's a bit like we've done for the wallet things. **Frederic** - So functionally, or structurally it makes sense to move this into a new CIP as a whole. Like for example, CIP37 and then have that one supplant CIP30. **Matthias** - That's not really supplanting, right? Because it's just an addition. So everything in CIP30 will still apply, but then you have this extension that you may or not support as a wallet. But from the usability perspective, if you are a DAPP integrating your wallets, you don't necessarily want to have a list of all the things either wallet supports, but more like a version number. Actually, a list may also be relevant because a wallet might support this and this as features, but not these wallet features. And a version number would suggest a kind of sequentiality of CIPs, which may not be the case. So yeah, all that to say, perhaps better move to support CIP, have that as an addendum that refers to CIP30 and... Have the wallet then, let's be that integrating what kind of CIP's they support as extensions. That in itself would be a change to CIP30 also. I'd like to propose that. **Frederic** - So the changes you propose is that we move this one as a standalone CIP being an addendum referring? I'd be okay with moving this into Last Check as is. **Matthias** - Yeah, moving it as a last check, but also making it a separate CIP indeed. Just try not to overload too much the CIP30, but start integrating new changes to that CIP as new CIP's, the same way we sort of removed at the time this [Evant API 00:22:05] and put it out of scope on the CIP13's, and we move that to a separate proposal. Do the same thing here for that one, and I think also having a new function as part of the CIP30 interface, for wallets to return all the CIP they do support, like all the extension they do support. So for DAPP integrating with the wallets, they can just ask the wallet for that information and know if this or this feature is available. Although I guess it's also part of the wallet documentation maybe. If you're integrating with this or this wallet, you should know if they support the feature. But it makes it a bit more automated in that sense, so... Yeah. **M. Àngels** - So the idea is to move this to Last Check for the next meeting, but as a new separate thing, as an addendum to CIP30. Is that right? **Matthias** - Correct, correct. Next one- **Robert Phair** - I think this also, just before we move onto the next one please, I think this also resolves a longstanding question we had about CIP13, where there were one or two suggestions to add something to the Cardano URI scheme last year. That just kind of lost some momentum because the people who submitted those PR's didn't drive them. But ?? and I were talking about how to handle a document that might actually get a lot of additions to it. So in the future, maybe if those issues come up again, I would suggest that they be dealt with in the same way. If someone wants to add something new to the URI scheme for instance, they could submit a new CIP rather than a modification to CIP13. If that's okay with everyone. **Matthias** - Yeah definitely. Yeah, I agree with the original idea. **Robert Phair** - Sure. **M. Àngels** - And how, maybe that's a stupid question, but how we can let the creators of the PR know that they need to create a new CIP instead? **Matthias** - We'll comment- **Matthias** - We'll comment on the workplace. And in that case, the creator is Sebastian. We'll just ping him directly. #### PR209 [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) **M. Àngels** - Yup. Okay, PR209 - [CIP-0030] Adding optional networkId parameter to .enable **Matthias** - So that's also modification to the CIP, but this one is an actual modification which could go as an update as CIP30. It's small enough and it's modifying one of the existing functions. Okay, so this is about inquiring to enable only a specific network. Through the wallets? I would be curious to know the rationale behind that. It allows the DAPP to specify which network it operates on, so the wallet forces the user to only connect to wallet accounts on that network. Example, that [inaudible 00:25:18]. If not specified, the user is free to select any network, and the DAP must be able to handle it then. Okay. That kind of makes sense as it is, with this. Sebastian says "I would prefer if we instead used CIP-34 instead of just passing in a network ID otherwise this will cause issues if Cardano ever has >16 network IDs reserved (which is entirely possible in the future). Probably that should be done in parallel to deprecating the getNetworkId and replacing it with something that returns the CIP34 string" Yeah. CIP34 was a CIP proposed by Sebastian to have a uniform chain ID that is uniform across block chains. So there is a standout which is used on Bitcoin, Ethereum, I think Solana as well, which specifies a certain format that identify a network across over to the possible blockchains. So Sebastian, "We're applying to one that would work for Cardano, which envelops both the network ID, the genesis hash, network advantage, and that could be used instead of just zero, one, two, three and blinds integers as a means to specify the network." Which I do agree. That makes also a lot of sense. So... Yeah. I will comment on the progress exactly with that. And then we can go back to reviewing it again next week, if we have any update from the others from last time. **M. Àngels** - So we are going to review it again next week and get feedback. #### PR215 [PR215 - CIP-35: Plutus Core Evolution](https://github.com/cardano-foundation/CIPs/pull/215) **Matthias** - Yeah. That's the one proposed by Michael about... Giving a [inaudible 00:27:33] process to, yeah, propose changes to Plutus. Right? So it's a bit of like a process on top of the CIP's, which specify all the different steps people will have to go through to get something implemented inside Plutus, which is a very interesting proposition by itself. It would be nice to come up with something like that for the ledger, or the consensus, or every part of Cardano, basically, and to have a clear path of how you can get an ID from a CIP in proposition, into actually being implemented into protocol by the team. So Michael gives a full process for that, which is very sensible in my opinion, that we have also been following in the proposal already, but having two proposals on top of that. On top of that, currently under discussion process. But the general idea is to say, well, you make a CIP, that explains good rationale, explains what you are going to change, and I've come also with proof in a way that what you are doing is correct. So they don't necessarily ask for people for doing the implementation, but at least you have a rationale and an idea of what will be the impact on Plutus. For instance, if you claim you want to add a new built-in, then you should come up with a cost model of that built-in and explain why it works, or what would be the impact on the loan implementation and so forth. So that way the team doesn't have to do all that work, and can basically just verify that and then go on with the discussion right away. So it has also divided the different changes in multiple categories, explaining whether the changes would require a new Plutus version, a version of the language, or a hardfork, or if the changes can just be done in a fast forward way because they are just backward compatible. So it's pretty complete in terms of information, I think. So, yeah. **M. Àngels** - So do we want to do it with this one? **Matthias** - That's a good question. I mean, it's been already used kind of, by at least two other CIP's as a baseline for proposing changes. There hasn't been any comment on that one, which suggests that no one was in disagreement with the process. I think it's fairly well explained. So yeah, I will be all for moving into Last Check next time. But as far as I'm concerned, the process is clear. The CIP check all the boxes. And yeah, it is not a CIP that would require an implementation, because it's just describing a process. So I would even actually move it as active right away; the rationale being that it's pushed by one of the co-member of the Plutus team. And therefore, we have the implicit agreement that the team is also already okay with that CIP as a process for driving the Plutus implementation. What do you think about that, Fred? **Frederic** - I think moving it to Last Check and the push to active is fair. I mean, there being the but it sounds like if Michael's behind the PR, it kind of invites it, pretty much. **Matthias** - Yeah, exactly. **Frederic** - And Last Check for next meeting. So then Sebastian is going to be able to jump in and do a certain look-through. **Matthias** - Yeah. **M. Àngels** - Good. So that was what we had in our agenda. **Frederic** - Uh, going back on this one is a minor conflict regarding CIP numbering but that might be... Which is that we have some conflict going on with the numbering. But 35 has been taken over and a few people are complaining that the allocation of number directly to the next available number is difficult so I suggest we just move this one as steady and request the other one which has whichever next number that is [inaudible 00:32:33]. **M. Àngels** - I don't know the other people but Fred I just lost the half of what you were talking, So, I understood the conflict with... To move and the number 35 and then you wanted to push another PR to another number. And this is what I didn't get. **Frederic** - Yeah. **Frederic** - You should go in the conversation for CIP 35 pull request 215, and scroll down to the bottom. There should be a link that CIP identifier is crashing with PR 137. **Frederic** - And yeah, Michael just commented on this and, editors are responsible for taking numbers. In this case we have to move the other one. **Matthias** - Which goes back to pull requests I was mentioning this week. Well, I have taken a read me and try to guess basically the, a table of proposals under review. Follow the read me, with preallocation of those CIP numbers. Which should give us a bit of organizational. That means we would have to maintain that table, which I think is fine. We don't have to maintain it more often than once every two weeks. So every meeting we could go over this. Proposals under review, make a little update so that we meet you... To get them. **Matthias** - Side benefits we also get from that is, that table becomes part of the read me, which is the front page of the CIP site. Which means that it gets easier for people to browse through a distant CIP without having to go through the pages of full requests. It's a bit more comprehensible so review CIPs under discussions and get maybe more people to contribute. **Matthias** - And in that case, the Plutus core evolution, I've already pre-located that one the number 45. And I think other one, request number 15, I moved it as another unused number. So... **M. Àngels** - So, it should be good right? **Matthias** - Be good. Yeah. **Frederic** - On that, I do think that this adds significant overhead but I don't know if it's really necessary but it sounds as though this deal it is. So, very open to that conversation. **Matthias** - It does have a bit over our heads. And that's also Sebastian's concern when I discussed the PR within. I don't mind maintaining that list. And as I said, I don't think it has to be more often than every two weeks. It's not as... It's not a big cost overhead anyway. It is PR number 227, which I put in the chats. Right, so Robert already chipped on it. Think we're also in agreements. **Matthias** - [Foreign language] changes. Sorry for my French. And feel free Robert to push any of these if you want. **Matthias** -You should have the right access on this pull request I haven’ t forbidden people to add comments on top. **Matthias** - So yeah, if you can look at the file changes this so you can have it on... Maybe. **M. Àngels** - Where? **Matthias** - Just a small, small explanation of what exactly the CIP process is, otherwise we will have confusions. And so put this little table proposals on reviews, which clearly explains that these proposals are being discussed but they are also for pre allocating the numbers. And I also added the editor lists from that file because I got the question several times from people who wanted to reach out to the author and they did not easily know that they had to look into CIP 1 to find the lists. So, I put it back in. It should be... So now, yeah. With that, we should have all this information regularly available on the website front page. **Robert Phair** - I have just one question about the naming issue. Sorry if this is already covered in one of the meetings I wasn't at but... Because I did try to read all of this stuff. Is there a reason why people need to choose CIP numbers when they submit their original PR or could they just have CIP dash some name that's their content for CIP. **Matthias** - No, no, that's the point. They shouldn't have to pick a number and the editor should do it. **Robert Phair** - Okay. Okay. **Matthias** - And that is just a way for us to get organized with that. And just advertise it, on the front page. **Robert Phair** - Right. So the naming collision is only then because people thought they had to pick a number? Even though they were never told to- **Matthias** - .. Yeah. **Robert Phair** - ... [inaudible 00:37:44] page. Got it. **Matthias** - So that could be a probably little addition to CIP 1, where I mentioned earlier. We also explain the process of submitting the CIP so you don't have to pick a number you just put XX or dash dash. The offer will put something, the editor will come up with something. **Robert Phair** - Yeah, that's just what I was hoping for, thanks. **Matthias** - [00:38:10] Okay. So Fred if you are okay also with that little change, we can get a little bit more organized on the number allocation, which also answers Kevin's concerns from earlier. I hope Kevin. And so yeah, CIP 35 currently, the Plutus core changes, I think it can stay as CIP 35 and as we say move to last check for next rounds and move everything to active. It's proposed by the co-team so there is no reason to, yeah. Just put it as draft proposals. **M. Àngels** - Okay we are talking about PR 215 Plutus Core Evolution, right? To move it directly to active. **Matthias** - Yeah, yeah. You can tell Michael to put this little change or just push it ourselves. And move it to last check meeting so that we have the ability to just have Sebastian also chip on it and tell us if he's against or voice concerns but I don't think that would be the case. And good. And then we can only encourage the other teams to do the same. So that we can move forward with other co-changes as well. ### Discussions **M. Àngels** - So this was all for today that was planned? Do you want to review some specific PR? Maybe some, all of them? **Matthias** - No. I haven't got a lot of time to look at the PR recently. There a few new ones but... Not something we will do right now probably. Unless someone someone has something to bring in as well. Or, sell as built in data said Sebastian. So, yeah, that's one of the PR 215 which is based on the Plutus Core changes proposal. I would maybe keep it for next time, this one. In the next meeting, so that once we have the Plutus Core Changes validated we can start looking at the proposals on top. And we can get quick review as well from, for it right now. Yeah, if you want to bring it on screen. **Matthias** -Probably PR218. **M. Àngels** -[00:40:52] Fred, you were saying that you need to drop? **Frederic** - Oh, no I thought that you wanted to bring in Sebastian on screen and was proposing to drop. But, if you really don't recommend about them. **M. Àngels** -[crosstalk 00:41:07] Is here? **Frederic** - Sebastian Michael. **M. Àngels** - Oh, okay. **Matthias** - If [inaudible 00:41:15] speak. **M. Àngels** - So, Sebastian do you want to speak? #### PR218 [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218) **Matthias** - Not sure, just showing. So I can also cover this CIP, we co-wrote this with Sebastian, pretty much no worries about that. ll basically, speed up a few things we have as part of the Hydra development. If you built any functions that we can use from within and on on-chain scripts and the goal of A is to be able to sell some data into some binary digests so that you can use that as a pre-image for hashing on-chain. We currently only have on-chain built in for hashing stuff but I suppose you can produce some binary data that you can hash and this process is exactly about that. It's adding a built-in to produce some serialization of any data type in plutus. We've been discussing that with the team as well. The implementation actually has already started on this [inaudible 00:42:34] so we should know quite soon if it's actually working okay in terms of performances and what will be the cost model for that addition. And yeah, so the proposal was based on this CIP 35 following the different Plutus steps. And yeah, that's about it. So I guess depending on the outcome of the implementation of what's going on, on the Plutus call, we can probably also move that CIP right into active. Because if it's already getting implemented it gets done, it gets validated then there is... We will have proof it has been active. According to CIP 35 again. **M. Àngels** - So... in order to move it to active right now we have... I mean there's a lot of discussion even though this is new. **Matthias** - Yeah, I'm not moving to active right now. But depending on the outcome of the Plutus Implementation which is still ongoing. So for now, I'm simply moving it to review for the next meeting. **M. Àngels** - Okay. #### PR222 [PR222 - CIP-42? | New Plutus Core built-in dataHash](https://github.com/cardano-foundation/CIPs/pull/222) **Matthias** - And at that time we will reassess what's the status. I just wanted to give a little status update on that one. Knowing that there is a conflicting proposal in a few months that was opened also right after. I think, yeah, which is PR 222. Which is also adding a new built in. But this one instead of providing a built-in to seriesalize any data, it's a built-in to directly compute the hash of any data. So it's all bundled together, the sale-ization and the hashing with the rationale that in most cases that's what people want to do. If you want to sale-ize on chain, this is for computing the hash, which is where I think we disagree. **Matthias** - That means, both proposals can also live side by side and it will be up to the Plutus team I guess, to decide on which one that gets implemented eventually, if any of the two gets implemented. **M. Àngels** - Because it's one... That they are conflicting within each other. **Matthias** - They are competing with each other because they are targeting, overlapping in terms of the features they provide. One is a bit more generic to the previous one, and this one is really tailored to a particular use case of computing the hash on-chain right away, which according to the author is arguably what's treat will always want to do. So yeah, there is slight disagreement I guess on this always. And yeah, so they will be competing in the sense that they can both be proposed as two Plutus core -evolutions and then following the process describing CIP 45, one will get implemented into Plutus, the other one probably not. But there is no problem having two overlapping built-in as part of the language, so I think the team will just choose one of them. And then we will be able to just either make one of the CIPs obsolete or if things happen before that just deprecate the complete CIP and not even propose it as draft. So we can move it to review for next meeting I think so that we have both and can compare and reassess the situation. And since we will also be in European time zone we will probably have Michael, someone from the Plutus team to chip in. **M. Àngels** - I think that makes sense to always review these two PR's together. **Matthias** - Yeah, definitely. #### PR220 [CIP-43? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220) **Matthias** - And since we are in CIP and Plutus changes, we could also look at CIP, what's the number? Sorry, PR 220, which is also about extending Plutus our co-changes. But this one with a new cryptographic primitives. This one was submitted by Migo, who is a cryptographer working at Input-Output, and he is proposing a new pairing mechanism on-chain, which is a full request for which we don't require some cryptographic expertise, which I don't think we have amongst editors. So we would have to find the right people for that one. So what had been discussed today it's... with people from [inaudible 00:47:39] I believe? And Michael I also see end dates. So, I think what makes sense to have this one for next meeting as well as the review. And make sure we have someone with the big cryptographic expertise that can go through the changes although Iñigo is already probably that person. **M. Àngels** - Are you going to reach them, Matthias, or do you want me to try to reach someone? **Matthias** - I'll try to see if we can find someone from DCSpark who might have people there that can help, just to have at least two cryptographers discussing on this matter. That would be interesting. **M. Àngels** - Okay. So let's move this to review for the next meeting, and maybe I will chat with you if you have the necessary expertise, or then we can wait until we have those expertise in order to review it. We have 10 minutes left. **Matthias** - Anyone from the chat? We had a question already which I answered on the fly. #### PR229 [CIP-45? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229) **Robert Phair** - I have one thing regarding the question of whether a CIP affects a mathematical or protocol design issue. We had another PR, 229 decentralization using pledge as a bidding form. This is a walk in from a mathematically oriented fellow. There's a CIP with a lot of equations. And honestly, I don't know if any of the editors would be able to address this. Is there a way to officially request that we get someone else to look at the CIP based on merit, or is this beyond the scope of what we're trying to do? Just lodge the CIP and then have it represent some kind of a standard that's independent of a mathematical evaluation. **Matthias** - So on these matters we try to get experts to chip in. Exactly what I was saying also with the cryptographic proposal, when we don't have the expertise within ourselves at editors, we fetch for help and people that can help us. That's been the case of few other CIPs in the past. First thing I can think of is CIP seven for the [inaudible 00:50:36] benefits proposal, where we reach out for researchers to have actually buy in the CIP or to be able to chip in on that. There is no formal process with that. This is something we've been discussing internally at Input Output, really trying to get this into a formal process. It's sometimes a bit hard to move the researchers also from what they are doing to this. But it usually requires to load back a lot of context regarding global laws and the game theory and all that. So the researchers are aware. From what I've understood, they have also started to work a bit on some of the CIPs. They don't have yet the time to put up a formal answer to a lot of them. Hope it'll come soon. And really I'm trying to get things in there to get things moving a bit. It takes time, but we'll eventually get there, I hope. And comment also with the process, that's what I was saying earlier. I wish maybe more teams would engage the same way the Plutus team has engaged with the CIP process, defining their own process to drive those changes. For other things, for instance, at Plutus, we don't have also the expertise necessarily to know whether a change is sound or not. If you are changing a part of the compiler or something that really involves deep language theory, there is no way we can review that fully as editors. So we'll always have to get back to the Plutus team and reach out to them and have their expertise on the matter, which is why Michael came up with this process. That's a way for them to explain how we can reach out. I want to have the same thing for basically every single part of Cardano, have that for the consensus, have that for the ledger, have that networking. That's something that takes a bit of time to set up. Hopefully we will get there. **Robert Phair** - What I did in this last case is invite the presenter to attend the meeting and see if he could say a bit about it and help us understand what it is he's getting at. And then maybe we can determine whether his ideas are presented properly enough to be evaluated at some future time. **Matthias** - As a editors, that's pretty much all we can do when we lack the expertise necessary to judge the actual content, but we can at least see if there are proper rational motivations, steps that explains what's happening, which is for instance, the case for Iñigo's proposal. From an editors perspective, it looks okay, but I'm not able to judge whether there is a sufficient amount of details that will allow another cryptographers to review it. Sean is saying it would be great to have a feedback process for parameter changes CIP. We're getting to the hour almost. **M. Àngels** - Would you like to do a quick wrap up of what you have reviewed, or do you want to… ### Close **Matthias** - Indeed, we did this last week and people appreciated that. We should do it more often. So we went through a few proposals this week. First one was in line. That one we agreed on and actually merged, so it's finally merged in the repo as a draft CIP. The implementation is ongoing, so we should be able eventually to move it to active. **Matthias** - Then we went through the CIP 30 addition, which is design data that was there already as a draft. And the CIP was adding a few specificities to it. It was clarifying a bit of documentation. We agreed also that it was fine, but the pull request was made a long time ago, and the repository checks are failing. So we first need to update this pull request to the latest changes, and it should be able also to be merged, which I will do after the call. Then we reviewed a few CIPs. So the first one was the PR 200, which adds the multi delegation support to catalyst, which should then allow to better split the voting on the Catalyst process. The limitation is also going on in parallel. The CIP has mostly settled. We agreed to move it to last check for the next meeting. Then we went through CIP 30 addition, adding a collateral function to the connector API to allow that to update itself. But we said to move it as a separate safety and to do that for pretty much any new addition to the CIP 30 to avoid loading too much to the CIP. So we'll go back and ask the author to do that. We should be able to move it to last check for the next meeting. Then we had another little update on CIP 30, which is proposing to add an optional argument to one of the existing functions. This one will also go back to the author to change perhaps the interface that is being chosen to avoid just using integers, have something a bit more structured and typed if they can. And finally the last one, we went and reviewed CIP 35 about defining a process for proposing changes to Plutus Core, which has been proposed by the Plutus team. Process has been already out for two weeks. There are already three CIPs that are based on these processes. So we agreed to move it to also last check for the next meeting and have it as an... **M. Àngels** - For review we are moving and the 218 and 222 that are on top of this review, right by that. **Matthias** - So all the changes based on this one will be moved to review for next week, but CIP 30 will have it as last check and merge as active right away since it's defining the process, and it's already backed by the core team, which makes it a good proof for activity. And we also discussed modifying the ReadMe, to get a list of pending CIP under review on the front page of the website also, and I have pre-allocated numbers to all existing CIP so we can get better organized within the number location. And that's the last, or did I forget something? **M. Àngels** - PR 220, which we will need cryptographer expertise that we are going to try to get. **Matthias** - So that's part of the Plutus score changes we'll review next week. And we'll try to get the help of a cryptographer on that one. I think Iñiigo, we would definitely be able to ask him if he can already join, maybe to work us through the proposal and have maybe someone, if not in the meeting itself, to at least be able to comment on the proposal itself. **M. Àngels** - Next meeting is going to be in the Europe time. So I was wondering if we should bring to the agenda all those collateral PRs that we were waiting for Sebastian to review. **Matthias** - That's a good idea. **M. Àngels** - So if you don't have anything else to add, it's the time already. Thank you very much everyone. **Matthias** - Thank you. **M. Àngels** - It's been lovely meeting, and we'll see you in two weeks in European time 10:30 a.m. CET. Thank you very much, and have a nice week. --- ## Extra ### Current CIPs in the CIP repository and their status | # | Title | Status | | ----------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- | | 1 | [CIP process](../CIP-0001/) | Active | | 2 | [Coin Selection Algorithms for Cardano](../CIP-0002/) | Active | | 3 | [Wallet key generation](../CIP-0003/) | Active | | 4 | [Wallet Checksums](../CIP-0004/) | Draft | | 5 | [Common Bech32 Prefixes](../CIP-0005/) | Draft | | 6 | [Stake Pool Extended Metadata](../CIP-0006/) | Draft | | 7 | [Curve Pledge Benefit](../CIP-0007/) | Proposed | | 8 | [Message Signing](../CIP-0008/) | Draft | | 9 | [Protocol Parameters](../CIP-0009/) | Draft | | 10 | [Transaction Metadata Label Registry](../CIP-0010/) | Draft | | 11 | [Staking key chain for HD wallets](../CIP-0011/) | Draft | | 12 | [On-chain stake pool operator to delegates communication](../CIP-0012/) | Draft | | 13 | [Cardano URI Scheme](../CIP-0013/) | Draft | | 14 | [User-Facing Asset Fingerprint](../CIP-0014/) | Draft | | 15 | [Catalyst Registration Transaction Metadata Format](../CIP-0015/) | Draft | | 16 | [Cryptographic Key Serialisation Formats](../CIP-0016/) | Draft | | 17 | [Cardano Delegation Portfolio](../CIP-0017/) | Active | | 18 | [Multi-Stake-Keys Wallets](../CIP-0018/) | Draft | | 19 | [Cardano Addresses](../CIP-0019/) | Active | | 20 | [Transaction message/comment metadata](../CIP-0020/) | Active | | 21 | [Transaction requirements for interoperability with hardware wallets](../CIP-0021/) | Draft | | 22 | [Pool operator verification](../CIP-0022/) | Active | | 23 | [Fair Min Fees](../CIP-0023/) | Draft | | 24 | [Non-Centralizing Rankings](../CIP-0024/) | Draft | | 25 | [NFT Metadata Standard](../CIP-0025/) | Draft | | 26 | [Cardano Off-Chain Metadata](../CIP-0026/) | Draft | | 27 | [CNFT Community Royalties Standard](../CIP-0027/) | Draft | | 28 | [Protocol Parameters (Alonzo)](../CIP-0028/) | Draft | | 29 | [Phase-1 Monetary Scripts Serialization Formats](../CIP-0029/) | Draft | | 30 | [Cardano dApp-Wallet Web Bridge](../CIP-0030/) | Draft | | 33 | [Reference Scripts](../CIP-0033/) | Draft | | 34 | [Chain ID Registry](../CIP-0034/) | Draft | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](../CIP-1852/) | Draft | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](../CIP-1853/) | Draft | | 1854 | [Multi-signatures HD Wallets](../CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](../CIP-1855/) | 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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-04-05.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [April 05 2022 Transcript](#april-05-2022-transcript ) * [Triage](#triage) + [PR217- Collateral reward](#pr217) + [PR104 - CIP-1856 | Collateral Key derivation](#pr217) * [Last Check](#last-check) + [PR200 - Add support for Catalyst multi-delegation](#pr200) + [PR208- [CIP-0030] Adding getCollateral function to the connector API](#pr208) + [PR215 - CIP-35: Plutus Core Evolution](#pr215) * [Review](#review) + [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](#pr209) + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218) + [PR222 - CIP-42? | New Plutus Core built-in dataHash](#pr222) + [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](#pr220) + [PR216 - CIP-40? | Collateral output](#pr216) * [Discussions](#discussions) + [CIP-47? | Proposal for open Daedalus or desktop wallet via URL](#pr234) * [Close](#close) ## Summary Rough transcript of 05/04/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-42/3) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. ## April 05 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. PR209 - [CIP-0030] Adding optional networkId parameter to .enable. **Sebastian Guillemot** - PR209 - [CIP-0030] Adding optional networkId parameter to .enable. function for the DApp connector specification. I disagree with the way the CIP is done. I don't think it's a good idea and Matthias agrees with me and there's been no response. So I feel like we're stuck on this waiting for a response. **Sebastian Guillemot** - Next is... Does anybody have any comments about CIP-30 before we move on? Because I think we're just blocked on a response for this one. ### PR234 [CIP-47? | Proposal for open Daedalus or desktop wallet via URL](https://github.com/cardano-foundation/CIPs/pull/234) **Sebastian Guillemot** - All right, hearing none, moving on. CIP-47? | Proposal for open Daedalus or desktop wallet via URL Triage is to basically add DApp connector to Daedalus by taking advantage of the URI scheme. To be honest, I'm not super convinced this even needs to be a CIP because the way they want to do it is very much Daedalus-specific and I'm not sure there's a way for them to not do Daedalus-specific, which is my main concern. The reason why is because for the web Cardano stuff, this works, they can use this, but Daedalus only supports a single network per installation Daedalus, and so they want to introduce a new web Cardano test net, and then they have multiple implementations of Daedalus. They want to have like a web Cardano flight for test modes. So this is kind of awkward because this won't really work with other wallets well, and it won't work with DApps well either. **Matthias Benkort** - It's kind of weird to have a Daedalus-specific CIP in a way. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - The point of having a CIP would be to, well, have cost compatibility or interop between wallets. So if it is something Daedalus-specific, then [crosstalk 00:01:56]. **Sebastian Guillemot** - What they can standardize is this extension to the web Cardano stuff. **Matthias Benkort** - Yeah. **Sebastian Guillemot** - And then as a side note, they can say, "Oh, and by the way, Daedalus has this Daedalus-specific stuff in case you care." The CIP as is feels like it doesn't add any functionality. It just specifies some Daedalus-specific considerations, which doesn't need to be done as a CIP. **Matthias Benkort** - Yeah. **Sebastian Guillemot** - So this is my main concern [crosstalk 00:02:26]. **Matthias Benkort** - I haven't been through comments, but maybe this is something you've already suggested, or we can make it clearer maybe to suggest as a top-level comments. That the idea in itself of extending the URI scheme to include other parts makes sense, and maybe that's something that could go as a CIP, explaining how to extend it and why would be the extension. But then that's... Well, documenting the Daedalus-specific extension is probably not the right place to do it here, unless this is done in the form of a sort of global registry that also can be used by other wallets for other stuff. But yeah, if it's Daedalus-specific, that doesn't make much sense. **Sebastian Guillemot** - Yeah. I've had some discussion with this and we're kind of at an impasse on this one. I'm not sure what they want do about it. I'll try and summarize my comments again and try and move on this. **Matthias Benkort** - Okay. We had this one on the agenda anyway, so we can maybe put it as triage for next time or simply comment on it and… **Sebastian Guillemot** - Anybody else here have comments on this? I'm not sure if anybody from the Daedalus team is here. **Matthias Benkort** - I think Daniel is here, who is the author of the CIP. I'm not sure if he's listening or hearing anything. **Sebastian Guillemot** - Yes. He is. He's here. **Matthias Benkort** - People had problems with sound. **Sebastian Guillemot** - How do you invite people up to speak? **Matthias Benkort** - We cannot. Only the host can. **Sebastian Guillemot** - Yeah, you're right. **M. Àngels Jover** - Do you want me to invite anyone to speak? **Matthias Benkort** - Maybe Daniel, yeah. Since he's here. **M. Àngels Jover** - Okay. **Matthias Benkort** - Thank you, Maria. If Daniel is up to it. **M. Àngels Jover** - I don't see any username with Daniel. Maybe it's under another nickname? **Matthias Benkort** - It's Daniel Main. He is in the chat. **M. Àngels Jover** - I don't see him live right now. **Matthias Benkort** - Oh, weird. Okay. So maybe he's not they're anymore and our chat is lagging behind. Yeah, I can see too. **M. Àngels Jover** - Wow. What's happening today? **Matthias Benkort** - Daniel, are you around? **Sebastian Guillemot** - So... **Matthias Benkort** - He shows in the guest list. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - I bet if he was there, he would've commented maybe on the chat already. **M. Àngels Jover** - I mean, he is in registered, but it's not live. Maybe I am the only one that can see the live. **Matthias Benkort** - Yeah. Yeah. We don't see that information. Indeed. **Sebastian Guillemot** - Ah, you're right. The chat does not show people who are actually here. It just shows people who have registered. **Matthias Benkort** - Yeah. **M. Àngels Jover** - That's the second tab. **Sebastian Guillemot** - I see. I see. **Matthias Benkort** - Okay. Well, then we'll just comment on the pull request itself. **M. Àngels Jover** - It's PR 234, this one? To put it [crosstalk 00:05:38]. **Sebastian Guillemot** - It's 034. **Matthias Benkort** - Oh yeah. Not even in [crosstalk 00:05:41]. **Sebastian Guillemot** - Oh. Yeah, no. Yes. **Matthias Benkort** - We first need to address the points that we just raised and then we can maybe reconsider it for CIP triage. **M. Àngels Jover** - Okay. **Matthias Benkort** - So I will just go on that. ### Triage #### PR217 [PR217- Collateral reward](https://github.com/cardano-foundation/CIPs/pull/217) #### PR104 [PR104 - CIP-1856 | Collateral Key derivation](https://github.com/cardano-foundation/CIPs/pull/104) **Matthias Benkort** - Okay. Maybe we can go through the PR 217 and PR 104. Sebastian? Just for triage to see what we can do with that. If you think they are still relevant or not. We had them in the pipeline for a while. **Sebastian Guillemot** - Yeah. Yeah. Both these can just be deprecated and closed. **Matthias Benkort** - Okay. Both of them? **Sebastian Guillemot** - Sorry. Collateral output is the one that stays and should be merged at some point, but reward and key can both be marked as deprecated, or rejected, whichever, and closed. **Matthias Benkort** - Okay. Then I will let you do that. Yeah, we'll go through the collateral output after that. ### Last Check #### PR200 [PR200 - Add support for Catalyst multi-delegation](https://github.com/cardano-foundation/CIPs/pull/200) **Matthias Benkort** - So the next one is CIP-36. The Catalyst multi-delegation support which we have been discussing for a bit. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - It needed an update, but Mark has been unwell for a few weeks. **Sebastian Guillemot** - Yeah. I think there's still some comments that need to be resolved. **Matthias Benkort** - Okay. **Sebastian Guillemot** - Yeah. From two weeks ago. These are mostly just to do with mostly documentation changes and wording. Not so much about functionality-wise. I did add a comment a few days ago, I guess a week ago, saying that the current delegation CIP only supports staking public keys, like vkeys and not script keys. So there's two kinds of scripts, right? Native scripts and Plutus scripts. So, trying to register Plutus scripts for voting on Catalyst may be kind of tricky, but I feel like native scripts should be doable. This would be nice because there's a few different projects that are using native scripts now for multisig and it means that for multisig, any amount of data you store in your multisig can build for Catalyst. Notably I was interested about this because for Milkomeda we have the Milkomeda DAO, which stores the funds for the Milkomeda DAO, and obviously the Milkomeda DAO wants to also vote on Catalyst so this specific proposal mix that any amounts that the DAO earns cannot be used for voting on Catalyst, which is kind of unfortunate. **Matthias Benkort** - Okay. I'm just reading through your comments also. Probably... Yeah. **Sebastian Guillemot** - I think extending this CIP to extend to not just public keys, not just vkeys, but also native scripts is probably not too hard, and the hard part [crosstalk 00:09:21]. **Matthias Benkort** - Shouldn't it be just a hash in the end? **Sebastian Guillemot** - Yeah. [crosstalk 00:09:26]. **Matthias Benkort** - You don't care much what's the pre images about so long as it's a valid credential. Maybe a Plutus script, native script or a vkey. **Sebastian Guillemot** - Yeah. So I think from the actual CDDL specification from the CIP perspective, this is not a hard change. Someone just needs to make it like some sort of or with a tag. The question is just whether or not they want to make that change now or later. I suggest we at least make it now so we have backwards compatibility, and then I'll see this is something for wallets to add support and something for the Catalyst team as well to add support when they scan the chain. **Matthias Benkort** - Yeah, that's the field number two in the CDDL, right? In the key registration record. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - Which currently is staking pub key. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - Which should really be... For Jörmungandr if I call correctly, Jörmungandr doesn't use hashes. Right? It uses plain keys. So there might be- **Sebastian Guillemot** - It shouldn't matter for Jörmungandr because this is not who you're delegating to. This is just who is delegating. So from Jörmungandr's perspective, it's still just voting keys. Do you see what I mean? **Matthias Benkort** - Yeah. But if we put hashes instead of keys, don't we have a [crosstalk 00:10:47] there with [crosstalk 00:10:48]? **Sebastian Guillemot** - These hashes are not the voting key. These hashes are just who's delegating. Remember with Catalyst, you delegate to a voting key, right? So I'm saying we should allow delegating from a native script to a voting key, but the voting key still stays the same. **Matthias Benkort** - Yeah. Okay. Okay. Yeah. The voting key on the Jörmungandr side stays. **Sebastian Guillemot** - Yeah. That's why I think the change is probably not too hard, but at the very least, if you don't have time just make a tag- **Matthias Benkort** - This is just to determine this snapshot, right? That snapshot that goes, and how many funds is allocated to every voting key at the beginning of the voting round. **Sebastian Guillemot** - Can we add Kevin to speak? **Matthias Benkort** - Yep. I think so. **M. Àngels Jover** - Sure. **Matthias Benkort** - Oh. I'm right back. Got a call. **M. Àngels Jover** - We can only have four people on screen, so we are three now plus the screen share. Maybe Sebastian you can not screen share so we can talk to Kevin and have it... Okay. **Kevin Hammond** - Hi. Hi, everyone. You hearing me? **M. Àngels Jover** - Yeah. Clear and loud. **Kevin Hammond** - Hi, good. Yeah. Sebastian, we've been looking at this. It's an interesting idea. We have two issues with it. One of them is to do with how it changes the voting. We need to think about that quite carefully, so we don't want to rush into this. The second is we would need to add logic into the tooling to essentially replicate the script actions. That would include replicating the context for the script. We don't have any capability to do that at the moment. We would also, if we included native scripts, need to think about how time locks will work. So we can't simply add multiscript, multisig scripts without also having a think about how the Allegra time locking will work. So, what I would propose to do here would be to set up CIP so that it is upwards-compatible to allow script hashes, but not to do it in the immediate future. **Sebastian Guillemot** - Yeah. I think if we just change the stake pub key to instead just be a structure with a tag that's like zero is pub key and that's it, and then later we can add one as native script and later two as Plutus script, something like that. **Kevin Hammond** - Exactly. So we make it a union type and it's only got one network element, which is [inaudible 00:14:02]. We're happy to do that. Then we can think properly about all these different types of scripts. As I was saying, I don't think it's ever going to be possible to use a Plutus script, or at least it would be quite hard because you would need to bring in all the script context and you would need to execute that from within the... They call it the snapshot tool. So I think you would need to be basically running a node within the snapshot tool to be able to set up the context and execute the Plutus script. That looks very difficult. It might also cause some issues over how the votes were actually set up. So from a semantic perspective, that's quite a, potentially a big change. **Matthias Benkort** - I'm not sure to get the point though, because here it's really about the staking, right? So- **Kevin Hammond** - It's to do with how we translate the stake into the voting rights at the snapshot times. **Matthias Benkort** - So all you need to do at the snapshot times is to make sure that some staking credentials is attributed to some stake, but that's already what the ledger does. Right? If you've already delegated your stake using a Plutus script, that means you have published this delegation certificate on chain. It has been checked by the ledger already and your stake is active under that credential. So just specifying the credentials at the moment of your voting arbitration doesn't really add any complexity. Right? **Kevin Hammond** - Okay. Let's think about that. What I'm proposing is we discuss it properly rather than- **Matthias Benkort** - Yeah. Okay. I'm fully on board with that. We can have as you said, a forward-compatible format. **Kevin Hammond** - Exactly. **Matthias Benkort** - And see what are the consequences. But I do think there is no really consequences, so we can bring the discussion to another time. Yeah. **Kevin Hammond** - Well, the consequence concerned about are, they're more to do with the semantics of who can vote, how you control the vote. So we want to think about that, Sebastian. **Sebastian Guillemot** - Okay. Well, let's change this to this union type with a tag, merge to the CIP, then we can open another CIP that adds the native script, and then we can discuss from there for another voting round. **Kevin Hammond** - We've got a technical problem in that we can't seem to do anything with this PR because Mark owns it, and also the history, of course as you said before, has got a bit confused. **Matthias Benkort** - I thought it would be able to do that, so maybe I can try. Yeah, you don't have the rights on the CIP repo, so maybe you cannot push on mark PR. **Kevin Hammond** - Yeah. I don't think so. I think... **Matthias Benkort** - I think I can. The two things we need to add here as the... The derivation path, right? That was discussed a while ago already for the voting key, and this [inaudible 00:17:24] forward-compatible, changing the CDDL. **Kevin Hammond** - Yeah. But if you could give us write access. So [crosstalk 00:17:30]- **Matthias Benkort** - No. **Sebastian Guillemot** - The other option is just to close this one. **Matthias Benkort** - Yeah. Again- **Sebastian Guillemot** - Go back to this one and just do whatever. Or close both of them and open a new PR is another option. **Matthias Benkort** - Yeah. With all the history. But, okay. I mean, those are the two changes we want to get in, right? That the duration path for the voting key and the change of the CDDL. With that, we're good for merging this proposal as draft. **Kevin Hammond** - Yeah. I think Jack, he wanted to tidy things up to make sure we properly responded to all of the comments as well. We'd like to do that. If we can close these down, take a... I guess it's probably a... Is it a forked PR and then progress that as the set, that would be great. **Matthias Benkort** - Yep. Okay. **Kevin Hammond** - Good. **Matthias Benkort** - Okay. We can do that and maybe do the validation offline and get it merged. I don't think we need to wait yet again for the next meeting for the review. Although the next meeting is only in a week, so we can also do a last check for the next meeting with all the changes in a new PR and the comments addressed. Does that work for everyone? **Kevin Hammond** - Yep. That should be good. **Matthias Benkort** - Okay. **Kevin Hammond** - Great. So we'll progress that. I'll progress that with you, Matthias. Is that right? **Matthias Benkort** - Yeah. Yeah. Let's take it offline. I think we've been discussing this one for a while. We're pretty aligned on the next steps so we don't necessarily need to discuss it online again. **Kevin Hammond** - Yeah. We're actually talking to various wallet implementers about supporting this at the moment. **Matthias Benkort** - Yeah. **Kevin Hammond** - This one is [inaudible 00:19:37]. **Matthias Benkort** - Okay. Taking a few notes and I will comment at the end of the call. **M. Àngels Jover** - So I understand that you are going to take the conversation offline and we are going to either merge it or change it in a new PR. Right? **Matthias Benkort** - Yeah. And probably merge the new PR also right away since it's already been discussed. **M. Àngels Jover** - Okay. So we can- **Matthias Benkort** - The new PR is just the technical issues because the author is not responding on this one, so. **M. Àngels Jover** - So we can take it off of the agenda. Right? next meeting? Perfect. **Matthias Benkort** - No. Or if we really have to we'll put it as last check for next week, but I don't think we'll have to. We can handle that offline. **M. Àngels Jover** - Okay. **Kevin Hammond** - Thanks, everyone. **M. Àngels Jover** - Thank you, Kevin. **Kevin Hammond** - So... **M. Àngels Jover** - Sorry. Sorry, Kevin. I just removed him while he was talking. **Matthias Benkort** - Kevin is gone. **M. Àngels Jover** - My apologies, Kevin. You were talking. **Sebastian Guillemot** - We have to move on to ... **Kevin Hammond** - I was going to say... **Sebastian Guillemot** - Oh, go for it. **Kevin Hammond** - I was going to say, Sebastian, we'll set up a call with you and others discuss this probably in about two months' time. **Matthias Benkort** - Yeah. You mean the extension with the multisig. **Kevin Hammond** - The extension with the multisig. **Matthias Benkort** - Okay. **Kevin Hammond** - Brilliant. Okay. I can drop now. **Matthias Benkort** - Bye. **M. Àngels Jover** - Thank you very much, Kevin. #### PR208 [PR208- [CIP-0030] Adding getCollateral function to the connector API](https://github.com/cardano-foundation/CIPs/pull/208) **Matthias Benkort** - So, [CIP-0030] Adding getCollateral function to the connector API We discussed this one last time already. All right. It makes sense. **Sebastian Guillemot** - Yeah. I think this implementation made sense to me. **Matthias Benkort** - It made sense also to have it as an extension of the CIP-30, this one. I think the only thing we were maybe discussing was whether or not we want to add it to the existing CIP-30, or to have that as another CIP which is extending the API. **Sebastian Guillemot** - I would just merge it I think to CIP-30. **Matthias Benkort** - Yeah. I mean, it's quite small enough, this one, and it's really core to the API itself. But then there is this question of versioning of this CIP connector. When do you suppose [crosstalk 00:22:29]? **Sebastian Guillemot** - Yeah, so the way we're handling versioning, at least the way I envision it is that in the CIP-30, we have two sets of functions. Experimental functions and non-experimental functions. Any new CIP should add stuff to the experimental section. And then whenever enough wallets implement, they would move from experimental to main and then bump their version number is the way I envisioned it. That way people can still make changes without bumping the version number and everything is in the experimental [inaudible 00:23:02] space. **Matthias Benkort** - Yeah, but the experimental was also a CIP [inaudible 00:23:06] discussion. Right? **Sebastian Guillemot** - Yeah, but I think that was merged already. **Matthias Benkort** - I don't see it on the CIP-30. Experimental... Or was it maybe merged. Yeah, it's in still open PR. That was the experimental API version. Okay. That's another thing. **Matthias Benkort** - I'm pretty sure we discussed that experimental approach a while back, but it's definitely not merged in the CIP. Oh yeah, it is, actually. Sorry. At the bottom. My bad. **Sebastian Guillemot** - Yeah, it was merged back in February. **Matthias Benkort** - Okay. **Sebastian Guillemot** - That's the way to manage the version number I think that makes the most sense. The get collateral one is the only one that's kind of awkward because we're changing an API that everybody already supports. We're just documenting it. **Matthias Benkort** - Okay. **Sebastian Guillemot** - That was especially a case of an awkward thing where we already [crosstalk 00:24:27] one, so there's no point going from the experimental first. **Matthias Benkort** - Yeah. Then the awkward thing is how and when you decide to move from experimental to non-experimental. It's once multiple wallets implement it, but it's a bit vague, right? How many wallets and... **Sebastian Guillemot** - Yeah. Probably what we need to do is make this more formal, add it, change the CIP-30 that adds to the governance of CIP-30 that says governance of the CIP is that it should only be merged if X wallets, blah, blah, blah. Include the functionality, something like that. **Matthias Benkort** - Yeah. Maybe having explicit versioning in the CIP. I mean, for every single function that there is, like this one should be supported if you are in version 1.0. If you are in version 1.1, you should also support that function and that function. And then from that, it's very clear. You can ask the wallet version and depending on the version number, you know exactly which version they support, which API they have available. **Sebastian Guillemot** - Yeah. **Matthias Benkort** - Or an alternative, and that's why I was maybe advocating having another CIP for that, would be instead of a version number, you get the list of CIPs that your connector supports. Would be CIP-30, CIP I don't know, 46, for instance. And 46 is the one that introduces the get collateral API. So you know from that list exactly which feature are supported. That allows also wallet implementers to implement features that are important to them. Not necessarily in sequential order, but just say, "We support this set of features. You have the list here," but maybe we don't support this one that was introduced in between these two other features because we don't care about it. And we don't make it mandatory to implement every API as you upgrade versions of your wallets. See what I mean? **Sebastian Guillemot** - Yeah. That's definitely another approach. We could even do both at the same time because I don't think they conflict each other either. **Matthias Benkort** - Okay. I don't want to be too much on that one for this particular one so I think this one is fine to merge as is, but maybe I will actually make a proposal for handling new versions of our additions to CIP-30 in the form of- **Sebastian Guillemot** - Yeah. We definitely need some PR that just adds some governance to this document. So I bring those [crosstalk 00:27:08]. Yeah. **Matthias Benkort** - Yeah. Governance and structure. A bit more on how to update, because as a wallet implementer, this sounds not like fun right now to maintain all the different versions of the CIP-30. **Sebastian Guillemot** - Okay. Yeah. It's kind of tough. We'll have issues with people not wanting to support the message signing, but message signing was not a separate CIP. It was introduced in the original CIP, blah, blah, blah. Somebody will need to sit down and figure that out at some point. **Matthias Benkort** - Right now it's still draft so what I would suggest would be to say, move this one to actually active. Merge that pull request, making the API collateral something part of the core CIP-30. Move it as active and sort of settle in stone a bit the primary API, and then define updates through another CIP and define how we would implement updates and extensions on the CIP-30 in the future, because there will also be extension. But at least settle that first part in stone now that it's become pretty stable or discussed for quite a while, and it's implemented now by most wallet provider anyway. So we have also the proof of activity, in that sense. Do you agree? **Sebastian Guillemot** - Yeah. Makes sense to me. **Matthias Benkort** - Thank you. I will discuss that with Robert as well. **Sebastian Guillemot** - In the meantime, I've approved this PR. **Matthias Benkort** - Yeah. Just, approving comment. Let's move this one. **Matthias Benkort** - Okay. **M. Àngels Jover** - There's still one missing approval. Matthias, are you going to approve it later? **Matthias Benkort** - No, I just did. I was just commenting at the same time, so it took a bit of time and we can go for it. #### PR215 [PR215 - CIP-35: Plutus Core Evolution](https://github.com/cardano-foundation/CIPs/pull/215) **M. Àngels Jover** - Shall we move to the next item? PR 215, Plutus core evolution. **Matthias Benkort** - Yeah. **Sebastian Guillemot** - I just noticed we have two tentative CIP-35s. This conflicts with the Daedalus one. **Matthias Benkort** - Yeah, I will tweak the numbers. I think we've made it clear last time, and on the read me also. Well, people are not supposed to be allocating numbers themselves. They might try, but we'll just modify it at the same time. **Matthias Benkort** - Michael is saying it's confusing. Yes, but it's been clarified last time now, so we have tentative numbers on the front page. Yeah, I told you pick a number and that was fine. We keep track of the numbers on the front page. As you can see, the tentative number for the Plutus core evolution is 35. So, you are not the one conflicting here and it's fine. But mind you, we have all the rights to modify the PR if we need to adjust the numbers. We will do so upon merging if needed. But that's not the case for Plutus evolution, which is already the candidate for number 35. So that's fine. **Matthias Benkort** - Okay. The Plutus core evolution, that was also reviewed last time, and we are mainly in last check, right? If there was any last comments on this one, but I think there was none. **M. Àngels Jover** - No. Last comments are from February 14. **Matthias Benkort** - Yeah. So we're good with that. There has been already two, at least. Even three now I think. Proposals already following this process, people seem to be happy with it. Yeah. You never know if people are really happy though. **M. Àngels Jover** - Weeks ago, there was commented that maybe it would be good to add an extra status call at adopted between proposed and active, but we haven't. **Matthias Benkort** - That's also Michael's question in the chat and that was what I was suggesting last week. Since this one is a process, it should be I think merged as active. Mainly because, well, there has been already three CIPs following this process which shows already activity, and it's not like we're wait for an implementation or some actual code or platforms to adopt it. It's really more of a process and we deem it now ready, active. It's supported by the core team, the core Plutus team, which mean that we don't even need to check with them if it's okay because the process actually comes from them. So, yeah. I've just approved. Maybe just before merging, we will change the status to active, if that's fine for everyone. **M. Àngels Jover** - Looks it is. Shall we move to the next item? **Matthias Benkort** - Okay. Michael, if you want to push the change to move it to active, feel free. Otherwise I will just do it at the end of the call. Well, just this one approval though, I think, because I was the only one that approved. So Seba, unless you disagree, voice yourself, but otherwise... **M. Àngels Jover** - Now we have both approvals. **Matthias Benkort** - Okay, good. So yeah, just the active status and we can merge. ### Review #### PR209 [PR209 - [CIP-0030] Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) **Matthias Benkort** - Now, more to the review, which was the next item was the... Yeah. Optional network ID parameters. Yeah. What Sebastian was discussing at the beginning. We're saying yeah, this one we disagree and the author has been quite inactive since then so we can simply park it on the site and wait for updates from the author. **Matthias Benkort** - Can we talk about the other builds in CIP? Yeah. We're just coming to it. So, CIP-32 and CIP-32. Those one have the same numbers precisely because they are conflicting, also in the sense. So I don't think it makes sense to merge both of them because they are attacking the same problem and if one of them is actually adopted, the other one should be deprecated or rendered obsolete. I think it's the one we wrote with Sebastian on the CRS built-in data that has been adopted in the Plutus code base. Maybe you can invite Michael on chat before he leaves. **M. Àngels Jover** - Sure. **Matthias Benkort** - Yeah. It's the one we are implementing these days. That means we can probably deprecate the second one, unless it makes sense to also have the second one. I don't know. And have the two ways. This one's redundant to me to have both ways, but I don't know. Michael? **Matthias Benkort** - I don't think so. Yes, it's- **M. Àngels Jover** - I need to remove my screen sharing before invite him. Ah, no. **M. Àngels Jover** - Now you have Michael on the screen. **Michael** - Can you hear me? **Matthias Benkort** - Yeah. We can hear you. **Michael** - Okay, good. Yeah. So, it's redundant I think. #### PR218 [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218) #### PR222 [PR222 - CIP-42? | New Plutus Core built-in dataHash](https://github.com/cardano-foundation/CIPs/pull/222) **Matthias Benkort** - Okay. Talking about PR number 218. One thing we would have to add before merging it as proposed or active will be the cost model I believe, that was left out initially. **Michael** - Yeah. I think the Plutus... Wait. Can you hear me? **Matthias Benkort** - Yeah. **Michael** - Okay, good. I think that Kenneth has been working on that so I think we could probably put something up there with the Plutus team. I think this is maybe something that I should clarify in the evolution one maybe as a follow up, but I think it would be fine to merge it as draft with a high-level description of what the serialization function is. So, say something like based on the work in this pull request, we believe that it is basically linear in the size of the thing. Exact parameters will be determined empirically or something. That I think is sufficient. **Matthias Benkort** - Okay. **Michael** - Yeah. I think that's fine. It doesn't have to be 100% precise, I think. **Matthias Benkort** - Okay. Okay. So we can add that and then move the CIP as proposed since there is a clear path to active now, and move it to active as soon as this becomes available in the Plutus built in, which should be part of the Babbage hard fork as far as I understood. Or Vasil hard fork? I don't remember what's the name anymore. **Michael** - Yeah. That sounds right. **Matthias Benkort** - Okay. About the second one, the PR 222, you were saying this won't be implemented because it's redundant. **Michael** - Yes. **Matthias Benkort** - Do we have the last here? It was in the chat, but I'm not sure if it is active or not. It is Vasil, thanks. So, because Las is the author of the second one, which was basically trying to solve the same problem, but in a more straight way, I would say. In a more direct way. So not having this extra serialization step, but just going for the hash straight away. So there was a bunch of discussions on it, but it's been pretty evolved since then. **Matthias Benkort** - Okay. He doesn't seem to be here. Maria, do you see him as live or? Las Safin. **M. Àngels Jover** - No. **Matthias Benkort** - Okay. He just registered, but probably didn't join either, so okay. We'll comment then on PR number 222 and move that CIP. Probably merge it as deprecated or obsolete. **M. Àngels Jover** - Yeah. You mentioned, Matthias, Mlabs? Who do you mention that you want to ? **Matthias Benkort** - Las. Las Safin. He's from MLabs. **M. Àngels Jover** - Ah, Las. No, he's not. He is registered but not live. **Matthias Benkort** - Okay. Okay. So there is still room for CIPs that are rejected, and I think it makes sense to still record it as a rejected CIP, this one, to show that there has been discussions between two alternatives and we went for a first one that is a bit more composable, in my opinion. Okay. We'll comment on that one. **Matthias Benkort** - Maybe Michael also, if you have a rationale for why you went for PR 218 instead of 222, that would be also helpful maybe as a closing comment. I am a bit biased in the story since I'm the co-author of one of them, so obviously I think mine is better, but that's biased. **Matthias Benkort** - I'm not sure. Okay. Sure. Okay. So yeah, feel free to comment on the pull request then. I will also add some top after the meeting. **M. Àngels Jover** - Just a quick question. PR 218, are you going to merge it? **Matthias Benkort** - Yeah. Once we've done these little additions I was mentioning about the choice of cost model, as Michael was explaining. **M. Àngels Jover** - Okay. **Matthias Benkort** - The cost model is still to be determined empirically, but it should be somewhat linear in the size of the built-in data based on what we've been observing so far. That's good enough for now to have it as proposed CIP and once the implementation is finalized and available, we will update it as active. **M. Àngels Jover** - What do you want me to do with this? To put it on hold and discuss it in a few meetings or? In the agenda, I mean. **Matthias Benkort** - Hmm? Sorry. **M. Àngels Jover** - What do you want me to do? To put it on hold until the change is made and we can then discuss it later or? **Matthias Benkort** - Yeah, I think we can put it as last check for next week. **M. Àngels Jover** - Okay. **Matthias Benkort** - I will do the change somewhere between now and next week and we'll be able to do our last review and see if it's okay. **M. Àngels Jover** - Perfect. **Matthias Benkort** - So we had the last one, I think, on the list. #### PR220 [PR220 - CIP-43? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220) **M. Àngels Jover** - Yeah. PR 220. **Matthias Benkort** - Yeah. Plutus support for pairings over curve BLS12-381, which was the one for which we wanted to have some help of cryptographers, which I haven't been able to get so far. So, we'll keep looking, actually. But yeah, this one is hard to progress for us as Editors because we are missing the expertise here that is necessary to judge. Yeah. That's the idea. I mean, I trust in Iñigo, the current author, what he's writing and specifying, but it's good to have conversation with people that can actually contribute to the conversation. So yeah, I will just keep that on my list to try to find someone. **M. Àngels Jover** - I will ask you in a couple of weeks if you find someone. Okay? **Matthias Benkort** - Yeah. We can park it for now and see if there is anyone either in IOG or within the research cycle. Someone that can share some time on that. #### PR216 [PR216 - CIP-40? | Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) **M. Àngels Jover** - Good. The last item that we have was PR 216, the collateral output. I know that you had a discussion at the beginning of the meeting, but I don't know if we just left that for now to discuss in the... **Matthias Benkort** - I don't know. Sebastian, what do you think? **Sebastian Guillemot** - One more time? Sorry. **Matthias Benkort** - The collateral output. Do you want to discuss it now or keep it for later? **Sebastian Guillemot** - No. You can discuss if you want, but this has already been decided. This is already part of the CDDL, already implemented in the ledger spec **Matthias Benkort** - Okay. So it's in a good way to actually becoming active. **Sebastian Guillemot** - We can have a discussion about if you want, but I don't think any discussion we'll have would actually be reflected into the protocol. **M. Àngels Jover** - So this is going to be merged? **Sebastian Guillemot** - Yeah, I would merge it unless somebody has any objection. **Matthias Benkort** - Yeah. It's been around for a while already. You've been discussing it with Jared and Andre, I imagine. **Sebastian Guillemot** - Yep. **Matthias Benkort** - Okay. So we can have it as proposed, also following the same paths, and moving to active as soon as it's becoming really available in the ledger. So, moving it to last check for next week. Or we'll change the status, assign the right CIP number and move forward with that. **Sebastian Guillemot** - Yeah. Sounds good to me. **M. Àngels Jover** - Okay. ### Close **M. Àngels Jover** - We have five minutes left. Do you want to do a recap, Matthias? **Matthias Benkort** - Yeah. I think people appreciated that last time. Just Kevin has a question on the chats. I'm not sure if still have the context. Are you talking about the search for a cryptographer, Kevin? **Matthias Benkort** - Maybe Kevin is gone, so okay. We'll take it off band. That's fine. Okay. Let's recap. **Matthias Benkort** - We went through the collateral reward collateral key derivation CIPs, which are going to be marked as deprecated and likely closed. We could also merge them as rejected CIPs just for the record and keeping the history. **Matthias Benkort** - Oh, wait a minute. **M. Àngels Jover** - I took some notes so I can do the recap on behalf of Matthias. We are going to have a PR 200 for last check in the next meeting. PR 208, adding collateral function to the connector API has been merged. Also PR 215, Plutus score evolution has been merged. PR 222 is going to be rejected. This one is the PR that was competing with PR 218 that finally is going to be implemented. Here it would be good to have a rationale why PR 218 has been chosen over to PR 222. And we have PR 218 for last check in our next meeting. **M. Àngels Jover** - Also, PR 216, collateral output. This is going to be merged. Right, Sebastian? I am not 100% sure of this last one. **Sebastian Guillemot** - Yeah. **M. Àngels Jover** - Okay. So that's it for today. Just remember you all that next meeting is going to be next Tuesday. It will be in the United States time zone. This means that it's going to be held at seven UTC. Well, with you all there and the ones you cannot make it, as always we are going to record the session. Thank you very much and have a lovely day and week. Bye-bye! --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-04-12.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [April 12 2022 Transcript](#april-12-2022-transcript) * [Triage](#triage) + [PR216 - CIP-40? | Collateral output](#pr216) + [PR163 - CIP-37? | Dynamic Saturation based on Pledge](#pr163) + [PR137 - CIP-0038? | On-Chain Token Metadata Standard](#pr137) + [PR151 - CIP30: Events API](#pr151) * [Last Check](#last-check) + [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](#pr218) * [Review](#review) * [Discussions](#discussions) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) + [PR224 - Add Proof of Existence record label to registry.json](#pr224) + [PR241 - CIP-0989? | ISPO KYC_CDD](#pr241) + [PR188 - CIP-36? | Update CIP-15 to support multi-delegation](#pr188) * [Close](#close) ## Summary Rough transcript of 12/04/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-43) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. Distribution of the minutes via mailing list. ## April 12 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, Frederic Johnson, Robert Phair. **Guests**: Michael, Giacomo **M. Àngels Jover**-: Hello, everyone. Welcome to the CIP editors meeting number 43. My name is Maria Angels Jover, and I work as a project manager at the Cardano Foundation. And I am here to facilitate this meeting for you. At the top left, here you see... I am not sharing my screen. Sorry. Right now, you should be able to see my screen. At the top here, on this I letter, you can click and you can check the agenda. Then you have the chat box where you can leave any questions that you have. Also at the bottom, you have this bottom Ask a Question, you can use this because it's easier for us to answer from here and not from the chat. And well, it's my pleasure today to introduce you to all our editors today, which are Matthias Benkort, Frederick Johnson, and Robert Phair. First of all, I would like to check with you editors, is there anything that you want to review that is not in the agenda? Hey, Sebastian is here. Hi, Sebastian. I'm sorry, I didn't see you. And you have Sebastian Guillemot as an editor too. **Matthias Benkort**-: Well, there has been a recent pull request on CIP, but I sure CIP 50, that will be maybe nice to get a nice one, especially because it's similar to a previous CIP we've had, and maybe also overlapping with CIP number 37. I haven't looked in details into it because it's quite wide CIP, and we won't do the review today likely, but at least get a first acknowledgement, first dive into it, and see what would be needed then, maybe, to move it forward. I've already forwarded that CIP, by the way, to the core team internally for people to have a look. Yeah, we can expect some activity and comments in the upcoming future. And maybe I'll have [crosstalk]. **M. Àngels Jover**-: What PR is it Matthias? **Matthias Benkort**-: Sorry. It's PR 242. **M. Àngels Jover**-: Okay. I'm just going to share it with you. **Robert Phair**-: : Okay. And there was also one issue that I think should be discussed, some of the CIP PRs are being discussed. Said it's about one of the first CIPs that came along as an issue 232. That is right now being hashed out, the discussion is being hashed out in that issue, but it might be good to track that the same way we're tracking some of the PRs, because there's been a lot of discussion about whether one of the original CIPs should be modified or a new CIP should be created. It would be good to observe that for a little bit. **Matthias Benkort**-: Yeah, yeah. Good point. Issue number 242, right, on CIP number two, the coin selection. **Robert Phair**-: : Yeah. **Matthias Benkort**-: This one, yeah. This one has got a bit of a [inaudible]. **Matthias Benkort**-: (Silence). ### Triage #### PR216 [PR216 - Collateral output](https://github.com/cardano-foundation/CIPs/pull/216) **Matthias Benkort**-: Okay. Shall we start with the collateral outputs? **M. Àngels Jover**-: Yes. This one was agreed last week to merge it, but I have added it to triage as I haven't seen it merged yet. **Matthias Benkort**-: Yeah. Right, right, right. I wanted to go through it, which I actually did yesterday. Yeah, you just need a number. That's why we haven't still merged it. But it's tentatively CIP 40, so it's just a matter now of moving the file to the right folder, putting CIP 40 as a number, and getting it merged, indeed. That we discussed, but we also haven't proved it explicitly. Yeah, I will approve and reduce conditions of those terms. I'm not sure, Robert, if you had time to go or to look at this one, but the status quo of what we discussed last week was that this has been made and written in combination with the ledger team, and it's actually already being adopted in the ledger as an implementation and should be part of the Vasil Hard Fork coming in June, so it's a bit fast tracked in that sense. **Robert Phair**-: : Yeah. That's all I got from it is that it seems to be in progress anyway, and I certainly don't have any disagreement with it, the way it's being treated. **Matthias Benkort**-: Yeah, it was more like an ad-hoc conversation that got documented as a CIP, but by the time the CIP arrived, the decision had already been made with the ledger team about the direction to take. It's more an informational CIP in that sense. **Robert Phair**-: : It's fait accompli, yeah. **Matthias Benkort**-: And therefore, we could also maybe address the status already, because at least as proposed. Yeah, can you confirm we expect this to be included in the Vasil Hard Fork? I would say we could merge it as proposed and move it to active as soon as it's observable after the Hard Fork. Let's document that under pull request review change status to propose. **Matthias Benkort**-: Okay, sorry. That's commented directly on the ticket. **M. Àngels Jover**-: Here, we have the update. Perfect. We are missing one approval right here, right now, to merge it. **Matthias Benkort**-: Yeah, but we don't want to merge it also right away, as I said. We still need a few bullet points to be tackled, so either Sebastian can do it or any of the editor can tackle that later on. We should be able to push on the branch, at least. #### PR163 [PR163 - CIP-37? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163) **M. Àngels Jover**-: Okay. I just added a few things to the agenda that were... This one, for example, 163 was on hold, and you comment that Matthias said was sitting with the engineering team. I was wondering if you had any update on this. **Matthias Benkort**-: Yeah. Unfortunately, no. This one is a bit the same as the curve pledge benefits CIP seven, or another CIP, which I don't remember the... Yeah, 24th non-centralized ranking which are affecting the protocol and the rewards mechanism of the protocol or the way pools get rewards and get organized. And therefore, this is affecting the game theory behind the scene, and that's CIPs for which we wanted to have inputs from the researchers. From what I got so far is that the research team has no bandwidth to provide an actual detailed answer, but that they are not quite in favor of these new CIPs because they put some... Well, they reduced the Nakamoto coefficient or they put some security issues, but they have been quite vague so far on the reasons and the rationales behind, so I'm really trying to get a formal answer or some more detailed answer on those matters. But yeah, so no substantial updates from my side, unfortunately. **M. Àngels Jover**-: Perfect. What I will do is to leave it on hold and maybe we can just talk in a month or a month and a half. Maybe I can ask you offline if you have any update. **Matthias Benkort**-: Well, if I have any anyway, I will put them on the PR and comments on the respective CIPs. I'm really checking every week on those ones, mainly because if they are unsuitable because of some reasons, I would just like to put those CIPs and mark them as obsolete or rejected and be able to move on with that. **M. Àngels Jover**-: Okay, okay. **Matthias Benkort**-: Okay, so Kevin is saying the research team has a blog in progress about pledge, so that might be resolved soon. And that's also why I wanted to look at the the potential CIP 50 that has been published recently because it comes along with, actually, a lot of data, graphs, and argumentation in favor of the CIP, which then makes it for a good style of discussion, or actually, that definitely shows that there has been research done also on that particular topic, and maybe makes it easier for the research team to assess whether or not the work is legit, or what I mean is it doesn't put security issues within the whole project. **Matthias Benkort**-: Yeah, Michael is here, I see. Yeah, well, near the end lately, after we've done the current agenda, we'll touch a bit about CIP 50, so that's good. Thank you, Michael, for joining. Yeah, beside that, I think we reviewed the CIP 37 already in the past. It looks sensible from a technical perspective as it is. The question is, does it play actually well with the game theory or not, and will it have the outcome that is explaining in the motivation. That's more a question for the game theories behind, so it's a bit hard to tell. Maybe there will be also something to do with testnets on those two slants. Many of those changes rely on the game theory, and the game theory is theory also, a lot. It doesn't necessarily play like that on the whole scenario, so I'm wondering maybe if we could also just pin up testnets to try out those features sometimes and see how it goes, how people organize, even though testnet is also not mainnet. You've got free money, so you don't behave the same way you would behave on the actual minutes. I don't know, sorry. Just a parentheses. **M. Àngels Jover**-: Okay. Do you want to move forward to the next one? **Matthias Benkort**-: Yes, unless someone has something to discuss on that one. #### PR137 [PR137 - CIP-0038? | On-Chain Token Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/137) **M. Àngels Jover**-: Okay. I brought to the agenda also PR 137 because we were waiting for the author, and this was one that I have on hold too, but I see that has been commented seven hours ago, so that's good. **Matthias Benkort**-: Yeah, there has been some activities, but not from the author, unfortunately. Maybe we can ping, actually, Matt, the author, directly to see. People are arguing on the formats, and mainly, so they want to have something more compatible with the NFT standard that exists, but as we've outlined already in the past, the current NFT standard has several flaws that we want to fix. If going for new standards, we shouldn't repeat the same mistakes as before, which is exactly what the last comment answers or explains. As for this proposal itself, it still has the issues we've exposed a while ago, which is that you cannot really use the minting transaction of tokens to attach metadata to them, and therefore... Well, that's still an unsolved problem, and that's why we were waiting for the author to react on that. Maybe they have been discontinuing the whole proposal, so it would be good to clarify that with them. **M. Àngels Jover**-: I can ping again, request him to comment on February 28th, maybe. Well, I will just do it again and ping him again. **Matthias Benkort**-: We're already pinging, or- **M. Àngels Jover**-: Yeah, yeah, yeah. I will do so. **Matthias Benkort**-: Okay. I will just reach out to him on Discord maybe, that would be more efficient. Oh, not sure if he's monitoring the report or not. **M. Àngels Jover**-: It's Savasky, right? **Matthias Benkort**-: Yeah, who is actually Matt, the CTO of SundaySwap **M. Àngels Jover**-: I'll do it later. #### PR151 [PR151 - CIP30: Events API](https://github.com/cardano-foundation/CIPs/pull/151) **M. Àngels Jover**-: We have 151 events API. I brought this to the agenda because it was an old one. **Matthias Benkort**-: The Event API. Didn't we merge that one already, or was it still in flux? **Matthias Benkort**-: (Silence). **M. Àngels Jover**-: Matthias? I don't know if you are talking. Oh, he disconnected. Hi, Matthias. **Matthias Benkort**-: Hey, sorry. **M. Àngels Jover**-: You disconnected, right? **Matthias Benkort**-: Yeah. I clicked the link. **Robert Phair**-: : Thank God. I saw the drop there too, yeah. **Matthias Benkort**-: Took me out. Am I back? **M. Àngels Jover**-: Yes, you are. **Matthias Benkort**-: Okay. Yeah, so this one has got no activity since February 4th, so we're basically waiting on the author on that. This was part of the original CIP 30, and it was moved out of the CIP when we merged the CIP 30 as a draft, because it was quite a side concern, and we thought it would be better to bring it as an update or an external CIP completely. It was more like a grooming around what could an event API look like for the CIP 30. I'm not sure if the effort is being discontinued or not, but yeah, I guess this one still needs more discussions from within the community before we actually can do anything as editors. **M. Àngels Jover**-: We just leave it on hold, right? **Matthias Benkort**-: Yeah. It's still a draft, and it's very under discussion, so I think you just open a PR to have the discussion live, happening on GitHub, but there is no particular need or urgency to get anything done at the moment with that CIP. **M. Àngels Jover**-: Okay. I'll take notes. **M. Àngels Jover**-: (Silence). ### Last Check #### PR218 [PR218 - CIP-42? | New plutus builtin: serialiseBuiltinData](https://github.com/cardano-foundation/CIPs/pull/218) **M. Àngels Jover**-: Next step I added to, this is the same one, here at 163. We can go directly to last check with the 218, new CIP-42? New plutus builtin: serialiseBuiltinData within this one. I think it was supposed to be merged. **Matthias Benkort**-: Yeah, provided that we did the necessary updates on this one, and I'm guilty as one of the co-authors. I was just busy with other stuff and didn't do the time to do anything with that one. But yeah, so it's another implementation on the Plutus site, or actually it's even been implemented already, but only available on the latest master branch, so not yet in the nodes. But yeah, we wanted to clarify the cost model and what the cost model looked like with this proposal, that was one of the open points we left when we made the proposal, and it's been clarified since then. Before merging, we should just report in the proposal what it is. Just waiting for the author on that one. **M. Àngels Jover**-: Okay. I'm going to label it. **Matthias Benkort**-: Maybe I will just comment on it so that it's also clear. **M. Àngels Jover**-: Okay. That was what I added to the agenda because we were moving forward little from our last meeting. Do you want to do a review on other PRs, because maybe you know better what it's worth? ### Review ### Discussions #### PR242 [PR242 - CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias Benkort**-: Well, since we have Michael here, we can definitely look at potential CIP 50, at least to get a round of introduction and a high level overview of it before we actually dive into redoing it in the next sessions, or more in between sessions. **M. Àngels Jover**-: We are in 242? **Matthias Benkort**-: That was 242, right? **M. Àngels Jover**-: Okay, so I will bring Michael on stage. And Robert, I am going to need to change you for Michael. **Matthias Benkort**-: Yeah, or I can drop as well. Oh, okay. That already dropped. **M. Àngels Jover**-: Michael Liesenfelt, right? **Matthias Benkort**-: Yeah. **M. Àngels Jover**-: Connecting. Hello, Michael. **Michael**-: [crosstalk] your audio? **Matthias Benkort**-: We hear you. A bit low, but we hear you. **Michael**-: Excellent. **Matthias Benkort**-: Okay. **Michael**-: Right, should I launch into a brief introduction? **Matthias Benkort**-: Yeah, more like describing what's the intent behind, and maybe if hardly also aware of the other CIP that exists, and let's also try to address similar issues, so maybe the key inferences with that. **Michael**-: Sure. There are many prior CIPs, I've referenced them much later in the document, but this grew from looking at the Cardano Network as a whole and realizing that there was a disconnect between the game theory and the game reality. And then upon a paper review, I realized that the RSS paper considered multi-pooling as a Sybil behavior, and we just won't simulate our players in the models with the capability of spooling up more than one pool per player, which, if I was the reviewer of the paper at the time, I would've kicked it back and said, "Each player can delegate to somebody else, make one pool, or make more than one pools." That oversight in the game theory has led to the proliferation of multi-pools in defiance of any hope of changing the K parameter. **Michael**-: Instead of complaining about it, I decided to start investigating and looking at the historical background of who's had thoughts on this issue, what could be a potential solution forward, and there were plenty of forum posts, other CIPs, that have each taken a little bit different edge. I'm not the first to mention pledge leverage. There are concepts of crafting a leverage parameter. Many of the prior equations included higher order relationships, included higher order curves, included due factors, included greater complexity. And I decided I was going to be a little crazy and instead, simplify it so there was nothing to hide anywhere in the equation, anywhere in the field of outcomes. The relevant document's probably the readme.md, and that contains the long narrative. **Matthias Benkort**-: Okay. Thank you. **Michael**-: And it may be good to view it. Yeah, there we go. From a prior CIP editors meeting here, I learned that with certain technically deep topics, we'll need to come up with and propose external reviewers. That's probably one of the first steps is find out a great list of peer reviewers that are relevant and engaged and have done prior work that could add value to a review. I've started that list. I would definitely love any additional names to go on that list. That's probably one of the first starting points. **Matthias Benkort**-: Yeah, indeed. I've already forwarded your documents, by the way, to all the engineering crew at IOG, I at least the ledger one, or exactly, people work on the ledger and [inaudible] words. Also brought that to the attention of the research team. We are expecting some feedback on that and the discussion to start. I think we can remove Tim from the list, too, although he would love that. I'm not sure Tim would be the best person to review any of the technical stuff we have. **Michael**-: All right. I purposely didn't put you on the list either because I considered you as an editor and maybe not as a reviewer. **Matthias Benkort**-: Yeah. We're going to review from a editor perspective, the whole proposal. It makes sense whether it respects or not the holes and whatnot. And I can definitely review it with my engineer hat, but I'm definitely not the best person to review that. Kevin say, "Yeah, the ledger team is interested in this indeed." We've got pretty good feedback so far, so I will chase a bit people to see if we can get at least one person to get the conversation started from the IOG engineering, maybe also one person from the research side. I think we have Sean here as well, who maybe has also an interest in participating in a conversation. Tobias also, I recall he made an extended post on the Cardano forum on this topic. I think he even made a CIP or not yet submitted, but he had the plan to, at least. Yeah, definitely also good. I'm not sure if Colin has seen the proposal, but we can also ping him. **Michael**-: His initial Cardano forum thread is what spurred me to decide to write the CIP, especially when he said, "We at IOG here, we could be more aggressive with how we game rewards and financing from our current stake." And I'm like, it's exactly what we need to prevent one actor deciding that they need to be able to take a more aggressive stance against the rest of the community. **Matthias Benkort**-: Yeah, yeah. That's one, it's definitely something we want to discuss, but I'm not sure we will just discuss it on the next weekly meeting just because the discussion on this one will take likely a bit of time. This is one of the CIPs that might stay open for a bit. It would be good maybe to really see if we can have a more structured way of reviewing this one, because it's quite deep in the game theory. And in the protocol changes, we might want to have review sessions with a bunch of people that are listed in that CIP. **Michael**-: At a high level, I've crafted the name specifically, I started out realizing that decentralization is a Shelly-era concept, but I am not expecting this to be done immediately or soon or fast. And that's why Voltaire is in the name because this may actually take more community review and community governance, and might get implemented next era rather than now. That's why it's actually named the way it is. **Matthias Benkort**-: Yeah, definitely. And right now, I'm just thinking about first having good conversation on whether or not it makes sense and whether or not it is sound. And then there will be a second round of discussion on when does this get implemented and how, or by whom. Here's that thread on... Yeah, maybe we can put those threads on the CIP itself, comment it on the pull request to keep track record of those other discussions. **Michael**-: There's a conversation already starting that is getting robust. **Matthias Benkort**-: Good, good. Yeah, the one on the- **Michael**-: Also, question, as we move to Voltaire and pull in more community support and more community input, where should the official place for community support and non-technical support or oppose come in? I started collecting them on the Wiki page of my submission, but is that the right place? Is that the best place? Obviously, the Wiki is disabled for the main repository. Or a better place. **Matthias Benkort**-: Yeah. That's a good question, and unfortunately, not something I can answer. That's something we keep on repeating on the CIP meetings, but the CIPs are often interpreted as a governance mechanism, but the CIP have no governance absolutely on the protocol. They are about collecting solutions to problems and agreeing on the technical soundness on solutions. The thing is, they are not authoritative of anything. They won't tell you that these things will happen or that this is the roadmap or anything. It's more like the collections of possible solutions. And if we even need to solve a particular problem, we can pick among that collection. And it's also a good way to collaborate on standards across different platforms and wallets. But then, gathering the community sentiment, more like the community votes on a particular decisions, that's something more for catalysts, really, and you could very much see that both works together. **Matthias Benkort**-: How have a first CIP that is technically reviewed, it's been peer reviewed, approved, and then move to the catalyst land, say, "Well, that proposal is about implementing CIP XXX," and there is where you can actually get community voting and chipping in on, yes or no, I want this, I think this is a good thing. And the nice way of going that way is that, from the community perspective and the non-technical people, they can trust in the CIP process to have done already the technical review and the technical soundness of something. If it's been approved, it's been reviewed by both editors and the community and experts, then you can say, "Okay, it's already a pretty strong catalyst proposal itself, and now it's about implementing it." Only thing we need to look at is whether or not the budget maybe makes sense and if the team that is proposing to implement it also sounds capable of doing it, basically. Yeah, I hope this is a good answer for you. **Matthias Benkort**-: Okay, for this particular one, we'll just keep it in the loop for now. I really think it's one of those CIPs that should deserve proper review meetings with a bunch of parties. I will see if I can make that happen, or if not, I will try to find someone that can make that happen. I see the conversation anyways already going on the community forum. Now, it's more a matter of digesting also the conversations and bringing those updates to the CIPs. I'm not sure how available also you are to make those updates and work on it, but I guess that's something we can figure out along the way. **Michael**-: I have been making additions and revisions and changes, and will continue to do so. Maybe not every day, but maybe every few days. **Matthias Benkort**-: Yeah, that's good. Yeah, if you can only work on that, for instance, once every two months, that will be a bit longer to iterate. "Talk to me, Matthias, if you need IOG involvement." Of course, Kevin, talking to you every day. Or not every day, okay. And yeah, we can definitely try to follow that up, Kevin. Thanks. What else do we have? I'm pretty sure we had also a similar proposal from Tobias, actually. I've seen it on the forum, but I'm not sure if you opened the pull request or not already. **Michael**-: Not yet. We've been in communication about it. There are some structural differences between our [inaudible] the R over one plus alpha term end, and define an extra perimeter L, whereas I decided to take out the one over one plus alpha term and recast alpha entirely. **Matthias Benkort**-: Okay. We might actually end up with only one proposal maybe, or are you just still, do you know if he's still thinking of making a competing proposal and maybe [crosstalk]? **Michael**-: I'm not sure. I want to make he's got the opportunity to submit it and submit a pull request, if he wants to, and anybody else, and any other prior formula change, equation change, because in review, all of these different variations should be tested together as a pool with the same methodology, including the old equation at a couple of different parameters. And I included a section of my CIP on how we should change the paradigm of how we analyze these proposals going forth. **Matthias Benkort**-: Yeah. Okay, okay. **Michael**-: It should be an inclusive process. **Matthias Benkort**-: Yeah, definitely. But the challenge actually is really to, as you just said, to find maybe a common way of assessing them and judging them according to some common criteria as to then make a decision. Yeah, and maybe there is not one good answer. Maybe there are multiple ones. And then, at some point, there will be a choice to be made. And that's exactly why we have catalysts also, so the community can choose eventually. **Michael**-: I'm also fully aware that, as we analyze this and peer review this, there could be a hybridization of ideas that would occur, a cross-pollination between different CIPs, and the form of the reward equation could change to something new that hasn't even been considered yet. It's not impossible. **Matthias Benkort**-: Yeah, yeah. And it's not impossible so that all those CIPs end up merging into one common proposal that has one common structure, which will be from the ultimate goal. And it will make the choice wager for the community as well, if you have only a choice to vote between one thing and one thing that's easier. But yeah, so we'll see. Okay. What else do we have on the table? Maybe tech, tech, tech. #### PR224 [PR224 - Add Proof of Existence record label to registry.json](https://github.com/cardano-foundation/CIPs/pull/224) **Matthias Benkort**-: I see there is a small pull request, 224, which is adding a new label to CIP 10. That's something Robert has already comment in them. Yeah, okay. That was good comment. Are you still there, Maria, by the way? **M. Àngels Jover**-: Yes, I am here. Don't you see my screen? **Matthias Benkort**-: Nope. We don't anymore. We see Michael. **M. Àngels Jover**-: Oh. I didn't realize. It's this one, right? **Matthias Benkort**-: Yeah, so a small addition to the registry for which we typically ask for also a justification for that. It's a proof of existing claims. **Matthias Benkort**-: I'm not quite sure to understand the goal of it, but at the same time, it's no particular... It's just an addition to the registry which needs to be public and extended. Nothing against it, not sure what Robert and Sebastian thinks of it, if they have also got time to look into that, but it's small one enough. **M. Àngels Jover**-: Rob or Sebastian, any of you on to the common stage? Robert says, "I am okay endorsing it if it's a label people can understand and use or are already using." And Sebastian says there's nothing on his side. **Matthias Benkort**-: Yeah. Okay, so it also boils down to a conversation we had in the past on CIP 10. Maybe having a slightly clearer process of what it means to add stuff to that CIP 10, or if there is new conditions to it, we typically just ask people to justify the hashing on behind their label and why it would be useful, but that's beyond that. **M. Àngels Jover**-: You have approved it, right and it is going to be merged. **Matthias Benkort**-: Yeah, this is really a minor update on that CIP 10, so no particular issue. **M. Àngels Jover**-: You have both approvals, already. #### PR241 [PR241 - CIP-0989? | ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241) **Matthias Benkort**-: Yeah. We put the label, CIP 10, new entry. Okay. Then we have a CIP, so PR number 241, which is a CIP from John Woods, so IOG Director of Cardano Architecture, he's proposing new primitives or... This one is interesting because it seems to be about providing some form of identity authentication mechanism for tools, but I'm not sure if the motivation really came from SPO or not. Would be interesting maybe to bring it to the next SPO call that often happen on Discord and see when we have SPO commenting on that, since this is something directly affecting them or providing a benefit to them. **Matthias Benkort**-: Yeah, I'm not sure if anyone knows, or maybe Kevin, you know, when is the next SPO call planned? Yeah, I mean he's Robert, that's why I'm wondering. And I think that will be a good first step before doing anything with that proposal first, show it to the SPO and see what people think of it and if they actually also see a use case or benefits in this approach. Yeah, okay. Thanks, Robert. That would be nice. Otherwise, we can probably share it with a bunch of SPOs already that we know and try to get some community sentiment. I will ask John, or we can ask John also to share it on the forum, or I think there is still some activity also there, and people are looking to the forum a bit more than the report, I think. **Matthias Benkort**-: (Silence). **Matthias Benkort**-: Okay, so I'm just telling John to maybe, so what you just said, commenting on the pull request to see if we can bring it to the next SPO call on Discord, and also share the link and the CIP on the Cardano forum to get some extra attention there. That would be interesting. **Matthias Benkort**-: No confirm date for the next meeting. We are on roughly four week cycle, that's okay. The last one was last week, so this one could take a bit of time before we revisit it. We can maybe put it on triage for review for, not the next be biweekly, but the one after that. **M. Àngels Jover**-: In a month, right? **Matthias Benkort**-: In a month. Yeah, in a month from now, and have the conversation going with the SPOs in the meantime. **Matthias Benkort**-: (Silence). **M. Àngels Jover**-: Would we have time to review anything else? **Matthias Benkort**-: Maybe, but the question is more what is left to review from what we had. We could definitely... Oh, maybe not today, but start including also the issues in the reviews because as we said last time, there is not 15 issues that have been opened on the repository, and it's not really something we anticipated in the first place. We're mainly thinking about pull requests and how people would just submit CIPs as pull requests, but there are also discussions or side discussions happening in issues which are similar to what's the kind of conversation happening on the Cardano forum. #### PR188 [PR188 - CIP-36? | Update CIP-15 to support multi-delegation](https://github.com/cardano-foundation/CIPs/pull/188) **Matthias Benkort**-: Oh yeah, right. It took Giacomo suggesting to look at CIP 36, that we discussed last week. There was a bunch of updates to make to that one. It was the initial extension of the meta delegations that was then extracted as a separate CIP, but the author, Mark, got unavailable, so we brought it back to the original author. What we discussed last week was that we'll move it back, get a few updates to it which make the CDDL format forward compatible and have also the derivation path specified in the proposal. I did add the derivation path, and I think Giacomo, you've been working on the CDDL a bit. Yep, so then I think it's good to go. **M. Àngels Jover**-: Which PR is this one I don't know which on it is **Matthias Benkort**-: 188. It's a pretty old one. It's been over multiple bumps, this one. **M. Àngels Jover**-: This one right here, right? **Matthias Benkort**-: What is the new CDDL nowadays? **Matthias Benkort**-: (Silence). **Matthias Benkort**-: Maybe we can bring also Giacomo on the screen just to walk us through the updates. **M. Àngels Jover**-: Sure. **M. Àngels Jover**-: (Silence). **M. Àngels Jover**-: Inviting Giacomo. **M. Àngels Jover**-: (Silence). **M. Àngels Jover**-: Hey, Giacomo, you are on screen. **Matthias Benkort**-: Can you hear me? **Giacomo**-: Yeah. **Robert Phair**-: : Yes. **Giacomo**-: Yeah. I've looked at the consideration that were posted on the CIP at... I've select the amended, the wording, but CDDL is still the same as before, because I believe we can make that forward compatible by requiring all new credential to have a tag associated with them, but keep the stake key unpacked so that it's compatible with all CIP 15, that would allow us not to require everyone to register again, which is a concern on our side. **Matthias Benkort**-: Okay, because at the moment, any registration maybe in the past is valid for any subsequent round. **Giacomo**-: Yep, exactly. It would be a bit expensive if we plan multiple voting rounds to have everyone to register for each one of them. **Matthias Benkort**-: Yeah, and that would be more expensive. That would just be per UX, in a way. Okay, so that's a good point, but yeah, it's also possible to support both formats and have the backward compatibility while also making room for the next steps. **Giacomo**-: What would be the advantage? **Matthias Benkort**-: Well, you just said avoid re-registering, right? **Giacomo**-: No, I mean in supporting both formats, what about we just say, there's this untagged version, there is just the default, and it's the- **Matthias Benkort**-: Yeah, exactly. **Giacomo**-: For about everything else, CIP 36 is already compatible with CIP 15, or there are defaults, sensible defaults, which makes it compatible. **Matthias Benkort**-: Yeah, okay. I guess it would just be a question for another CIP or an update later on, on how do we introduce a broader variety of credentials without actually also breaking compatibility with existing registration? And we won't probably get away from still supporting the untagged version for forever, just for the sake of backward compatibility. Yes, I can. I think Sebastian also had a few comments on that last week, so I'm happy to prove it on my side. I'm not sure, since it was mostly also Sebastian's concerns, whether or not he is fine with the current proposal. **M. Àngels Jover**-: Maybe we can leave a last check for next week, next meeting? **Matthias Benkort**-: Oh, it was already last check for today, I think. We want to talk to Sebastian in June. Well, I will approve it on my end. We can see offline if also Sebastian is fine with it, and then merged it to move forward with it or not, depending on the outcome. Sebastian said, "Yeah, as long as made the forward compatible changes to the tech type, and good." Well, that's kind of the point of the discussion right now, that the forward compatible changes won't be made in that moment yet because they all also break compatibility or backward compatibility. **Giacomo**-: All new changes have attacked, then I think they're good to go. This is forward compatible. We will just have one untagged variant in this type, which will be the stake key. **Matthias Benkort**-: Yeah, we can introduce new ones as tagged. **Giacomo**-: There's no ambiguity in that. ### Close **Matthias Benkort**-: Okay, it's been an hour, so maybe we can wrap up and do a quick recap. We've been through the collateral output proposal, which was already in the last check state, but this one needed to have a right number allocated to it put in a corresponding folder on the CIP and then be merged as a proposal. CIP 37 are mostly waiting on the feedback from the research team. CIP 38, waiting for the author. The author has been pinged again. I've also got an answer from the Discord that they are still championing it, and they will be providing an update soon. Good. The CIP 30 event API, still also on hold, probably abandoned or not really going under all of discussions at the moment, so there is no need to pressure that on our side. **Matthias Benkort**-: CIP 42, I'm waiting also for the authors to adjust the status and justify the cost model before being emerged as a proposed CIP, also waiting for the implementation to be available on Plutus. We've also got an introduction on CIP 50 for which we'll want to follow up with our focus group, basically, involving various parties from research, from IOG engineering, from the community also, and they are getting to more discussions on the visibility of this CIP, also comparing it with other similar CIPs and see maybe if we can either convert to one solutions or have multiple solutions that can then be proposed through Catalyst for implementation. **Matthias Benkort**-: We also just went through CIP 36, which adds a multi-delegation support for the voting mechanism on chain, or more exactly, the voting registration on chain, so that we can have the catalyst voting happening. Agreed on merging that one as it is, and think about the introducing multi key support or scripts credentials later on. And I think we also added a new entry in the CIP 10 registry. And that is it. Thank you all for joining and see you in a month at this time, or in two weeks on your time zone. **M. Àngels Jover**-: It will be in two weeks at 9:30 AM UTC. At 8:30 AM, sorry. **Matthias Benkort**-: Yeah, correct. No, at 9:30, right? **M. Àngels Jover**-: I think it's two hours now, UTC, like [inaudible]. **Matthias Benkort**-: Oh, yeah, yeah, yeah, yeah. This [crosstalk]. Okay, right. **M. Àngels Jover**-: Thank you very much to all and see you in two weeks or in a month, and have a Happy Easter, those who celebrate it. **Matthias Benkort**-: Yeah. Cheers. Bye-bye. **M. Àngels Jover**-: Bye-bye. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-05-10.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [May 10 2022 Transcript](#may-10-2022-transcript) * [Triage](#triage) + [PR177 CIP-0005 | Add prefixes for output datum hash and script data hash](#pr177) + [PR181 CIP30: getUtxos null instead of undefined](#pr181) + [PR182 CIP-1852: fix broken CIP links](#pr182) * [Last Check](#last-check) * [Review](#review) * [Discussions](#discussions) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) + [CIP-0052? | Cardano audit best practice guidelines](#pr252) * [Issues](#issues) + [PR109 CIP-0003: Broken links on the website](#pr109) + [PR167 A public collateral and tx broadcast service](#pr167) + [PR168 CIP-0027: Covering existing policy locked assets](#pr168) + [PR169 CIP-0030: provide unique wallet identification](#pr169) * [Close](#close) ## Summary Rough transcript of 10/05/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://www.crowdcast.io/cips-biweekly), [recorded](https://www.crowdcast.io/e/cip-editors-meeting-44) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## May 10 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. **Guests**: Michael Liesenfelt **M. Àngels**-: Hello everyone. Welcome to the CIP meeting number 44. My name is Marie Àngels, and I work at the Cardano Foundation, and I am here to facilitate this meeting. Today we have Sebastien Guillemot and Matthias Benkort that will lead this meeting as editors of the CIP process. We have here in this "i" button the agenda that you can follow. It has direct links to the PRs that we are going to comment. And at the bottom, you have the ask questions button over here that you can use to ask any questions, or you can also add your questions in the chat box. So Matthias tell us, do you want to add anything else to the agenda that was not expected? **Matthias**-: Yeah, on my side, I would like to add PR 252. Reason being that this is a topic that will be discussed in the next workshop that is organized by IOG in Barcelona. So it was brought to my attention and this is a fairly straightforward CIP in a way, because it just describes best practices. But yeah, that's something we could just maybe have on the topic, discuss and see if people can comment already before the workshop so that the workshop can be a bit more productive. **M. Àngels**-: Okay. Do you want to add it to the discussion section, or do you want us to start with PR 252? **Matthias**-:Oh no, we don't have to start with it. We can discuss first the items on the agenda, I think. ### Triage #### PR177 [PR177 CIP-0005 | Add prefixes for output datum hash and script data hash](https://github.com/cardano-foundation/CIPs/pull/177) **M. Àngels**-: Okay. So, shall we start with triage? **Matthias**-: Yeah, let's go. **M. Àngels**-: PR177 CIP-0005 | Add prefixes for output datum hash and script data hash. Can you give, Matthias, a brief summary of this PR? **Matthias**-: Yeah. So we have CIP 5, which has been there for a while, which defines a bunch of prefixes that we commonly use for Bech32 encoding, which is used mainly for short binary data, and to have a way to distinguish them in human readable interfaces. Like that's the encoding we use for address, for instance. And that's why we have this ADDR in front of all addresses, but we use it in command lines for all the things, actually. So tool, IDs, scripts, V-Key hashes, et cetera. And this PR adds a new one, which is for datum and redeemers or more exactly datum hash and redeemer hash, which is used by the, how do you call that again? Hardware devices, right? So ledger and tresor to show on screen, when you have to validate your transactions, the PR is made by Gabriel from Vacuum Labs who are working on the hardware integrations. So I think, yeah, we approved that a while back already. So it's quite an old one. And that's about it. **M. Àngels**-: So shall be merged this one today? **Matthias**-: I would say so. I see it has now conflict apparently, so we cannot merge it. So we'll just have to resolve the conflict because there are probably been some concurrent dates on the CIP 5. So not a big deal, but yeah, we'll just merge it. If not during the meeting right after once the conflicts have been resolved. **Sebastien**-: Can somebody share their screen, just so... **M. Àngels**-: I am not sharing my screen? **Matthias**-: Nope. It's a bit black. **M. Àngels**-: Sorry. Thank you very much for raising that. Shall we move to the next PR? **Matthias**-: Yeah, unless there is any objection on that one, but it's been there for yeah, a few months we just forgot about it. **Sebastien**-: Yeah. So for CIP 5, if I can just briefly add, so we also have a separate PR related to CIP 5, which adds a reference implementation to it. It'd be good if we get that merged as well. Considering that... Validation is just re-parsing every single file. **Matthias**-: So PR 251, right? **Sebastien**-: Yeah. **Matthias**-: Which is a reference implementation of what exactly? Of all the prefixes right? Made a package for, an NPM package. **Sebastien**-: Yeah. Yeah. It just gives you an adjacent object of just key and value and then it adds comments for you that describes the different keys. **Matthias**-: Okay. No, I mean, that's interesting to have, I guess. Do you automatically sync it from the repo or is it something manual? **Sebastien**-: Yes and no. So it generates JavaScript code from what we have in the repo, but what we have in the repo is not exactly machine readable. So you need to like convert from human readable to machine readable and then... [inaudible 00:06:06] **Matthias**-: Could it actually, maybe be also something we could do on the CIP 5 instead of this, this markdown table have a, just a big JSON file actually? **Sebastien**-: Yeah. I considered up-streaming this change, let me send the link in chat. So if you open the link in the chat. **Matthias**-: Yeah. I'm already on it actually. **Sebastien**-: Okay. Yeah. This is my human readable version of the markdown table. **Matthias**-: Yeah. The the machine readable. **Sebastien**-: Yeah. And then basically this reference validation takes the JSON file and then generates JavaScript code from it. **Matthias**-: Yeah. So yeah. Okay. No issue with adding that as a reference implementation indeed, but I would maybe consider also moving it upstream, the JSON part, like we've done for CIP 10, right. So that we've got something which is machine readable and then with tooling on top. **Sebastien**-: Yeah. Considers that the markdown file is easier to read for it to give context. **Matthias**-: Yeah. **Sebastien**-: So I'm not sure if we want to like generate a markdown from the JSON as well, but I'm not sure if we had like a good system for automatically... Generating markdown files. I remember we had this problem previously of like automatically generating files. **Matthias**-: Yeah. I'm betting markdown files like that, as it, sorry... JSON files like that as a markdown table could be nice, but yeah, definitely if we want to do generation, that's easier in this direction from JSON to markdown than from markdown to JSON. Okay. **Sebastien**-: Yeah. But mostly I would want to check, we don't have any CI resources to generate the markdown from JSON. If we remove the mark down and replace with JSON OEM and generate the markdown automatically. **Matthias**-: Okay. I mean, fine like that, but just, or just comment on that. Okay. So yeah, I think we can just proceed with these two. I will do it after the call. Okay. What do we have next? #### PR181 [PR181 CIP30: getUtxos null instead of undefined](https://github.com/cardano-foundation/CIPs/pull/181) **Sebastien**-: Yeah, this is a bug in the current CIP 30 spec. Basically we right now specify that the function returns undefined in some cases, but undefined is not a valid JSON value. You can only use null. So basically changes. **Matthias**-: Oh. And you can only serialize to JSON, right? Through the web browser API. **Sebastien**-: Yes. **Matthias**-: Doh. **Sebastien**-: So if you pass undefined, it gets silently converted to null. So just to avoid people making bugs just to change this back, please. **Matthias**-: Okay. I can't find it though. It's what number again? It's sorry. It should be the agenda. Yes. But why can I not access it? Ah. **M. Àngels**-: You can not access the agenda? **Matthias**-: No, it was me. I was putting an extra S in the URL. Yes. Well, I wish we had proper sum-types, but I guess we won't. **Sebastien**-: Yeah. I think this API is kind of ugly anyway, but you know, we can fix it in a separate PR, at this point we can just... **Matthias**-: Yeah. Yeah. And there has been discussion recently as well with this wallet connect API, right. This recent and NFT launch of Instagram which uses it slightly... **Sebastien**-: Yeah. But that will work very differently from CIP 30. **Matthias**-: Yeah. It's a bit of the same spirit though. Oh, except you have this extra bridge in the middle and the way things work on Cardano are a bit different, but maybe there is also room for alignment a bit. I'm not sure if you would simplify anything for external people to integrate. I think CIP 30 is mostly fine as it is, except maybe the versioning part that we mentioned last time, which I'm still willing to make a pull request for. **Sebastien**-: Yeah. But in the meantime, I think we can merge this PR because it's just a small fix. #### PR182 [PR182 CIP-1852: fix broken CIP links](https://github.com/cardano-foundation/CIPs/pull/182) **Matthias**-: Yeah. It's fixing a inconsistency. So next one, PR 182. No, what is it? Yeah. 182. Which is fixing some broken links yeah. Was approved a while back and we could just go for it. So the issue is that some of the CIPs reference other CIPs sometimes using relative links, which works on GitHub, but don't necessarily work on the website. So it's slightly better to use absolute URLs to make sure that, you know, things works on all platforms. We discussed that briefly on the issue and it's only about one of the CIPs anyway, but that's something we should be a bit careful with when merging new CIPs as well. So we've approved it. So unless someone has anything to say, also I'll just go ahead and merge it. Okay. All good then. **M. Àngels**-: Now I have added to the agenda, some issues. Do you want to review this or do you want to leave them for after the discussion point, which are the CIP 50 and the one you brought at the beginning? **Matthias**-: Yeah. Let's first talk about CIP 50 and the audit guidelines first so that we have time. And then if time is left, we can go for issues, which are a bit more minor points. **M. Àngels**-: Okay. **Matthias**-: Do we have Kevin today or not? No... **M. Àngels**-: We have Michael but not Kevin. ### Last Check ### Review ### Discussions #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias**-: Yeah. So maybe Michael knows, actually. So there was this discussion a few weeks ago to start a study group on CIP 50 with people from IOG and this was something Kevin picked up and was sorting. I'm not sure if it has happened yet or no. It hasn't happened yet Michael, okay. So that's something we'd need to follow up with. I know Kevin did reach out to a few people and it was acting behind the scene to get it done, but yeah, I will just reach out to him. Yes, definitely. Vasil has brought some attention already. But yeah, there are people I think we can, from whom we can pick their brain to just start thinking about that who are not directly involved in Vasil. Okay. I will just reach out to Kevin and ask him if he has any update on that regarding this study group. Maybe you can bring Michael on screen, if just for a short time, maybe you have had also some discussions on the side already or got any feedback that you want to share? **Michael**-: All right, here we go. There's always many discussions on the side about this particular CIP, the very important CIP in many ways. So this will be continued to be [inaudible 00:16:12] feedback of individuals including yourself. **Matthias**-: Yeah. Okay. So I guess this is also one of the CIPs where it would be worth maybe giving some summary of discussions every week. So I haven't gone through the whole discussion thread I admit yet, but I will try to yeah... Post summaries a bit like we did for the... Oh, what was it? The NFT standards. And CIP 30 actually, back in the days. So we get some yeah, regular point of synchronization where we can move the discussions a bit forwards. **Michael**-: That seems reasonable. And when we want to schedule any kind of meetings or debate or review on the scope of the CIP. I know at a prior meeting, you mentioned doing that in a side channel, in a different format, as long as it's public and anybody can join, that would probably be a benefit. **Matthias**-: Yeah. So that's the study group I was mentioning and that's something that could actually be done publicly. I was thinking more initially that this could be a closed study group just to have it review and post actually the notes and the outcome of the meetings on the CIP but being public will also make sense. As a kind of discussion forum, which is just managed by the fixed bunch of individuals. I'm just writing to Kevin and okay. If we don't have anything more for this week, maybe on this one, we can leave it there and yeah. Move to the next item. #### PR252 [CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252) **M. Àngels**-: . So next item, I would say that this is the PR 252 that you wanted to comment, Matthias. **Matthias**-: Yes. Oh, more than commenting. Just bring to the attention of the CIP enthusiasts. The audit best practice guidelines. So this was a document that was written mostly by Simon here, in discussion with the various auditing parties that are currently involved on Cardano. And the main idea is to give some general guidelines for DApp developers who wants to have their apps audited by those auditors, such that there can be some form of common format for sharing information on what your DApp is doing. What's the expected outcome while your contract high level interface and sort of make the whole audit process more streamlined. So that means most of what's written in the CIP currently has been reviewed by the auditing parties. And now it's more question of getting that reviewed a bit more by the community, as you know, because this is a two sided discussions. And as I was saying, there will be a workshop organized by IOG in Barcelona next week, actually. **Matthias**-: And this CIP would be one of the topics during that workshop. So that's why Simon wanted to get some attention on it. I've already done a first round of review getting some feedback, I think in particular, that there is one part which could be extracted as another CIP even, which is this whole idea of a specification language for the contract interface, a bit like open API, but for on chain scripts, right. Where you can clearly specify or state what's your datum, what's your redeemer, what's your transaction structure invariance and stuff like that, which is touched a bit in these CIPs, but more as a side topic. And that could be an interesting standout in itself to have. And that's all I have to say about it. So we will leave it there for commenting and maybe have it in the next biweekly for a proper review. And then yeah. See how it goes. **M. Àngels**-: Okay. So we are going to move this for review for the next meeting. And I guess there, you will have information gathered in this workshop that you are having next week, right? **Matthias**-: Yeah. So hopefully there will be also, yeah. Another batch of update after the workshop. And yeah, since there are mostly guidelines, there isn't much to discuss really on the technical side of it. So I've made a few suggestions just on the editorial aspect, moving some sections round and maybe renaming a few things. But apart from that, it's pretty straightforward. And it's really coming from all the auditing parties. So if anyone wants their DApps audited they'd rather just follow the guidelines. **M. Àngels**-: Nice. Very useful and very interesting. So anyone want to comment on this PR? **Sebastien**-: No, I think it makes sense. I wanted to check, so did she want to merge this before the event or after. The main part of the event is just discussing this document right? **Matthias**-: Well, that's what I told Simon basically, we won't probably get it merged before the event, just because of the whole process happening. And I want to let people have a chance to discuss it, because maybe there are some of the guidelines that don't make sense from a DApp developer perspective. So far it's been mostly reviewed and written with the auditing parties, so I want to give enough time to discuss it. And since this was submitted only a few days ago, I don't think we have... It left enough time until the workshop. So if we have it already, in good shape for the workshop and kind of ready for review that's good enough. Okay. So maybe we can move to a few of the issues, or we have something in the chat, someone who was employed in order to look at your smart contract and review it and add any comments. Thank you very much. ### Issues #### PR109 [PR109 CIP-0003: Broken links on the website](https://github.com/cardano-foundation/CIPs/pull/109) **M. Àngels**-: So if you want, we can move to the issues. We can go to PR 109, just a quick recap. The issues are located here and... Please Matthias correct me if I am wrong, it weren't intended to be used, but as are being used organically. **Matthias**-: Yeah, exactly. We didn't really thought of what to do with issue initially. And there are nothing in the CIP process that mentions opening issues, but yeah, just happened. And now we have a bunch of issues to go through, which is also a nice medium of discussions in a way for people that just want to yeah. Be part of a discussions on the CIP and yeah, don't have anything to put in a pull request because that's also something right now we want to see CIP is merged. You don't have much way to comment on it, except if you do another pull request, but sometimes if it's just questions or general discussions, maybe an issue is better suited for that. So I guess we just need to get issues as part of the triage that we do, and make sure that we pick relevant issues every week as well. Or every two weeks. So this one's broken links on CIP 3. What is CIP 3 again? The wallet key generation, the history table. **Matthias**-: Yes. I guess this is the same problem as we were stating before that it's probably using relative URLs and here on the website, it doesn't work. So let's check that. Yes, exactly. So we can fix that by using absolute links. And I think this is maybe what Robert is suggesting. Yes. Require absolute path name in the CIPs. So I will maybe add to the to do here, fix broken link. Okay. So we can fix it the same way that was done for CIP 1,851 previously by changing the relative links to absolute links. And we're good. #### PR167 [PR167 A public collateral and tx broadcast service](https://github.com/cardano-foundation/CIPs/pull/167) **Matthias**-: Next one. PR167 A public collateral and tx broadcast service **M. Àngels**-: I think that this one Robert commented that there wasn't enough information and there's not been follow up from the author. **Matthias**-: Yeah. I guess it was intended to be a draft CIP maybe. But it's very tiny draft and yeah, okay, guess I get the spirit, which is mostly now covered by the extensions that are added to CIP 30, right? The was recently, this discussion around adding this, get collateral functions to this, the CIP 30 interface, which is kind of exactly answering that topic, except it does it locally from the installed wallet than through a remote service. So I think it would just add a label waiting for author. Any comments also on this get quality role? Okay. #### PR168 [PR168 CIP-0027: Covering existing policy locked assets](https://github.com/cardano-foundation/CIPs/pull/168) **M. Àngels**-: Shall we move? The next one. Okay. PR168 CIP-0027: Covering existing policy locked assets, so what is this one about? **M. Àngels**-: Is there discussion in this one? It's... **Matthias**-: So it's again about royalties on NFTs that are using the phase one monitoring script. So this is indeed a whole discussions about how to enforce royalties on NFTs. And the idea would be to lock existing assets that have been minted previously into a contract, but with scripts that would make sure that the royalties are enforced correctly on every transactions and exchanged. Then there is whole thread of comments, mostly with a solo I see who was, if I remember correctly, the author of the CIP 27. Or if not just contributing to discussions back in the days, at least. **Sebastien**-: Do we want keep going over these issues? I feel like a lot of them feel like just drafts and I [inaudible 00:31:43]. **Matthias**-: Yeah. Many of them are draft or just starts of discussions. And maybe they are fine to just leave us as discussions until they make it as a pull request. But then we still need to do some form of issue managements at least to close the old discussions and, do a bit of house cleaning. I don't think we will go through the whole thread of discussions on that one just here. And it hasn't got any updates for about six months also so I'm not sure if the discussion has settled or not in the end. That's one we need to go through and read, and see what's up, but right now it just seems like an idea that sounds to have been abandoned, but I'm not sure. **M. Àngels**-: Shall we ping the author and... **Matthias**-: Well, we should read, read the conversation thread first and then see if it's... I would say we have two outcome already, either we ping the other to see if it's still relevant based on what we've read in the thread, or we just close the thread completely, close the issue from being, resolved and installed. And if they ever want to come back to it, they're free to reopen the issue and... Or make a pull request actually acting on it. But first I would like to get a sense of what's being said in the thread. **M. Àngels**-: Do you want to add to the agenda in two weeks to check if you have time to read it or to go and read it, or do you want to it a month? **Matthias**-: I would say for now we don't add it to the agenda. I will read it. And if it's something that we want to add to the agenda in the sense that the discussion hasn't been settled, then yeah. We'll just add it. If not, then I will close the issue with a comment explaining exactly that. **M. Àngels**-: Okay. **Matthias**-: Yes, indeed. And as is saying in the chat, there is a lot of controversy over whether you should be able to add royalties to a project which did not need them within the original policy. And this is indeed a topic that's been discussed in the past here. So I think this is part of what the thread will be about. People disagreeing about whether or not a CIP makes sense in itself, but it's also two separate concerns in a way. That a CIP in the end is just a proposal always. And whether or not these proposals end up being adopted by marketplaces and projects, that's a different topic. So if the proposal makes sense from a technical standpoint and it's something that could indeed be implemented and not lead to security issues or stuff like that, that makes for valid proposal. And you may still disagree with the proposal and not implement it, that doesn't discard the proposal from being proposed. But if there is indeed no proposals, then we can just close it. Maybe for just a discussions, like have an idea. What do you think? Bad idea. Okay. Close it. **M. Àngels**-: Do you make any comment on what Matthias just commented or shall we move forward? **Sebastien**-: Only to agree. #### PR169 [PR169 CIP-0030: provide unique wallet identification](https://github.com/cardano-foundation/CIPs/pull/169) **Matthias**-: Next one is PR169 CIP-0030: provide unique wallet identification When trying to integrate light wallets with the Plutus application backend, I came across the issue where I need to, I need the wallet ID before activating the contract. Yes. And currently the PAB, I guess, uses the wallet ID from Cardano wallet, which is a hash of the verification, the hold verification key of the wallet. And that is indeed not something which is remotely specified anywhere. So, okay. I will maybe just comment on that. **Sebastien**-: One thing is that we do have a CIP for like a wallet checksum. Which is kind of similar in concepts, right? So obviously it does the same thing, which is a hash of the wallet's public key. And so they can request for a CIP 30 feature that exposes this checksum. Or implement something similar. But I'm not sure if this is enough that could fit the standard requirement for a wallet ID or do they want something more like a key exchange, ephemeral key as an ID? **Matthias**-: Well, from what I read here, I guess the strategy is really just to have an identifier for the wallet, which is unique enough for wallet. So probably the checksum would also be sufficient, but maybe what form would it take to checksum? The question is, the checksum is meant to be represented as image right, but you can also just represent it as a sequence of bytes. **Sebastien**-: Yeah. There's an image format and there's also a text format. The text format is like a characters line, I think. So it obviously has a lot of quotients that should be enough. **Matthias**-: So I guess that there is really two questions in one, in a way, there is what exactly is the ID format and specific used by EV and Cardano wallet currently. And the second question is, what kind of ID do we want to use more generally speaking for wallets? And that's something which could be, for instance, part of CIP 30, indeed. You ask for wallet identifier, and you get something which is in the same format. That could be the checksum specified by CIP 4, or that could be indeed the wallet, the ID used by the Cardano wallet at the moment, the advantage of using the CIP 4 one is that it's already specified. So we've already got it out there. So we can just point to this one. And if we want to use the same as Cardano wallet, then there is a small CIP to write. **Matthias**-: Or at least this part of the specifications to write. It's not much right. It's basically just, what I've written as a comment here. So I'm not sure it's worth a whole CIP but it could be part of the CIP 30 to say that's, but this suppose also that a wallet is using a hierarchical scheme, or at least some key that is following the key generation from CIP 3, which I think must wallets do, if not all. I know Nami is a bit special in that regard, but I think they still follow the same derivation tree. Right. They just happen to use only one key of that tree. **Sebastien**-: Yeah. **Matthias**-: So in that sense, yeah. They, they could all be using the wallet ID from the Cardano wallet. I'd like the checksum in a way, especially because it also come with this image part. And then you can think of all sort of flows where upon validating or signing a transaction, for instance, you can display again, the checksum just as an anti... **Sebastien**-: One idea we had for [inaudible 00:41:24] in the past is that we had this checksum, right? **Matthias**-: Yeah. **Sebastien**-: But we also, at some point we're considering some sort of way to connect your transaction metadata to Dropbox or something similar. So you could have off chain transaction metadata that's local due to you. But to do this, you wouldn't want to upload the unencrypted data, you want to encrypt first, but we don't want to encrypt it with your account key because then to approve the encryption, you would need to provide the account public key. **Sebastien**-: So we had this idea of coming with a new derivation path with a different purpose. So if you have the root recovery phrase, then you could generate a different key path, which would be like a utility key path. With the utility key path, you could have the wallet checksum key used for the wall identifier and then a wallet encryption key use for off chain, transaction information, and so on. And so make it slightly easier for people to cope with standards in non complicated ways, instead of always relying on the master public key. **Matthias**-: In CIP 4, what key is used here to compute the checksum? Is it directly coming from... **Sebastien**-: The public key. **Matthias**-: The root public key as well? **Sebastien**-: Not the root public keys, it's the account public key. **Matthias**-: Okay. The account public key. Okay. So you have one checksum and per account, not per wallet in the end. **Sebastien**-: Yep. Because the main reason that was created was to make sure that users are restoring the right wallet. [inaudible 00:43:15] the account they were restoring is correct. **Matthias**-: Yeah. But CIP 30 operates at the level of wallets. **Sebastien**-: No, it's still account based. **Matthias**-: Still account based? **Sebastien**-: You're getting addresses for an account. You sign with an account. **Matthias**-: And okay. Then it's up to the wallet to decide which account I guess, because there is nothing in API that's that lets you select the account. **Sebastien**-: Yeah. It's when you enable CIP 30 the wallet will show you a dropdown asking you which account you want. **Matthias**-: Okay. So it could still work for that then. **Sebastien**-: Yeah. **Matthias**-: Okay. The idea is clear, but there is the question of making it a proper extension to CIP 30. At the same time, last time we said, we might want to sort of freeze the CIP 30 as it is now and have new extensions come as new CIPs just for the sake of having one core, which is fixed, but this thing feels also quite core in the end. So it could be just added before we freeze everything. Yeah. Okay. So from me, at least I would be quite in favor of extending the CIP 30 with a `getWalletId` or `getWalletChecksum` functions that would implement CIP 4, and have that as a the wallet ID, if it's ever needed by a DApp for any form of identification. Hmm. It's interesting 204, but we cannot actually do that with add to 5519. We can do it to convert to 5519. So we need to convert or translate the key, which is not unfeasible, but it was not quite recommended back in the days. **Matthias**-: Anyway. Okay. So I guess that's about it for these issues. The author also hasn't been quite responding for a few months, so I guess we can just put it as waiting for author for now and see if... Yeah. Maybe make a pull request to extend CIP 30 and add this checksum to it. **Matthias**-: On a side topic or coming back to the CIP 50 topic. Kevin just told me basically has pinged a bunch of people, has got in touch, but for now indeed all the bandwidth is taken for the Vasil hard fork. And therefore there is not much people available from IOG to review that. So we might as well just start a study group without IO and get various people from the community. I think it's already started anyway on the issue itself on the pull request itself. **Michael**-: Are you suggesting a Crowdcast fork in some way? **Matthias**-: No, but that's actually a nice segway to one thing we need to announce as well. We want to move away from Crowdcast to Discord. We have set up a Discord server for the CIP. And in there, so there will be voice channels available and we could definitely use one of them to discuss the CIP 50. So yeah, as a kind of fork of the current biweekly, or more as a yeah... Side meetings that could be done there. Maybe we can already share the link to the Discord. **M. Àngels**-: Yes. **Matthias**-: Because the next biweekly, and ones after would be held on Discord, at least for starter, we have also things in place to record them and they will be published on a YouTube channels. And will have also then the proper chats on this call as well to discuss. And we'll be able to have more people onto on the speaker side, if needed, as we've been a bit struggling with that in the past where people had to jump on and off the voice spots on the broadcast. **M. Àngels**-: I am getting the invite to share. **Matthias**-: I will also share it then on Twitter later on, and we possibly have a list of all the people that are registered to the Crowdcast meetings currently. I'm not sure if we can reach out to them through some kind of mailing or something, but we should also put it on the readme, I think, of the CIP repository so that it's available in place. **M. Àngels**-: This is the channel, and here you have the invite. And as Matthias said, we are going to share this in Twitter, right, and identify all the attendants. **Matthias**-: Yeah. So try to reach as much people as possible with this because the next biweekly will be done on this... **M. Àngels**-: What I was thinking is that maybe we can create an event in Crowdcast because we are going to maintain the subscription while we are testing Discord. And in the event... At the invite link and said that it's going to be held on Discord. **Matthias**-: That's a good idea. And at least maybe just jump on the Crowdcast for the first, like two minutes and tell it to people who have missed the announce, at least for a few weeks. That could be, yeah. Good idea. ### Close **M. Àngels**-: Perfect. Matthias, do you want to wrap up the session with a summary of what we have talked about today? **Matthias**-: Yeah. So let me go back through the links. So we had CIP, a new prefix for reading redeemers and datum to CIP 5. We agreed on merging. That pull request currently has conflicts, so we just need to resolve the conflicts first. Then there is a small bug fix in the specification of CIP 30, where we have to use null of undefined, because ultimately it needs to be JSON compatible. A bunch of broken links also that were fixed for CIP 1852 and also for CIP 3. So not fixed, but mentioned, and we will fix them along the way. **Matthias**-: We discussed a bit CIP 50. So there has been quite a lot of discussions happening on the pull requests, which we would need to go through. There is not much movement on the study group from IOG and research on this area, mostly because of the upcoming hard forks are taking all the bandwidth. I'm in touch still with Kevin on that to get this happening. Otherwise we can already get started on the new Discord with this. What else we discussed, went through a few issues. Most of them were quite old actually. So we haven't got news from authors for a bit. There is one in particular that we want to go through and read because there is a quite whole thread regarding NFT royalties, which is a quite controversial topic, indeed. **Matthias**-: There is one other, which was quite interesting about providing a wallet identification mechanism and adding that to the current CIP 30 API. So we discussed maybe using the checksum specification that come from CIP 4 and have that required as one of the functions available in the API of CIP 30. And finally, I think we discussed pull request 252, which is the Cardano audit best practices guidelines, regarding... So guidelines for people that want to get their DApps audited. There will be an upcoming workshop with pretty much all the auditors, I think in Barcelona organized by IO and the CIP will also be discussed there. So if there is any feedback to provide, that would be good to do it before that. And that's it I think. **M. Àngels**-: Yes. Next meeting is going to be in two weeks and it's going to be in the US time zone. It's going to be at four UTC and it will be held on, let me check the day, the exact date, May 24th, 4:00 PM UTC. **Matthias**-: Yeah, on Discord. But still maintain the Crowdcast invitation links, at least for a few biweekly meetings still. **M. Àngels**-: Thank you everyone to join us today and have a nice day and week, bye bye. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) ================================================ FILE: BiweeklyMeetings/2022-05-24.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [May 24 2022 Transcript](#may-24-2022-transcript) * [Triage](#triage) + [PR241 CIP-0989? | ISPO KYC_CDD](#pr241) + [CIP-0044? | Additional factors for NFT market verification](#pr226) + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163) + [CIP-0039? | Smart Contract Software Licenses](#pr185) + [CIP-0046? | Prepay Min Fixed Fee](#pr190) * [Last Check](#last-check) * [Review](#review) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) + [CIP-0052? | Cardano audit best practice guidelines](#pr252) * [Discussions](#discussions) + [CIP-0014, CIP-0015, CIP-0016, CIP-0025, CIP-0028, CIP-0029, CIP-1852, CIP-1853, CIP-1855 status updates. ](#pr256) + [Bootstrap first draft of the Plutus contract blueprint](#pr258) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 24/05/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## May 24 2022 Transcript **Attending Editors**: Matthias Benkort, ~Duncan Coutts~, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. **Guests**: **M. Àngels Jover**: Can you give me a few minutes? I will connect with Sebastien, Robert, and Matthias. **M. Àngels Jover**: Hi, sorry. I thought that by default you weren't on mute. **Robert Phair**: Oh. Can anybody [inaudible 00:02:51] ? My mute button that away. Can anybody hear my voice? **M. Àngels Jover**: Yes, Robert. **Robert Phair**: Okay, thank you. **M. Àngels Jover**: We hear a lot of background noise. Maybe we can do something. Let me... **Robert Phair**: I have just one question; how do we send text messages while we are looking at each other's faces here? **M. Àngels Jover**: I would use the general channel to ask questions. **Robert Phair**: Okay. To open a separate window, yeah. Okay. I'll have to duplicate this tab and then... Okay, I'm using the web-based Discord. Okay. Yeah, I'll see if I can get that to work. Okay, I'm muting my mic when I'm not talking, because I can't suppress this noise. Okay, thanks. **M. Àngels Jover**: This is going to be a test. This is the very first time that we are doing the CIP meetings on Discord, so please bear with us if everything is not going as smooth as we expect to go in a few weeks. So welcome everyone. This is CIP meeting number 45. I am going to share the agenda with all of you. It is in the event... **M. Àngels Jover**: Oh God, so many new things today. Well... I'm sorry. **M. Àngels Jover**: Yeah. **M. Àngels Jover**: Well, I have the agenda in another place, so don't worry. We are going to rapidly sort this out. We have today with us, Sebastien Guillemot, Matthias Benkort, and Robert Phair as editors. In the agenda today we have in triage PR241 CIP-0989? | ISPO KYC_CDD. So I'm going to share this and maybe some of the editors want to make... A brief summary on it. Matthias, Sebastien, I haven't heard you, but I have unmuted you. Can you speak? Are you able to speak? **M. Àngels Jover**: Sebastien is typing. **Matthias Benkort**: Oh actually, yes, maybe. **M. Àngels Jover**: Good. **M. Àngels Jover**: I don't think it's my mic. Okay. So do you want to start with this first item on triage? ### Triage #### PR241 [PR241 CIP-0989? | ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241) **Sebastien Guillemot**: Yeah. So, whatever, back to getting stuff set up. Yeah, this was proposed by IT, as a way for basically people who participate in ISPOs to KYC themselves, I did not see anything particularly wrong with the proposal itself, other than the fact that it uses LaTeX inside Markdown. But I think that will actually coincidentally support this very soon, if not already... Maybe it's already set. I think the main thing for this is that we probably need to Stake Pool input on this one, because they're the main people that will be leveraging this. And so far, there hasn't been any Stake Pool that has... Commented on this. I know that Robert, you reached out to SPOCRA to see if they had any input on this. Did you hear back from them yet? **Robert Phair**: Yeah. It's mainly to just see if they had any objection. And there were probably one or two Stake Pool, if I know, that would've had... If there were objections for privacy implications, they probably would've raised their voice about it. I think like you said, it's just a friendly for voluntary participation. So it is in the KYC which can be... For us, it will be mandated for projects anyway, and they just want a reasonable way of doing it. But I think the fact that there were no objections, it sort of implied consent. I haven't been able to take anything, not farther than that. **M. Àngels Jover**: I think that communication is going to be challenging today, because there's a lot of noise Robert from your side. **Sebastien Guillemot**: Yeah Robert, can you try getting the native Discord application instead of the browser version? It will probably help improve the audio quality. **Sebastien Guillemot**: Okay. So what do we want to do with this CIP then? Do we want to wait until we get more feedback? I mean, I personally do not find issue with it. So if there isn't any feedback from everybody else, I don't mind... Moving along. It'd be good to get some feedback from more than just one person on this though. I do know that has some cryptography as well. Personally, I did not see an issue with the cryptography being used; I think it's fairly standard. But I'm also not a cryptographer either, but we've done stuff similar to this in other CIPs in the past. So I don't think this is an issue. **M. Àngels Jover**: So shall we leave a little bit more time to get more comments and maybe discuss it in a few weeks Sebastien? **Sebastien Guillemot**: Yeah, it could be good to get least one person who's not... Who is with Stake Pool to comment on this, it would be my preference. You could possibly ping IOG to have them more explicitly get feedback on this. Because usually people post their CIPs in the Cardano forums or some other location if they haven't done any of this. So we also can't really blame people for not engaging with the CIP. **M. Àngels Jover**: So what would be the next steps? Reaching someone of at IOG and try to get them involved with this one? **Sebastien Guillemot**: So this proposal is by IOG. They're the ones who wrote this proposal. So it would be asking IOG to more practically reach out to Stake Pool for comment to see what they think this. ##### Discord discussion on the PR **rphair [COSD]**: That sounds good to me & I'll send another (second) call to SPOCRA but I agree it would be good to ask Ben O'Hanlon to PUT IT IN THE SPO NEWSLETTER @ IOG Ben is usually responsible about getting ahead of these issues #### PR226 [PR226, CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226) **M. Àngels Jover**: Okay. So I have taken note of that. This was opened by John, so maybe comment that with him. So if you are okay, we can move to the second item on the agenda, which is PR226, CIP-0044? | Additional factors for NFT market verification. We can see this here. Maybe Sebastien, can you make a little summary of this one? This was requested by Matthias to have this PR commented in this session today. **Sebastien Guillemot**: What did he recommend? **M. Àngels Jover**: He pinged me and said that it would be good to review this one. Here we have the comment. Let's maybe have this one on the agenda for the next CIP meeting. I feel it kind of missed to include it earlier. I don't know if Matthias is having issues with his mic. **M. Àngels Jover**: Maybe I haven't unmute him. **M. Àngels Jover**: I don't know why I can't unmute him. Oh, I mean real-time issues, right? We can always go back to Crowddcast if this is still happening. Hi Matthias. Now I can hear you. Or almost. **Matthias Benkort**: This almost works actually. **M. Àngels Jover**: Yeah, yeah. Clear and loud, yeah. **Matthias Benkort**: Okay. Okay, good. So yeah, I just said that at the time to bring attention to the CIP, just because yeah, it was hanging there, but we sort of missed it completely. So I don't think of necessarily doing a complete review of it, or a need to take any actions on it just yet. But it's more to... Yeah, to track this and bring it to the light. **Sebastien Guillemot**: Yeah. So this CIP will not run into the same discussion we had for CIP 25, the NFT standard and the same discussion we had for... I forget the number of the one for the fungible token standard, which is to say that some tokens are already minted, but want to add this data after the fact. **Sebastien Guillemot**: So the problem with this proposal is that, they're basically saying, "Oh yeah, you'll use the same policy for... And you made it a 808." This doesn't help existing projects, and doesn't describe what happens if somebody overrides their existing media in the future. But this is more of a Cardano issue than an issue with a specific proposal. And I'm not sure if there's anything that they can do with this. **Sebastien Guillemot**: Since this proposal is isolated to a new metadata tag, a new label, it's not overlapping with anybody else's proposals. So I don't think frankly speaking, there's a reason to reject it, given that it... There's no kind of overlap with other people that have, so this isn't stop people from making competing standards. I think the proposal itself could be refined a bit. Right now it's kind of unnecessarily long for Twitter links and some other stuff that probably should not go into the CIP itself. So we are going to do this kind of material cleanups. **Sebastien Guillemot**: It'd be good to know if anybody intends to actually implement this specific standard. So we could just say, okay, well, there's nothing wrong with this standard, headway speaking. And it's a fairly simple one too. So we could merge it, but it'd be good to know if there's at least one marketplace that actually is interested in this idea and to see what they think, or if this is just a one-time standard. Do you know if any marketplace has commented on this issue? I don't think so. I think all these links are just people who think it would be a good idea to have something like this. **M. Àngels Jover**: I mean, we have comments from Matthias, Robert. **Matthias Benkort**: No, it has been showing a few tweets. I'm not quite sure. I haven't checked, so I'm not sure what marketplaces think of it. But yeah, generally speaking, I do agree with Sebastien, that there is no particular conflict in merging that as a proposed CIP, as long as maybe we have a clear path to active, that is perhaps one marketplace or at least one actor, which is interested in adopting it, and something that can be then reflected upon. **M. Àngels Jover**: And are we going to reach out the marketplace in order to review this, or how do you want to proceed? **Matthias Benkort**: So, we could put it as a last check for next time maybe, and comment in the meantime to make sure that the author adds a clear path to active section mentioning... Yeah, so there is probably one marketplace that is going on with that CIP. And also just to have a... Two weeks period of last check and potentially hear from people that if we have it brought to the light. ##### Discord discussion on the PR **kieransimkin** - I can't see any reason to reject it My mic's not working. I will comment I like the general idea but i think the CIP needs a bit of editorial tidying @KtorZ We'd definitely look at implementing it at Artifct **KtorZ**: 👌 thanks for pointing out **rphair [COSD]** — 24/05/2022 That also sounds best to ask the author to ask for feedback from their own community... even if they support competing proposals usually they have a good dialogue 🙂 (NFTs) **kieransimkin— 24/05/2022**: I'm always happy to engage on these things if they're brought to my attention 😉 **havealoha — 24/05/2022**: None of the markets seemed interested in CIP-0044, I'm not inclined to further refine a proposal that wouldn't be adopted. Thank you all for reviewing it. **kieransimkin — 24/05/2022**: We'd look at it, but it'd be very low down the priorities list, since we already have a process for verifying projects that works fine(ish) **havealoha — 24/05/2022**: Feel free to take it how it is and modify as necessary. My inspiration was based on how difficult it was to get a project verified on cnft.io. however jpg.store was relatively painless. #### PR163 [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163) **M. Àngels Jover**: Okay. So just let's move this to, let's and ping the author. So if we move to the next PR. This is PR163, and is dynamic saturation based on pledge. And the internet is not going super fast today. **Sebastien Guillemot**: Yeah, I think on this one, was this one of the local PRs where the IOG researchers said they would comment... I mean were kind of looking for that? **M. Àngels Jover**: It's this one over here. **Sebastien Guillemot**: Right. Last time we talked about it, we got some response from IOG on the topic. They said they would maybe look into it in more detail, but I'm not sure if anything has come out of any of these discussions And it's the main block or anything related to Stake Pool parameters switching. **Matthias Benkort**: Yeah. So the latest update I had on the topic, and it's something I just commented on CIP 50, which is that the research team is actually working on a new simulation engine to run these sort of models into it, and see how they behaves with different actors, different behaviors. Which they just published a abstract introduction. I'm sharing the link on the chat. The engine is not yet available publicly. I understood that this is something they have planned to do, although there is no timeframe yet. And the idea would then be to have this engine to use to search this space for possible solutions and for... Well, exploring all those ideas that there is, and compare them to the current system to see whether or not those various ideas improves part of the system in the right direction. **M. Àngels Jover**: So, shall we wait for this one until we have more information? **Sebastien Guillemot**: Yeah, because we've discussed this proposal in the past. So we can re-have the discussion if people really want to. But at the same time, I think we're going to be blocked on the same point, which is we'll have discussion and say... If someone influence this, it's going to have to be IOG, and then blocked on the same point. **M. Àngels Jover**: So the next steps with this one is maybe here we will... If there is some kind of activity on it, and be reactive, or do you want to actively reach out to IOG on this one, accept the comments? **Matthias Benkort**: We have reached out to IOG many times already, and they are aware of the proposals. It's just the research team currently has no bandwidth to talk to them in more details and to formulate an answer. So what I would actually suggest for this proposal, CIP 50 and other in the like, to be merged as-is as soon as they have reached a good enough level of discussions and iterations, which is the case, I think for CIP 37, we can just proceed merging them as proposed CIPs with the assumptions that... Yeah, they need to be assessed by the engineering and the research team from IOG in order to move forward to active or reject it. But there is not much we can do. I think beyond that as part of the CIP process. #### PR185 [CIP-0039? | Smart Contract Software Licenses](https://github.com/cardano-foundation/CIPs/pull/185) **M. Àngels Jover**: Okay. I am taking notes. Okay. So next one that we have in triage, and let me open it... Is CIP 185, a smart contract software licenses. I don't see there has been activity. **Sebastien Guillemot**: Yeah. So this one has been implemented in SundaySwap if I remember correctly. So those who were going to be implementing it, I'm not sure if anybody else ended up implementing it. I remember when we talked about it in the past, there was some discussion about whether this is actually legally meaningful, a question which I am not qualified to answer. That being said, the proposal itself had no issues, it's implemented in SundaySwap, which is a project with real users. So, I don't see a reason not to approve this and merge it **Matthias Benkort**: Well, Michael made a quite meaningful comment that is, there is a lack of rationale section for each other proposal that sort of justify the choices made in the proposal. So that's something which I think should be added before we merge it. And yeah, we'll have to tweak it with the number, because there has been a few proposals merged in between. **Sebastien Guillemot**: Yeah. But I think Michael's comment basically Cardano's done the same discussion. I think we had were... Be based off the fact that... You can submit whatever. Is this actually legally meaningful to do this as a transaction level, which I'm not convinced to be the case. I'm not really a legal expert on this. **Matthias Benkort**: I imagine the rationale at the moment is that it's kind of first come, first serve. So the first one to publish the license takes effectively, because there is no signature whatsoever in the current design scheme. So that's why the rationale section could be interesting. **Matthias Benkort**: Something that we think would also be valuable on that proposal would be an actual binary specification of the formats by the CDDL spec. We just mentioned that for CIP 25, but as soon as you have an on-chain format like that with different structure type. I think it's good to just have this... A little piece of CDDL that explains without any ambiguity what the format is. And since it's also using a label, we probably want to register that label in the CIP 10... Just for the sake of centralizing all the labels in one place. So that would be the few edits I would request before merging anything. **Sebastien Guillemot**: Yeah, the CDDL comment is a good one. Historically we haven't made the CDDL specification requirement. We were getting CIPs that add a new transaction, maybe get a format approved. But maybe it **Matthias Benkort**: Should be, **Sebastien Guillemot**: We should had a lot of cases. Yeah. It just leaves things way too unspecified. It might be it's **Matthias Benkort**: We want to make them a lot easier to process. Yeah. As a separate file, we started doing it at least for JSON scheme more and more, but it also makes sense for CDDL stuff. **Sebastien Guillemot**: Yeah. **Matthias Benkort**: Especially when it's quite succinct like that, it's not much to write. 10 lines of CDDLs to... Write down the format. **M. Àngels Jover**: So you want to move to the next one? **Matthias Benkort**: Yeah. And I will comment on the PR request with those items, discuss if I can agree that is... And then reassess next meeting. **M. Àngels Jover**: Shall we add it to next meeting agenda as part of the triage or review? **Matthias Benkort**: Yeah, for review or last check depending on the state. **M. Àngels Jover**: Okay. **Matthias Benkort**: Because I mean the proposal itself, I don't think there is any big issue with it. It's more those little sections that we need to be completed. But yeah, I think review next time would be... #### PR190 [PR190 CIP-0046? | Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190) **M. Àngels Jover**: Okay. So next it item on the agenda is PR190 CIP-0046? | Prepay Min Fixed Fee. **Sebastien Guillemot**: To be honest, I don't remember discussing on this one, because it's been quite a long time. Maybe we could look of the meeting notes to see what we discussed on this? **M. Àngels Jover**: The meeting-- **Sebastien Guillemot**: [inaudible 00:27:02]. **M. Àngels Jover**: Do you want me to go to any place specifically? **Sebastien Guillemot**: Yeah, I remember reading the proposal thinking that this is not a technically sound proposal. I remember the author disagreed with me on this, but I don't remember what the conclusion of that discussion was. **M. Àngels Jover**: So maybe we-- **Sebastien Guillemot**: At the end of the day, this API also depends on the same blocker that the other... CIPs that need IOG's reports have. Because this also changes the way that delegation rewards are paid out to try and help with the same issues that the other CIPs mentioned. So this all ends up being kind of bundled with the same thing? **M. Àngels Jover**: So shall we leave it in standby until IOG has more capacity to take on those? **Sebastien Guillemot**: Yeah. **Matthias Benkort**: I would proceed the same way as CIP 37, which is, have them merge as proposed and add a first item on the path to active would be to get a clear assessment from IOG/ the research team at IOG, possibly using this new simulation engine. But yeah, there is not much we can do beyond that. **M. Àngels Jover**: So yeah, I- **Sebastien Guillemot**: I remember I was not even convinced that this proposal was technically sound, because it makes it the optimal strategy for managing Stake Pool is just to have a bunch of Stake Pools all creating a very small number of blocks, and you'll get more rewards doing this than creating one Stake Pool that creates many blocks, versus the opposite incentive that we want to have. So I was not convinced by whether or not this is actually even something that fits the requirements that we, as a protocol have. **M. Àngels Jover**: So, I see the two opposite positions here between you Sebastien, that you might think that it's not sound enough, and you Matthias that wouldn't mind to merge it as proposed? **Matthias Benkort**: Well, the thing is it's the same for all those proposals. It's hard to say or assess how serious they are before doing any extensive kind of stimulation of the holding theory around the proposal. So from a technical standpoint looking at it, I would say it sounds fair to me. But at the same time, I haven't run any read of the whole position or game really behind that. So I haven't pushed much the... Consequences of that proposal on different system. It is very hard to assess. **M. Àngels Jover**: I have a question related on the process, as you suggested to merge it as proposed. But before going to active, I just wanted to make sure that I understood. Before to making active, that needs to be on a step before, which is an assessment from IOG, right? **Matthias Benkort**: Yeah, an assessment from the research team, possibly using this new framework we have been developing for running this kind of simulation. **M. Àngels Jover**: Okay. Okay. So this is something that we would add as a comment or as a step before changing the path to active? **Matthias Benkort**: Yes, I think both what you said. **M. Àngels Jover**: Okay. Now I wanted to know how you do that. I guess that is like... As you are in control to changing the proposals from proposed to active. So this would be like a kind of requirement before moving it to active. And this would be in a standby until we have this simulation. **Matthias Benkort**: Yeah, indeed active, to active or rejected depending on the outcome of the results. **M. Àngels Jover**: Okay. [inaudible 00:32:04]. **Matthias Benkort**: If the simulation clearly shows that the proposal isn't sound, that it would make the situation worse, then we just don't want to make... Move it as active, but just as rejected. ### Last Check ### Review #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **M. Àngels Jover**: Okay. So, that were the items we had in triage. And now in review, we have PR242, which is CIP 50 regarding Shelleys Voltaire Decentralization Update. I think that we are going to do a weekly summary on this, if I am correct? **Matthias Benkort**: Yes. So I actually spent the whole day looking at the proposal and going through the thread of comments. I try to provide a summary at the bottom. There has been many, many things been said, but it's mostly also a debate around whether or not the proposal improves the situations in terms of, does it benefit decentralization, and does it benefit actually every users of the ecosystem and not just the big players? **Matthias Benkort**: So the discussion hasn't really settled on that. And again, this is the kind of proposal where we need more evidence or stronger arguments in favor or disfavor of the proposal, and something, hopefully this new simulator from the research team could help with. The research team is also aware of that proposal. I've had a discussion with Aggelos also on this one. He also mentioned that it was quite close to how incentives works on Tezos currently, upon which Cardano has improved. **Matthias Benkort**: They had analyzed in the past, and that they had rejected or iterated upon in the current design that is used in Cardano. He pointed out a blog post he wrote two years ago on the topic, which goes over the different designs that you can use for incentive and rewards, and why this proposed design has issues and works actually worse than the current mechanism. Which is also one point being made during... By other people in this whole thread of comments, which is that it's also not clearly established that the current mechanism is worse than the proposal here. And that possibly with a different set of parameters, we could also alleviate some of the issues that are being brought out or motivating this proposal. So that's a bit from the summary of the discussions on that. **Matthias Benkort**: I also think that there are many topics in discuss itself within this... In that proposal, and that perhaps it could be worse to split it in multiple smaller proposals. There is one which is the change of the reworked formula, which in itself is I think the main proposal. But then there are also other topics like the change or reduction of the value of K. There is a... This k-effective measure that is describing the effectiveness of the proposal. It has an interpretation that has also a definition that is being debated. So just for the sake of making the debate a bit more fluid or debate maybe in different rooms, if you want, I would be in favor of splitting this proposal into smaller ones. **Matthias Benkort**: Yeah. So that's a bit for the summary, which is also then posted on the CIP at the moment. And I will try to keep up with the discussions coming for... Next weeks. **M. Àngels Jover**: And for splitting the proposal, this is something that Michael should be doing? **Matthias Benkort**: Ideally, yes. And that's also very much up to discussions, because maybe he doesn't have a time or willingness to do it. It could also be someone else, right? Everything is in the end open here. So if someone sees something that has value and it should be made today, proposal by itself. I made a few suggestions on the... On my comments, but there's maybe some odd few other things that are worth keeping out of the proposal, even though it is agreed with the rest of the proposal. **M. Àngels Jover**: So you would suggest Matthias that we wait for some comments on your summary and suggestions, and see how the people react to this? **Matthias Benkort**: This, yes. And regardless of my comments actually, there are still ongoing discussions that have not yet settled on the proposal. So there is no point, in a way, moving it forward in any form at this stage, because it's still actively discussed. So I think it's good if we have regular updates on that one also, just to keep up with the state of the discussion. And eventually, once the discussion has settled and maybe people have agreed on the final draft, then we can proceed the same as CIP 37 and CIP 46, which is having it as a proposed CIP, and move the task then in IOG, IOP help and just have them do something. **M. Àngels Jover**: To run the simulation, right, or to review it? **Matthias Benkort**: Yeah, or provide an answer on the feasibility, viability of the proposal. **M. Àngels Jover**: Okay. So shall we leave... Save some spot... Some space in next meeting for review this or shall we do biweekly check-ins on this one or do you prefer to do monthly check-ins? **Matthias Benkort**: For this particular CIP? **M. Àngels Jover**: Mh-hmm. Yes. **Matthias Benkort**: I think having it done on the next biweekly at least, and then we re-asses on every biweekly, depending on the activity? **M. Àngels Jover**: Okay. Fair enough, because there's a lot of activity on this one. And maybe if we wait for a month, it's going to be too much to keep up. So let's go to the last item we had on the agenda, which is CIP 242, Cardano best practice guidelines. If I recall correctly-- ##### Discord discussion on the PR **KtorZ — 24/05/2022**: [Pool Splitting Behaviour and Equilibrium Properties in Cardano’s Re])https://blogs.ed.ac.uk/blockchain/2022/04/19/pool-splitting-behaviour-and-equilibrium-properties-in-cardano-rewards-scheme= **kieransimkin — 24/05/2022**: is this related to or superceded by CIP-0050? (not my expertise here) **KtorZ — 24/05/2022**: related to **kieransimkin — 24/05/2022**: you have to know you're agreeing to a license for it to be valid, if it's embedded into a smart contract that you're signing when you interact with it, that's not legally enforceable afaik but the metadata couold still be provided for information purpsoes **ccgarant — 24/05/2022**: Here for help with CIP-50 @KtorZ thanks for review. Took notes. Will relay to Mike L. Working on ranking equation for stake pools. Should have new pull by end of week. #### PR252 [CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252) **Sebastien Guillemot**: [inaudible 00:39:38] we agreed to approve this one, right? **M. Àngels Jover**: My sense is that... You had this meeting here in Barcelona last week, and you were going to discuss this. I don't know if I am... Must correct my... **Sebastien Guillemot**: Yes, you're right. **Matthias Benkort**: Yeah, which happened. It was presented during the workshop. It's been a bit discussed and... Yeah. So it actually created, or gave birth to another CIP that we are working on with a few other people, regarding the specification of an on-chain contract. But as for the audit guidelines, there is not much more to say. I think we were pretty much okay with that. **M. Àngels Jover**: So, we will be able to merge it? **Sebastien Guillemot**: [inaudible 00:40:37] as well, and if during the in-person meeting, nobody raised any issues, then given that there was a... If that was a room of experts as well, then I don't see a reason not to approve this CIP. **M. Àngels Jover**: Okay. So this is all what we had in the agenda. **Sebastien Guillemot**: So the CIP comes with this TX spec. So this is what we're extracting as a separate CIP, right? We want to remove it from the CIP? **M. Àngels Jover**: From this one ore from... **Sebastien Guillemot**: Yeah, so the CIP as part of it also has... I think maybe there's a merge issue actually when I look at it. Maybe they pushed stuff by accident, because there's the same file repeated twice. And then they added this-- **Matthias Benkort**: Yes. **Sebastien Guillemot**: TX Pack. **Matthias Benkort**: There's the CIP XXX which shouldn't be here, I think. And the TX spec one, it was originally in a Google Doc. And I actually asked Simon if we could put it on the report next to it. And this is precisely the TX spec stuff, what gave birth to another CIP currently under our discussion. So I think eventually, we will probably amend this CIP to just refer to the other one when it comes to the TX specification. And while I have no issue actually with the current CIP in terms of the guidelines, I don't find the TX spec very clear at the moment. So it's a bit of a side thing, but maybe it's just worth re-wording this. But the main state is okay, definitely. **Sebastien Guillemot**: Yeah, but it feels kind of strange, because these are two related, I guess, but separate things. And then we also have the same document. Okay. So probably we just need to go and pick up this PR and then [inaudible 00:42:52]. **Matthias Benkort**: Yeah. And I would suggest maybe to move the discussion of the TX spec to the other CIP that we're working on. And simply have a link from that one to this ongoing discussion. It's not essential for the guidelines anyway. **M. Àngels Jover**: Are you going to do this offline? **Robert Phair**: Yeah, right. **Matthias Benkort**: Yeah, yeah, we'll comment on the PR. Maria also, are you going to link to Robert? [inaudible 00:43:27] this trouble like I was, to join back this Discord or I was doing something wrong? **M. Àngels Jover**: Looks like it sounds better now, right? Or no? **Robert Phair**: Someone just did something. Someone just did something a few seconds ago, then it was... I've been clicking on my unmute button and I've been told... I've been suppressed ever since I reconnected. So I guess, whatever you did, fixed it. I've been trying like hell just to unsuppress myself and I couldn't. So thank you. Yeah, that's it. **Robert Phair**: All the comments that I wanted to make so far are in the chat. So I don't see Maria that... Even in the chat rooms. So that's where I've commented, is just in the chat. I don't know if I can be inserted into the minutes somehow, but there were a couple of things, but... What would the process be for in... **Robert Phair**: Just a comment, if there were relevant things in the chat to the discussion, are they ever inserted into the minutes or does it have to be spoken? **M. Àngels Jover**: I had a little bit of trouble understanding. **Matthias Benkort**: [inaudible 00:44:48] to the chat. So Robert was asking, what do we do with the chat basically, regarding the minutes meeting? I think we should just include them in some form or another, because there has been relevant stuff being said in the chat, and we don't bring everyone on vocal anyway. So, that's important. **Robert Phair**: Okay. Well, you can edit what I've said, because a lot of it is, "Help, I'm being suppressed." So you can turn that down a little bit. I did make some comments about two of the other proposals, but that's enough. We can keep moving on. Are you still hearing any noise that you were noticing through the web app? **M. Àngels Jover**: It's still noisy and it's difficult to understand you, because it gets... I mean the words... Well, nevermind. It is difficult. **Robert Phair**: [inaudible 00:45:42]? Okay. **M. Àngels Jover**: What I will do is check and see how we can include this, because I think that what you mentioned is really interesting. So I will check how to include the comments on the meeting notes. ##### Discord discussion on the PR **kieransimkin — 24/05/2022**: @KtorZ I've had a good read of CIP52 - nothing to add, looks really good ### Issues ### Discussions #### PR256 [PR256 CIP-0014, CIP-0015, CIP-0016, CIP-0025, CIP-0028, CIP-0029, CIP-1852, CIP-1853, CIP-1855 status updates.](https://github.com/cardano-foundation/CIPs/pull/256) **Matthias Benkort**: So I would like maybe to go quickly over a small PR I did last week, 256, which just turns a few CIPs as active. I was going through the list other day and thought to do... There are a few ones that we could definitely turn as active, because there are obvious and observable proof of activeness. So, there are old CIPs that have been there for a while. It doesn't mean that we cannot have a change of the CIP. But yeah, things like CIP 1852, which is the derivation scheme used in every single wallet currently. Or CIP 14, CIP 15. **Matthias Benkort**: There is a complete list with rationale as for why I think we should turn them into active. There was a few others that could be up to debate, which I didn't include. But I think generally speaking, we originally thought that the author would come and update their CIP as active as soon as they have reached a... Well, level of activity, or it turns out that I think we'll probably have to take upon that task, because... Yeah, outdoor is typically once they have proposal is active, they don't just come back at it. So it's just a variety of... The things. **Matthias Benkort**: So, there is no section... okay, so it actually used approved. There is now a conflict. **Sebastien Guillemot**: Yeah, it makes sense. It makes sense. All these are very commonly used. So it's no [inaudible 00:48:43]. **Matthias Benkort**: Yeah, I think I will make another PR soon to just turn a few others as proposed, because that's something also we haven't been quite careful with in the past. Some CIPs have... I think they have been merged as still... Are still draft. Like CIP 30, it's been drafted for a while and it was sort of on purpose. But quite a few of them are actually not draft anymore; they have been just proposed and they are just not yet active. **Matthias Benkort**: So yeah, but that will be for next meeting. Is there anything else maybe for today we could look at? Did we have any suggestion in the chat? #### PR258 [PR258 - Bootstrap first draft of the Plutus contract blueprint.](https://github.com/cardano-foundation/CIPs/pull/258) **Sebastien Guillemot**: And then, so the blueprints for Plutus one is still too early, right? **Matthias Benkort**: We could start have a look at it, if only for people to also jump in the conversation. But yes, it's very, very early draft at the moment. Actually, I mean the specification has not been written. We have just written examples at the moment of what we think it would look like in the end. **Matthias Benkort**: But yeah, we could have a quick look at that one, which people wants to jump on the conversation, at least to explain the motivation and the... What's behind. So happy to give a short introduction. **M. Àngels Jover**: Which one Matthias? **Matthias Benkort**: So yeah, I'm going to put it in the chat as well. So PR280... Sorry, 58. You can think of it as an open API/Swagger format for on-chain contract. So a way to specify a contract interface in a machine-readable format. And by contract interface, we mean... Data redeemers, and if applicable, for instance, the different transitions that can be operated on a contract, if it's evolving around the stake machine. **Matthias Benkort**: And the goal is really to enable a whole sort of tools to be built upon that, including documentation, automated card generation, or simply wallet UI that can then show you the different progress of your contract. And can also better show you what's going on when you sign or view a transaction that involve a contract, because now they have actual content or ways to inspect data redeemers that are being bundled as part of a transaction, and they can then offer you better UI for interpreting this data. **Matthias Benkort**: So this is a CIP that aim at just specifying the language you can use to write this contract specification. It's quite simple. It's just a YAML/JSON schema-based language, because it's quite good for that. There are a lot of tooling around it that exists already, and it's quite common for web and DApp developer... To use this kind of technology or this kind of... Yeah, people language. So it's still early draft, but I invite people that feel maybe concerned by that to comment and see. **M. Àngels Jover**: Okay. **Sebastien Guillemot**: Yeah. So one of my concerns with this is how we plan to basically generate these from a hash code itself. It is a very good way to basically have people [inaudible 00:52:51] they're off-chain code generation as it generates its file permit, or is that nothing that is- **Matthias Benkort**: That's the other way around. I think you actually want to write the spec first, and then generate hash code for responding to the spec. And this way, you can [inaudible 00:53:12]- **Sebastien Guillemot**: That would be ideal, yes. **Matthias Benkort**: To do code generation of either the on-chain part, or also the off-chain, which is in the whole diagram. And that tooling is also yet to be built obviously. But it's a start for good foundation for them, all of that. You could also use it for verification, for instance. Right, so have for validation, once you have created and generated a transaction as part of your whole... That pipeline, you could use that tool as a schema validation on the data and you will be able actually to make sure that your contract is actually doing whatever is specified in this file. And yes, exactly yes, someone said in the chat so automated unit test, yeah. Validation is based on the spec. So it's very close to the article representation of the data obviously, because... **Sebastien Guillemot**: Do you know what they did for the Plutus simulator? I forget the name of the project; it's been so long. But I remember they had a website where you could generate your code, you could give them your code and they would generate these bit machines and set some web-based UI. Do you know what they used for that? Yeah, Plutus Playground. How did they generate the UI from this... Our contract? Did they come up with a standard for this? **Matthias Benkort**: No, that's a good question. I think it's solidly based on the hash code types. And behind the scene, I know it's built with pure script. So I would expect that they have some form of... Pure hash code to pure script generator to do a bunch of the heavy-lifting. **Sebastien Guillemot**: Yes, they may have something that we can reuse either code wise or idea wise. **Matthias Benkort**: Yeah. And Michael has already commented on the proposals. He's aware that this is going on. He hasn't suggested anything in this direction though. But maybe you can ping him a bit more on this particular subject. **Sebastien Guillemot**: Yeah, because I imagine the people who work on Plutus Playground probably thought about this, and probably this is also something they thought about for Marlowe. Marlowe is maybe a bit trickier, because they have the separate TSL, which also generates code that's not this kind of JSON schema, but maybe it... Some similarity, I'm not sure- **Matthias Benkort**: Yeah, what Simon tried to specify in this TX flow file from CIP 52. **Sebastien Guillemot**: Right, yes. **Matthias Benkort**: Where I think the [inaudible 00:55:56] stems from Marlowe's and Marlowe's behavior. But it's really not obvious to me how exactly those things relate to the low level Plutus stuff in a way. **Matthias Benkort**: Oh, it seemed very... Too high level to be actually useful for code generation, automated test code verification. **Matthias Benkort**: So yeah, so far we are mostly focusing on the data redeemers kind of specification, but there is also maybe other information that are useful to add around that. Someone suggested, for instance, recently that we add also Plutus versions to the schema, because now we have... Well, soon we'll have two different Plutus versions. So it's nice to say your contract is this or that version. It's perhaps also a good way to actually have the compiled code of the contract and have it in some place so that you can refer to it later, which sometimes can be tricky because some contracts are parameterized at compilation time. So therefore, their code slightly changes depending on which parameter you choose. And it'll have a static address therefore. But there are maybe other components of... On-chain contracts that are interesting for that developer, which is exactly why the feedback is interesting here. **Sebastien Guillemot**: Right. So this CIP tackles the data redeemers. But we already have kind of a standard for representing these in JSON, that's implemented by both... Cardano CLI and the rest, SDK CML. So did we want to standardize this representation as a separate CIP and then build on top of that for the stake machine, or did you want to have the 12 B one, the CIPs? **Matthias Benkort**: It's kind of different though, because here it's more like meta language, right? Or describing what the functions are and a JSON representation is not as capable as the on-chain representation. So there are stuff that you cannot represent in JSON that you can do on-chain. So they don't necessarily have to converge, I think, the presentations. Maybe the passive value if they do. But I see that as two separate things, actually. They don't really describe the same thing. **Matthias Benkort**: It's a bit of like a type versus value kind of... **Sebastien Guillemot**: Yeah, okay. **Matthias Benkort**: Thing, right? **Sebastien Guillemot**: Yeah. **Matthias Benkort**: Here, we are describing the type of [inaudible 00:58:45], whereas the JSON of the [inaudible 00:58:45] is really just materialization of that value. **Sebastien Guillemot**: So in an ideal world, you could also generate this JSON through the schema that you're defining here? **Matthias Benkort**: Yes. I see someone is typing in chat. **Sebastien Guillemot**: Okay. Yeah, I have no other questions about this CIP. I see it's not done yet, but so far it makes sense. **Matthias Benkort**: Thanks for sharing. **Sebastien Guillemot**: How much time do we have left? Three minutes, so I guess we probably don't have... So there's a few other issues open or PRs open, but I think maybe with three minutes, we don't have really the time to get into them. **Matthias Benkort**: No. ##### Discord discussion on the PR **kieransimkin — 24/05/2022**: Super keen on this transaction spec @KtorZ - i also see it as a way for the plutus gurus to help simple C developer mortals like myself to understand how to actually interact with a smart contract 😉 automated unit tests could come from it too right? **PGWAD — 24/05/2022**: I am working on Coq proof assistant and this (Plutus contract blueprint) one will be very useful for that especially extraction part. I am writing an extended abstract and will update if i need anything more ### Close **M. Àngels Jover**: Shall we do a quick wrap up on the session? **Matthias Benkort**: Yeah. Who wants to... Sebastien, you're up for it? **Sebastien Guillemot**: Just thank you everybody for coming. Hopefully you didn't think the technical issues were that bad. And this is our first attempt to do this over Discord. I think we had higher attendance than what we did when we got over Crowdcast. I think this is a good migration. We were originally unsure about doing Discord versus Twitter Space. We ended up picking Discord because you can screen-share on Discord, which is useful. And hopefully the screen-share functionality was useful for everybody. **Sebastien Guillemot**: But one of the problems we have with CIP is we need to reach out to more people. So we need to go where people are instead of in an isolated platform. And so coming on Discord was part of that. And maybe in the future, we can try out broadcasting this to Twitter Space at the same, or some other kind of scheme to reach out to more people. But if you have any feedback for how we can improve these meetings in the future to make them more engaging, let us know. **Sebastien Guillemot**: I did notice that nobody else spoke during this session, other than in the chat. Let us know if that was good enough for you. I think Discord has a way for people to raise their hands or request to speak. So we could try and come up with a system like that. In my experience, it slows down the meetings quite a lot. But obviously, depending on the CIP, if we have the CIP author come up, it can be important. So obviously, one of those balance things we have to try to find the right balance. **Sebastien Guillemot**: So if you have any feedback about our first experience, just let us know what you think, and hopefully you'll be around for other CIP meetings in the future. **M. Àngels Jover**: Well, next CIP meeting is going to be in two weeks. It's going to be at 8:30 AM UTC, and it's going to be on Tuesday. Let me check... The actual number. Tuesday, June the 7th, 8:30 AM UTC. **M. Àngels Jover**: Thank you very much all for attending today. And well, have a nice evening or day. Bye-bye. **Matthias Benkort**: [foreign language 01:02:20], bye. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-06-07.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [June 07 2022 Transcript](#june-07-2022-transcript) * [Triage](#triage) + [CIP-0052? | Cardano audit best practice guidelines](#pr252) + [CIP-0054? | Cardano Smart NFTs](#pr263) * [Last Check](#last-check) + [CIP-0044? | Additional factors for NFT market verification](#pr226) + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163) + [CIP-0046? | Prepay Min Fixed Fee](#pr190) * [Review](#review) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) * [Discussions](#discussions) + [PR267 CIP-0025: Added version 2 and cddl](#pr267) + [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](#pr271) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 07/06/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significances to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## June 07 2022 Transcript **Attending Editors**: Matthias Benkort, ~Sebastien Guillemot~, ~Frederic Johnson~, ~Robert Phair~. **Guests**: **M. Àngels** -: Welcome, everyone. Welcome everyone to the CIP Editor's meeting number 46. My name is Maria Angels Jover, and I work as a project manager at the Cardano Foundation. And I am here to facilitate this meeting. Today is the second time that we are using Discord as a new platform, and it's the first time that we are doing this in the European zone time. We had some technical difficulties in our first meeting that we expect to be solved today. **M. Àngels** -: Please, any feedback that you have on this new communication channel will be very much appreciated. To access the chat of the voice channel, you can hover here in open chat, and you will see that it will appear at the tab here with a chat where you can comment, ask questions, and participate in the conversation. You will see that I have added here, a link. This is link is a direct link to the meeting agenda, so you can access from your end and navigate to the links. The editors are able to bring you on stage, so you can ask to be on stage if you think that you have something that is worth to discuss live. **M. Àngels** -: And it's my pleasure today to introduce you to our editor for this meeting, that is Matthias Benkort. Matthias, are you able to speak? You should be able to unmute yourself. I see that you have unmuted yourself, but I am not hearing you. Seems like we are running into some issues, let's wait for Matthias. We are not hearing you Matthias, if you are speaking. Maybe it's the microphone that you have enabled with Discord, that is not the correct one? Apologies on these technical issues that we are facing. I mean, this happens with live sessions, so please bear with us, and this will be solved in a few minutes. Thank you very much. **Matthias** -: Hello? Okay. [inaudible 00:06:26]. **M. Àngels** -: Yes, welcome, Matthias. **Matthias** -: [inaudible 00:06:28]. Yeah. I see Les asking, "Why use Discord?" And the truth is we have had mic issues with every single platform we've used so far, so I'm not sure any platform would actively serve that. And the reason we used Discord is because it allows us to have way more speakers on screen when we have to. It's more friendly. We have also a chat, and that's where the community are centralized around a few Discord channels. So it's quite handy to have things in one place. Okay. Having said that, shall we start? **M. Àngels** -: Sure, yeah. On screen, you can see the agenda. Matthias, do you want to discuss anything that is not included in the agenda today? **Matthias** -: Let me see. [inaudible 00:08:00]. Yeah, maybe, we'll see at the end, but there has been a few Pull Requests recently, we'll just go through them quickly and see that. ### Triage #### PR252 [PR252 CIP-0052? | Cardano audit best practice guidelines](https://github.com/cardano-foundation/CIPs/pull/252) **M. Àngels** -: Great, so we can start with triage right? So, in triage, we have CIP-0052? | Cardano audit best practice guidelines. Here we had some comments from the last meeting. It was suggested to move the discussion on the transaction spect to another CIP. This was supposed- **Matthias** -: Yeah. Which we started, but at the same time, as long as this [inaudible 00:08:54] CIP is not fully done, I think it's still fine to keep it in CIP 52 for now, and we'll just remove it later. Sorry. There were a few comments that have been retraced by Simon since then, and I saw he did also some recent edits. He added an auditor list at the end. It's fine now. Everything is re-read, was reviewed last time, so. Okay. **M. Àngels** -: Are we going to Merge this one then Matthias? **Matthias** -: Yeah, I cannot approve it right now because I don't have access to my GitHub account from Windows, but in the future. **M. Àngels** -: Okay. I'm going to take a note that this is going to be Merged online. **Matthias** -: Yeah. **M. Àngels** -: Let's go to the second item on our list. #### PR263 [PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263) **Matthias** -: So, PR 263 CIP-0054? | Cardano Smart NFTs **M. Àngels** -: Can you do a brief summary regarding this PR, Matthias? **Matthias** -: Actually, I think we have Kieran with us, right? Who could actually give us some intellection? We could bring it on the- **M. Àngels** -: Sure. **Matthias** -: Chat. **M. Àngels** -: Hi, Kieran. Yes, perfect. **Kieran** -: So yeah, this CIP, it's about a JavaScript API to be provided to JavaScript NFTs. So it's a fairly niche thing, I suppose, but it does need to be standardized because there are people developing or needing implementations of something like this at the moment. There needs to be a global standard that everyone relies on, so that's what we're trying to build here. **Kieran** -: Yeah, basically it's about allowing NFTs to read data from the blockchain itself. [inaudible 00:11:11] token in your wallet in an NFT [inaudible 00:11:35]. **Matthias** -: Okay so this is a sort of standard for a format on chain that allows wallets to query the informations about NFTs? **Kieran** -: Its to allow the NFT itself to query the blockchain, 'cause we have these JavaScript NFTs now, basically HTML pages with JavaScript in them. Currently they are some blocks so they call them [inaudible 00:12:02] which is causing people to commit a lot of data to the chain that doesn't need to be committed to the chain. So what this is about is allowing NFTs to create data directly from the chain without having to commit within that NFT itself so it's to reduce data duplication on chain data of the effects of this. It's also about allowing NFTs JavaScript to only [inaudible 00:12:30] the NFTs. It's allowing JavaScript NFTs to read arbitrary data from the chain and react how they see fit to that. It's things like, let's say you've got a chimp NFT and you buy it a hat, you can buy the hat as a single NFT and then the chimp NFT render the hat wallet, knowing you've got that hat NFT wallet inside the chip, does that make sense? **Matthias** -: Kind of. So the concept of JavaScript NFT doesn't make sense to me, what makes sense though is a JavaScript written DApps that interact with NFTs possibly, I think. **Kieran** -: JavaScript NFTs, this is something that is really happenning but an NFT is just a file attached to a token, right? And then that file could be an HTML file. And this is the thing that you could do, I don't know if you've seem mesmerized [inaudible 00:13:33] JavaScript NFT. And then there's a lot of people doing this now, this is a API for JavaScript. **Matthias** -: Okay, an API in the sense of an extension to CIP 30, current API, right? So that's something we implemented by wallets or simply all the plug-ins behind the scene, so. **Kieran** -: It would be implemented by the site rendering the NFT so it could be [inaudible 00:14:04], it could be JPEG store or it could be Artifact it be in the website that renders the- **Matthias** -: Yeah, okay, got it. Is there any working example of that already? Like is it something- **Kieran** -: I am working on it right now. **Matthias** -: Okay. That would be good to add on the path to active. **Kieran** -: Yeah. **Matthias** -: Once you have that or maybe already an idea of it. Okay. So the main thing I think we would have to view then is the API below. One thing I can already tell maybe would be to add versioning changes to the API, and that's something we tend to have forgotten on the previous API we have wrote, and that all came afterwards, like, "Oh, fuck. Now we need to have changes, but now you don't know which version you need to implement." So chances that there will also be changes to add to this [inaudible 00:15:01]. I would suggest really having an API on this one, or just make it theory that this will be the final API, we call it CIP 54. And any extension or any addition would be done as a CIPs, and then it becomes a big theorem because it's at least the number of CIPs that we should pause. **Kieran** -: One thing adding versioning to this would be the way to go, because it refers to the 721 enterprise of [inaudible 00:15:19] version 1.1, 'cause we already have a version 1.0, would not be [inaudible 00:15:34]. **Matthias** -: Yeah and there is 2.0 coming. Right. **Kieran** -: 2.0 coming is [inaudible 00:15:42]. So should I call this 1.1 for that? **Matthias** -: Um, I mean this one should probably follow a separate versioning. **Kieran** -: [inaudible 00:15:50]. **Matthias** -: Yeah, its own versioning [inaudible 00:15:53] or you can just pick it to the versioning 71. I'm sorry. **Kieran** -: I'll have to think about that but I will update the version. **Matthias** -: Okay, so I haven't yet read the full CIP, only read the abstract so far, but yeah we need to dive a little more deep here. From the idea standpoint, I don't think there is any major problem. It's truly just we only can Cardano API. **Kieran** -: That's right. Yeah. **Matthias** -: Yeah. From a security standpoint, there is not much issue with that. So I would love to see also if you have a working [inaudible 00:16:38] maybe so that we can possibly already Merge it as active, as we do. **Matthias** -: I see there is also the follow up link of what has been the feedback so far from discussion of NFT. **Kieran** -: I've gotten multiple NFT creators who are really excited about being able to use this. There's a lot of feedback that's really come from there. This was actually a much simpler API to begin with. I've added quite a lot in response to feedback. I was actually trying to keep it simple because we wanted the implementation to be as light as possible, had quite a lot of feedback for some extra things people would like to add and I've started to bear the fine line of trying not to add too much stuff onto this extra version because I want it to be implemented easily. **Matthias** -: Okay. **Kieran** -: We're sort of balancing it, but there's definitely been a lot of feedback both on the forum and then spoken to me on Twitter, and working with Alexander from [inaudible 00:17:25]. So, yeah, I've got quite a few things to go. **Matthias** -: Okay. Would you mind maybe adding a rational section to the CIP, mentioning maybe some of the feedback you've been discussing and why things have [inaudible 00:18:00] the API? **Kieran** -: Yeah. **Matthias** -: Just for the report. Oh, yeah. Also the type. I've commented that last time. Standard is really reserved for core critical changes, like through to stuff or later holes secure. It would be more of a process, right? **Kieran** -: It's just changing metadata. **Matthias** -: Yeah. The type of the same process here. Or informational, but I think it's going to be more of a process, right? It describes these kind of protocols between those smartness and data provider, in that sense. **Kieran** -: Yeah. Sure. **Matthias** -: Okay. And I guess we can just move it to last check for next time, it's been already really quite extensively on the forum that I can see. We'll make a small rational section and we'll try also make maybe a summary of the comments, when commenting on it and send the next time. We can go back to check if there is already an implementation ready and it's been endorsed by some of the platforms out there. We can activate right away or just go with proposed until there are also proof of that. **Kieran** -: Okay. Great. I've got do list [inaudible 00:19:25]. **Matthias** -: Good, thank you. **Kieran** -: Thanks. **M. Àngels** -: Okay. **Matthias** -: Next. ### Last Check #### PR226 [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226) **M. Àngels** -: We can move them on to the items on last check. The first item we have is PR226 CIP-0044? | Additional factors for NFT market verification **Matthias** -: Additional factor. Do we have Eric here? **M. Àngels** -: I don't see anyone by the name of Eric. **Matthias** -: What was this one? Sorry. It was a busy week last week. Perhaps we can switch. Hadn't got to go through this piece as I wanted to. Okay. So there is somebody [inaudible 00:20:29] the header, but it's okay. Let's see that later. Simple summary, a community standout for the NFT policy ideas to facilitate market verification, utilizing a new number, name asset tag hate with one online on chain accounts bank utilize this proposal [inaudible 00:21:08] Okay. To it is a standards. Two include with metadata. So KYC metadata to, [inaudible 00:21:31]. **Matthias** -: So what's the ID specifications, creating new tech creator makes a new current see and use one more existing online platform, social update. [inaudible 00:22:05] I'm not sure to fully understand exactly how would that work in practice. So the first question that would come to my mind is how do we exactly prove that whoever posted metadata are actually the NFT owners and not someone else since it allows to be original data, that means you can come later and also change those data. **Matthias** -: I mean, what elements ties you as the NFT owner or the owner of this metadata and why can't anyone [inaudible 00:23:23]. Is there also a community discussions happen? Yes, I see. So thank you. **M. Àngels** -: Matthias, where are you seeing the comments, the activity? **Matthias** -: Sorry, she's going to share this link in this channel here. So the second version of the side written, because there are two files on the [inaudible 00:24:36]. One of them is I think the latest iteration and it has a comment stream on the top. You high with also a discussion thread, which I will need to go through and see what's up. So I see there has been quite a few feedback and is the latest version of the proposal things from that, I suppose. **Matthias** -: Okay. So I'm a bit worried on the security implication of that more, the spoofing kind of capability. People like this so I want to carefully get feedback straight on the forum before saying anything. Let's keep it for the next meeting and I'll make sure actually to go through the comments and also post this small summary on that CIP. **M. Àngels** -: Do you want to add as under review section for next meeting? **Matthias** -: Yeah. **M. Àngels** -: Okay. **Matthias** -: This one. Yeah. I think there will be another bunch of comments and we'll probably need a bit more engagement from well marketplaces and NFT of platforms, because this is really geared toward them, towards how to get NFT approval. So it would be nice to get also input from the existing marketplaces, maybe to see how they currently do it. And if that solves an actual problem in your site. **M. Àngels** -: Okay. So you want to move to the next item on the agenda, Matthias? **Matthias** -: Mm-hmm. #### PR190 [PR190 CIP-0046? | Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190) **M. Àngels** -: CIP-0046? | Prepay Min Fixed Fee **M. Àngels** -: I think that I added a few items on the agenda related to the... Oh, just let me look for it. There was like two CIP on the past meeting that you proposed to Merge it as proposed and listing the path to active. So these are the two following ones and I added them to suggest to Merge them online today, but I guess that you cannot Merge it, right, because you are on windows and you don't have rights. **Matthias** -: Yeah, exactly. And they're still lacking enough approvals anyway, from the leaders. For instance, the prepay meet fixed fees, the moment hasn't been approved at all. So, well also need to get Robert and Sebastian. Inputs on that, I think last time we pretty much treat and the spirit was to say, "Let's have them Merged as proposed and make it clear in the past active that the goal is 90, well on the side of IOG to review that and give a clear answer from a research standpoint or signature standpoint, yes or no, to CIPs." Make sense or won't be implemented, but in network [inaudible 00:28:52] that's pretty much where we stop. #### PR163 [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163) **Matthias** -: On PR163 CIP-0037? | Dynamic Saturation based on Pledge . What about this one? We got approval things with the same situations. Yes. It's been commented a lot. So basically, no updates from this. And last week we also... I mean, we need the others to do the updates to proceed and for us to approve. So we can maybe just park them on the site for now until we have a activity from the young [inaudible 00:29:34]. **M. Àngels** -: Hey, shall we add a tag waiting for the author? **Matthias** -: Oh, yeah. Actually [inaudible 00:29:50]. **M. Àngels** -: Sure. Done. And what we are missing from the author is to add the path to active. Right? **Matthias** -: Yeah. And also just make sure that they acknowledge the current situation too. **M. Àngels** -: Okay. **Matthias** -: Yeah. ### Review #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **M. Àngels** -: Perfect. So next item on our agenda is PR242 CIP-0050? | Shelleys Voltaire decentralization update weekly update that we decided to make a biweekly update on the CIP that had a lot of activity. **Matthias** -: Yeah. So it has got a bit less of activity recently. So Michael responded to some of the things that we commented on and mainly there is still this discussions on basically whether or not the... How do you say that? It's actually just reads Michael comments. That would be not by paraphrasing anything. as he's saying. What was that? Sorry. Trying to find the right comments. **Matthias** -: Yeah. So as you say, ideally, IOG researchers would participate here, not in private, but afterwards, so that we could all collaboratively develop CIP 50 and I hope draft a new 2023 errors revised paper together. So in three months we have the discussion happening. As I said last time from what I got from the researchers, they are actually not willing to discuss it, or they don't have time at the moment for it. We try to set up this focus group, but we've got some pushback. So at this point it's a bit the same situation as to others. Either we need more community leverage or there is not much we can do to make the conversation move forward. **M. Àngels** -: So, do you want to put it on hold for a few meetings and maybe after the hard fork before trying to move it again? **Matthias** -: Yeah. I mean, we'll need to poke basically IOG constantly, I guess, until we get a reaction. There was also this new simulation engine that was supposed to come out. So maybe that would be a good time to look again into the CIP once this simulation engine is out, although there is no clear timeline, so this could also very much be six months or a year from now, which I don't know. **Matthias** -: I see also there is a comment from last week that I missed from an SPO. Which is quite lengthy. So from the quick reads, it seems to be again, debating on whether or not the CIP makes things better regarding decentralization. Because there is also this question at this stage, and this is what was brought up by the researchers when they looked at CIPs, was that from a decentralization standpoint and again, theory standpoint, this was an approach that was discussed during the early days of Shelley's and that was rolled out because not good enough at maintaining decentralization. So multiples were also considered in designing the first place. Yeah. **Matthias** -: I mean, the situation we are in today was kind of already included. So there is probably better to do but whether CIP 50 is going in that direction, it's also good question and it's not clear right now. We don't have any quite clear proof that it is actually going in the right direction. So far it seems to be more of in sentiment than an actual well calculations or simulation of that new theory. Maybe that's something which would be worth trying on the site network. But importantly, we don't really have that. **Matthias** -: And the stake on the test net would be for instance, much more different because it's all free money and people don't have the same behavior, therefore. So, yeah, I don't know. We can try to bring IOG back again, see what's the answer and keep to have short update on that every week or every two weeks. **M. Àngels** -: Okay. So we are going to keep it through for next meeting agenda? **Matthias** -: I would say for now, yes. And let's see, we probably won't get any update from Input Output before the Hard Fork. Because I guess all minds are focused on that, but we might a bit later. **M. Àngels** -: Okay. So that was all that was in the agenda for today's meeting. So maybe, Matthias, you want to review those new CIP you commented at the beginning of the session? **Matthias** -: Yes. But I just have a small urgency to cope with, so I will be back in two minutes. **M. Àngels** -: Okay. ### Discussions #### PR267 [PR267 CIP-0025: Added version 2 and cddl](https://github.com/cardano-foundation/CIPs/pull/267) **Matthias** -: But I would like to look at PR 267 CIP-0025: Added version 2 and cddl, at least. So maybe we can already print to screen. **M. Àngels** -: Sure. Take your time, Matthias and I will leave it here for everybody to read it. I will share the link on the chat and also here. So let's wait a few minutes until Matthias is back. **Matthias** -: Okay. Sorry for that. **M. Àngels** -: No problem. Do you want to make a brief summary of CIP 267? **Matthias** -: CIP-0025: Added version 2 and cddl #267 **Matthias** -: No, sorry. Yeah. Pull Request 267. Yeah. So this is a iteration on CIP 25, right? Which was the NFT metadata standard we ha not exposed, but mentioned a few points that could be improved last time. And the idea was to make a version two that would address those points or this is basically it. Okay. What I see here. Yeah. I think one thing we discussed and that's also Sebastian maybe mentioning it, or. So it would be good to have the CGTL as a separate files as always, but at least now we've got a clear onchain CDDL specifications of the metadata for the CIP. **Matthias** -: I think it is mainly compatible version one in the sense that it embeds the same informations, but there is a slight difference in the way the asset names gets included. For instance, right now it used to be just playing UTF-8 text string, whereas this new one uses actually raw binary bytes through CBOR encoding. So since this is entry data any way, that makes much more sense. **Matthias** -: For the rest, I think what has changed the media type probably, the remains optional. Yeah. And it has also now version number two. Yeah. Overall it addresses the points we mentioned right back on that CIP. And therefore, I think we can move it to last check for next time. It'll be fine to have as is. And maybe it would be also a good opportunity to change the status of CIP 25 to active instead of draft. But beyond that, the rest makes sense. It's basically the same structure and it's just addressing the issues on the asset name plus explicit version name. **Matthias** -: I see there is a comment in the chat, not on that one, on the previous one. So in what channel do we discuss the IOG, which shows we don't have time. We are getting pushback. Yeah. Not on this call, actually this happens through private channels unfortunately also. So the whole point of making [inaudible 00:43:06]. Yeah, no, I mean, I think so. I think you're right. Although I don't think we keep the illusions, we are working on it. I mean, it's pretty clear that we are not working on it because we are blocked by IOG's feedback at this stage. And that's why I'm just proposing to keep just regular updates on those CIPs to have them Merge as proposed and simply make it clear in the past to active that the next steps now is to be done by IOG, to assess the CIPs and to give a clear answer on the feasibility. IOG, I also include the research side of things. **Matthias** -: And then it's just, I guess only up to the community to voice it enough that maybe it kind of forces IOGs end to actually allocate time to debts. But at the same time, what is more important between this or for instance, input endorsers, arguably the community should be deciding that's not IOG, generally. So if the community deems that this one is more interesting and more important, then that's probably how it should be framed. But there is also not much channel at this stage to kind of voice those concerns, right? So I'm not sure how to proceed, basically how to make the best out of it. **M. Àngels** -: I see on my writing on the chat, may I bring him to the- **Matthias** -: Yeah, maybe actually having on the chats that would be easier than writing things. Although writing has nice. **M. Àngels** -: Hi, Homer. You should be able to speak now. **Matthias** -: Sorry, he can't talk. Putting kids to bed, ah. **M. Àngels** -: Okay. **Matthias** -: Well, we can have that conversation also off time. So I mean, on the channel later meetings as well and that would be a good feedback also to put to IOG. Maybe the right ways, I don't know, to write letter and make it clear that this is something the committee wants and something times could be allocated to. I don't mind pining Charles directly as well, if needs be. Just poking in and saying, "Hey, look. This needs attention from the community, from IOG because the community wants it." And I mean, I guess if we make enough noise, then it might be okay. I'm not sure if you're trying to speak, Homer, but we hear some... **M. Àngels** -: It might be me, I will mute at myself. #### PR271 [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](https://github.com/cardano-foundation/CIPs/pull/271) **Matthias** -: PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses Ah. Okay, well let's see how we can do. I don't know, perhaps the Twitter or call seems like the community loves Twitter. What's the next thing that IOG should be implementing? Okay. That was it for CIP 25 update. What time is it right now? At 8:00 is left that. So there is a new CIP for [inaudible 00:47:12], but we won't go through that right now. That's quite length, although interesting. Treasury donations is a bit of the same, quite big overall. And so there is a small update I see on CIP 27 [inaudible 00:47:33] latest, where that was made to PR 271, which is what exactly as NFT projects become more extreme projects may need to handle multiple royalties addresses for team members. **Matthias** -: This PR is created to [inaudible 00:47:58] show implementation community. So multi [inaudible 00:48:10]. The feedback this class consider during short discussions surrounding royalties on chain. And there is multiple problem that arises when declare multiple priorities increases which research receive, which amounts quality [inaudible 00:48:25]. And what about using smart contract for that? Want to address, but specific holes on who can spend in minutes. That's perfect job for [inaudible] . **Matthias** -: So I guess I will just cut that add, because I see is the CIP defines a... I mean, this exemption seems to define a off chain [inaudible 00:49:12] in the royalties as for what should be the different distribution, [inaudible 00:49:22] royalties between different addresses. I think this is just accessory in the sense that this is something you can do completely with script company. So with a single address, you make it a script address. And while sending the royalties to that script address, it can then convert completely how the funds get distributed and deemed from that address later on. So that will be entirely up to whoever set the initial royalty. **Matthias** -: I mean, from a proposal standpoint, I guess proposal is fine. This is definitely something, guess it would be better handled by street addresses traces. So I can comment right now, but I will, once I get back on my lovely minutes. **Matthias** -: Yeah. I see someone is typing on the chats. I would also very much like to see incentive research team. Okay. So that's [inaudible 00:50:52]. So we'll get back to this, but okay. So on CIP 27, I will comment with what I just said. I mean, this is a substantial update on the CIP itself. So either the format will need to be made backward compatible. I would suggest another CIP and I will actually strongly suggest to use crypto address for that instead of changing anything because of the format and then see. Yeah. So give that as a feedback to the authors, unless we have the author right now with us. I don't think so. Okay. Let's maybe wrap up with the three minutes left. ### Close **Matthias** -: All right. So CIP 52 agreed to proceed with reaching as active [inaudible 00:52:07] even. CIP 54, Cardano Smart NFTs. So discussion still going, mostly sounds fine so far from the... So face review needs a more in depth review for the API to see if we catch anything. And the author to add a rational section also summarizing the different feedback behind some of the decisions that were made but good to move as last check for next time. **Matthias** -: CIP 44, additional factor for NFT market verification, felt a bit unclear in terms of, security implications and or spoofing/hijacking this this approach also when led to get that feedback to the author and see, this is something they have thought of. Awesome. **Matthias** -: Prepaid means fee and dynamic saturation based on pledge, sort of in the same bucket as CIP 50, which looks fine from an editorial standpoint. The ideas make sense at least from a reduced standpoint, but there are debates as for whether or not they improve the situations. And we need clear updates from IOG regarding this. So from an editorial standpoint, there is not much we can do with these proposals anymore except mitigating the discussions, maybe. So we'll keep poking at IOG, keep making noise and maybe see how we can move them forward giving that feedback. **Matthias** -: We also went through an update on CIP 25, which is adding two, fixing some of the issues that we mentioned months ago, post one first in one. And we briefly looked at an update on CIP 27 which I think would be better addressed by script address and possibly otherwise be made as in other CIP as an extension of the existing one, if that's something the author still want to pursue. So that is it for today. Thanks for attending, everyone. And thanks for Kieran also coming. On vocal to explain everything that is nice. And let's try to follow up on that research involvement for the CIPs. **M. Àngels** -: As Matthias said, thank you very much, everyone for attending. Next meeting is not going to be in two weeks, it's going to be in three weeks because we are in a business trip in two weeks, and it's going to be held on the United States time zone. This is 4:00 PM UTC. Thank you very much and have a lovely day. Bye-bye. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-06-28.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [June 28 2022 Transcript](#june-28-2022-transcript) * [Triage](#triage) + [PR 271- CIP-0027? | Update Proposal: Multiple Royalty Addresses](#pr271) * [Last Check](#last-check) + [CIP-0054? | Cardano Smart NFTs](#pr263) + [PR267 CIP-0025: Added version 2 and cddl](#pr267) * [Review](#review) + [CIP-0044? | Additional factors for NFT market verification](#pr226) + [CIP-0381? | Plutus support for pairings over curve Bls12-381](#pr220) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) * [Discussions](#discussions) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 28/06/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## June 28 2022 Transcript **Attending Editors**: Matthias Benkort, Sebastien Guillemot, Frederic Johnson, Robert Phair. **Guests**: Morgan Thomas, Michael Liesenfelt ### Triage #### PR271 [PR271 CIP-0027? | Update Proposal: Multiple Royalty Addresses](https://github.com/cardano-foundation/CIPs/pull/271) **Matthias** -: CIP-0027? | Update Proposal: Multiple Royalty Addresses And that current CIP is already active. It's been used by a few marketplaces. So it doesn't quite make sense to modify it as much. As for the proposal itself, I made already some remark last week. I think the author came back saying: "Yes, true. But that would make for a worse UX. And therefore I would prefer the approach". They have a good rationale in the proposal, which is fair enough, but I still maintain that it should be made as a separate proposal, as an extension of the existing one rather than modifying what exists and has been used in a while. **M. Àngels** -: So I see you maintain a conversation. So from my understanding, Nicolas will need to make a separate, right? **Matthias** -: Yes, indeed. **M. Àngels** -: So shall we add that we are waiting for the author? **Matthias** -: I think that's pretty much the case now because the proposal by itself... **Robert** -: [Issues with the audio: Robert cannot hear Matthias] I don't think based on what Matthias was saying before, which he'd probably be staying now, if he could. It sounds like that can only really go ahead as a separate CIP because of the existing implementations that it would be incompatible with. **M. Àngels** -: And apologies on my lack of knowledge on this. So in this case, what is the next step. **Robert** -: As far as I know, we would say that this is waiting for author. And then if that is the agreement, then we would deprecate this one in favor of the new PR once the author submits it. **M. Àngels** -: Okay. **Matthias** -: I think it can also be the same PR right, it can just modify it. **Robert** -: I can add that label now waiting for author, if that's okay with everybody else. **Matthias** -: Yeah, good. **M. Àngels** -: I was doing it already, so don't worry about this. **Matthias** -: So the content itself, I mean, I already admitted my remark last week and I agree with the author. I think I've just asked him to put that as a rational because I would avoid having this discussion again. Should be fine, but just as a separate content. **M. Àngels** -: Perfect. **Matthias** -: It is too different. ### Last Check #### PR263 [PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263) Okay. So we move to the items on last check. So we have PR 263, CIP 54, Cardano smart NFTs. **Matthias** -: Yes. So this one was on last check, I think because it was substantially discussed on the forum. And this is like the results of quite a few weeks of discussions. Had another go at it today, actually. So made a few small remarks. It's mainly on the editorial aspect. So just titles and sections to stick a bit more to the template. **Robert** -: [Issues with the audio; Robert still cannot hear Matthias] I was hoping again, that Matthias was going to be jumping in with his eloquent voice because he's already said everything. He's made some substantial comments on this issue so far. And I think what he wrote today on GitHub is self explanatory for the things that the author would have to respond to still. I guess this could remain in last check until we have responses about all of those. So I would suggest postponing this until the next meeting. **M. Àngels** -: Okay. **Robert** -: Remaining in last check until we have responses from the author. **M. Àngels** -: In this case, I'm going to add also the label waiting for the author. **Robert** -: Yeah. #### PR267 [PR267 CIP-0025: Added version 2 and cddl](https://github.com/cardano-foundation/CIPs/pull/267) **M. Àngels** -: And let's keep this one for the next meeting. Perfect. Next item on the agenda is CIP 267, CIP 25, added version two and CDDL. Has two approvals, this one. What is missing from this one? Or it's ready to be merged? **Robert** -: It could be merged right now, it seems. **M. Àngels** -: Okay. So I understand that Matthias cannot approve because it's on Windows. So I don't know if you Robert and Fred could merge or either of you do it online. **Robert** -: It's done. **M. Àngels** -: Perfect. **Robert** -: I just wanted to give it a last call in case any last objections, but it's been approved all around. **Matthias** -: And I think the last objection was already the last meeting. As we said, it was approved, but we left it open for comment. There hasn't been any comment, so it's good to go. ### Review #### PR226 [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226) **M. Àngels** -: Then we go to the items under the review section, you have PR226, additional factors for NFT market verification. According to my notes, we were expecting this week to have some advance on this. I don't know who are we talking about two weeks ago about an example, but maybe I am confused with another PR? **Robert** -: It's the author, Eric Nichols here in any form today? I guess he would be coming forward if so. From the last comments that Sebastian made, I think there needs to be a little bit filled out in the text of this CIP so maybe if there's no one ready to discuss it, I would suggest that we note in the GitHub that we'd like to discuss this with the author at the next meeting, if we can. And to note internally that we're waiting for comments about the last review. **M. Àngels** -: I have asked for this PR and also PR 263, Cardano smart NFTs to the developers' newsletter and see if we can get feedback from developers if they would be interested. Because as far as I remember, I think that it was some concern... We wanted to get input from marketplaces and see if it actually was solving an actual problem from their side. **Matthias** -: We could maybe try to reach out to the marketplaces directly actually. I mean, there are not so many on Cardano yet, so I think it's still going [crosstalk 00:08:03]. **Robert** -: I'm just going to note on GitHub that from the CIP meeting today, waiting for developer feedback from NFT marketplace. **Matthias** -: Yeah. **M. Àngels** -: I am going to organize and see. **Matthias** -: If you can ping a few people. **M. Àngels** -: I know that we have some telegram channels with marketplaces so we can reach to them. **Robert** -: So you pitched via private channels? **Matthias** -: No. Via GitHub I think. That should be enough or perhaps on Discord, I don't know. **M. Àngels** -: Okay. We can discuss about how to approach them after the call, if you like to. And next one, #### PR220 [PR220 CIP-0381? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220) **Robert** -: This is beyond me technically as well. I can see that there's a good discussion about it, but it's above my level. **Matthias** -: Yeah. I think we have Las here. **Robert** -: All I can tell that there is... **Matthias** -: We could ask him [crosstalk 00:09:32] summary. **Robert** -: God, I can't even use my mouse button to get through the amount of discussion on this. **M. Àngels** -: Hi, Las, do you want to give us a brief summary regarding this PR. I am not able to hear you. **Matthias** -: Me neither. I'm not sure if Las is speaking. He has un-muted himself too. **M. Àngels** -: No, it was me that I am unmuted him. **Matthias** -: Ah, okay. And he's gone. **M. Àngels** -: I think that it has to do with... There's some worse things with Discord and the audio. I need to unmute. Let's try again. Now. **Las** -: I muted myself out of the system. **M. Àngels** -: Now, we can hear you perfectly. So would you like to make a summary on this PR? **Las** -: The data hash one? **Matthias** -: Nope. Not this one. The pairing over curve, BLS12-381. I think you've been putting many discussions on that one. **Las** -: Yes. I have. I was doing something else. Okay. It looks stable to me. I don't think there are many remaining questions. I think there was one remaining question that Michael answered with regards to what to do about the missing operations. I don't actually remember what he answered. Let me see. I think I have the answer right here. I think it might be okay as is. I don't think that's implementation or anything. **Matthias** -: The implementation is up to the Plutu's team, I guess, at the end or is it something that will be back-ported into Plutus from some other places maybe. **Las** -: I think the audio GZKP team or something, I don't remember what they called will work on it. **Matthias** -: Okay. **Las** -: I'm not sure of the exact situation though. **Matthias** -: Okay. I see Michael was also part of the conversation. So I will assume Plutu's team is aware of what's coming. **Las** -: Yeah, they're aware. **Matthias** -: Okay. So I think we can just reach out to Iñigo then maybe to see last message he posted was I've included your suggestions. I'm not totally convinced about this sub operation count. I removed that. Okay. So I think the author, Inigo is happy to go forward with that. And I did a few cosmetic remarks last time just to make it fit also with the templates. I would just love maybe to have confirmation from the Plutu's team before we merge that. But beyond this, it should be okay. **Las** -: Actually, now that I think about it, there might be one thing that we might have to change. I just thought about this, but we have both serialization and de-sterilization and I think it was actually me who recommended that we have both. Now, that I think about that may not actually be a good solution because the exclusion is deterministic. You just need one of them. I don't think you need de-serielization actually, do you? You can't have it if you wanted to have it in data, you need de-serielization. I was thinking because with data, we don't have any de-serielization data function because you can just pass in data natively and they're same with other things. In this case though, we can, so we need de-serielization. I actually think it's fine as is. There is a missing operation, the pairing one, but other than that, it looks fine actually. **Matthias** -: Okay. Thank you. **M. Àngels** -: So how would you like to proceed? **Matthias** -: I think we can move into last check from the next call and in between reach out to both Inigo and Michael to also have their confirmation on that. And then that will be merged as proposed, I believe until it's actually implemented and verified in the Plutu's primitives. **Las** -: By the way, it seems that Morgan Thomas wants to speak. **M. Àngels** -: Let's bring him on stage. Hello, Morgan. Looks like we are having a lot of issues with the audio today. New Speaker: [Audio issues] **Matthias** -: Okay. Could you detail a bit on that and would it be, you think, crucial for the CIP or would you see that more as an extension to it? Okay. So it's more like do it now because it might be useful later, but there's actually no current use-cases that requires it because I see the CIP considers side chains. The all knowledge [inaudible 00:16:14] basically. **M. Àngels** -: I only listen to you Matthias, are you speaking by comments or by chat or it's me that I am not able to hear Morgan. **Matthias** -: No, Morgan is speaking actually. So I think you are not able to hear him. **M. Àngels** -: Wow, weird. **Matthias** -: Okay. So is this something we've already discussed actually with Inigo or Michael? Because if not, maybe just bring that on the Pull Request comments and we can see how to proceed. Because that seems to me it's quite speculative at this stage that this might be useful later, which doesn't preclude including it depending on how much overhead also it adds on the implementation itself. I have absolutely no idea of what that entail on the implementation, but you probably have a better idea than me. Why Morgan is muted again? **M. Àngels** -: I haven't been able to hear a word. New Speaker: [Audio Issues] **Matthias** -: He is speaking. Okay. And what about the making those proposal for another already curve support. New Speaker: [Audio issues] **Morgan** -: We're not going to use elliptic curves for Orbis V1 because the support is not there. And so whereas I don't have a specific use-case for elliptic curves on Cardano right now that's because the support is not currently there. If the support was already there, then there's a high chance we would be using them. **Matthias** -: Okay. It's a bit of chicken and egg situation, but I would definitely encourage you to propose that as a CIP. I Think the Plutu's team is fairly reactive on those proposals. So if you need that or not need, but if you would want that for part of Orbis, just go ahead and make a proposal with the Plutu's team, there is a good chance that this can actually be reacted upon and end up being useful for you. **Morgan** -: Okay. Thanks. **M. Àngels** -: Matthias, would you be able to do a summary for the recording? **Matthias** -: Back to this one actually, that means we can, I think, move it to last check for the next one. **M. Àngels** -: Matthias, would you please be able to do a summary of the conversation between you and Morgan because I don't know why I wasn't able to hear it and I am concerned that it's not recorded. **Matthias** -: Okay. So Morgan is suggesting, or was suggesting to possibly add a support for a new operation that is currently not mentioned in the CIP, which might turn useful if it is there. Although there is not yet any use-case backing it, but it's also because the operation is not there that people does not feel necessarily the urge to use it. And you would like to avoid heading through a entire CIP process later on when it becomes actually needed. But he was also discussing actually having a different supported inputs of different curves, to have a more wider set to pick from for a wider set of applications, which would be in a completely different CIP in that case. And I just encourage them to do that and propose this in addition to Plutu's because this is something they wouldn't explicitly need for Orbis, at least in the first version, but that would be possibly useful later on. So if they have it, that's even better. And I think that team would be fairly welcoming that sort of request. **Matthias** -: So back to this one, I don't think Morgan wants to add that particular operation in the end if I got you correctly because mostly for the hassle that it would create on discussing and justifying adding it. If you do, then please comment on the Pull Request. We still have quite a long time because it'll be in a proposed state for a while and until it gets implemented. So there is also rooms for modifications once in proposed. But at least we'll move it to last check for the next meeting so we can get it merged and have it as proposed in the repository. **M. Àngels** -: Okay. Perfect. **Robert** -: Maria, one thing I noticed when I couldn't hear a handful of people's voices and I'm sorry if I talked over anyone without realizing it. Hitting Ctrl+R I think will refresh the audio part of Discord and that fixed everything for me. **M. Àngels** -: Yeah. I open a new window and it fixed it. I realized that you were talking and it was like you couldn't hear Matthias. **Robert** -: I could not. I'm very sorry about that. It must have sounded ridiculous. And I hope it doesn't look that way in the minutes, but that's it. Ctrl+R will redraw the window. Sorry, everybody. Okay. But hopefully, that solution will help other people. **M. Àngels** -: Yeah. Because it feels really strange because you can hear one person perfectly, but the other one is completely mute. So if this happens to any of you just open a new window and it will be sorted. **Matthias** -: And don't hesitate to use the chat also for that. So next one is CIP 50, I think. #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias** -: Which always gives me nice afternoons. **Robert** -: Do we have Michael today? **Matthias** -: I think I saw him earlier. **Robert** -: He's joined, but he's still muted. Michael, if you're here, maybe he could unmute yourself. **M. Àngels** -: I think I need to do it myself or any of you. The editors can do it too. **Matthias** -: Doesn't have it. **Robert** -: There he is. **Michael** -: Audio check. **Matthias** -: Yes. **Robert** -: Here are you? **Matthias** -: Audio check. Received. **M. Àngels** -: I think that I need to reset the screen sharing. Just give me a sec. Can you see my screen again? **Matthias** -: Let me check actually. **Robert** -: All I see are the cat heads. **Matthias** -: I see your screen, yes. **M. Àngels** -: Perfect. Thank you very much, Fred, for the heads up. **Matthias** -: So CIP 50, I've tried to summarize the conversation that happened over Discord last week. And I try to structure a bit the summary so that it could be readable in a way. Generally speaking, I think we want to avoid having those conversation on Discord. As we said, when we set up the Discord, it was really not meant to discuss the proposals, but just to organize around the meetings. So the discussion would be better to have on more public and more persistent forums. Although I get also that's GitHub discussions and GitHub issues just that it tends to become quite long and how to follow as well. **Matthias** -: So I don't know, we can perhaps create a dedicated channel on the CIP server just to avoid people floating the general, and we can keep the general for normal conversations or organizing around the events more than discussing CIPS per se. So I'm not sure how people feel about that. We haven't really planned for this, but I think there is room for having a fast-paced kind of conversation channel for the CIP, which could be just on the server, but not on general. **M. Àngels** -: As long as then we are mindful and transfer the important things to GitHub. And I think that is something that each one of us needs to be mindful of. Because if not, it's a lot of overhead for either you the editors or a single person. **Matthias** -: It is. **Robert** -: I think it's a great step forward to have a topic-specific channels on Discord. The problem usually is that everyone wants to present their own opinions as if they're consensus. But if you give people a little bit of time to vent their opinions in the more public forum, usually, the consensus emerges on its own. And then one of the participants can copy it back to GitHub at that point, like Matthias just did this morning. **M. Àngels** -: I just would like to make sure that it's not always Matthias or any of you that needs to be doing this extra work. **Matthias** -: And it's also my own perspective what I got from the discussion. So it's obviously, skewed to both my understanding and my own biases. [crosstalk 00:29:09]. **Robert** -: It can go the other way. Also, on the other way, I had been having a review of that thread privately with other correspondence and the author. And I actually should have been more public about posting my conclusions or my summaries, I suppose of the existing discussion back to GitHub. So when we do see common threads emerging, we should be willing to post them. And I think that would clear a lot of it up too. **Matthias** -: So what I see from the discussion and from the past discussion we had also, and I think I mentioned it already last time that there are multiple things being discussed as part of the CIP and it would be nice to maybe organize the conversation in multiple CIPs or multiple different forms of discussions. Like for instance, the protocol parameters, their value, and possibly changing K and things like that. That's orthogonal to the CIP and to just be discussed on the side. **Matthias** -: And more importantly, it seems that there is a clear divisions between the people who thinks that the CIP does not improve the current situation and the people that thinks it does. And at this stage, it seems to be both opinions and arguments would maybe lack of methodology or at least, an agreed upon methodology that people can use to judge whether or not this solution is better than the current one. The current solution, it has the advantage of being there. So being visibly effective or not in the while, but at least we can say, well, that current approach, we reach this minimum vector. We have reached this amount of stake pools. So it's visible. **Matthias** -: The new approach, it's very hard to say from just reading the proposal, what will be consequences. So there is really this need of a framework or clear methodology to both evaluate the solutions and according to some metrics and some outcomes that we try to maximize and say, this solution is objectively better than this one because this and this and that. And I think this is clearly missing on that proposal, which is why we have such a clear divisions between those who think it's not good. And those who think it's good, basically. **Michael** -: I agree with that. As the author, I've incorporated the updates and revisions to adopting that rigor and methodology to the path to active. As Cardano transitions to an open source project, we're going to have to be very good about reaching consensuses in a non-hierarchy away. And that includes all of the input and research of the IOG team. So if they're not participating yet, consensus is not reached yet, but they have responsibilities and obligations to deliver Vasil and so that comes first. But then after that, there should reasonably be a deadline on sharing prior research or turning it over to the community if IOG can't lead that research anymore. **Matthias** -: I tend to agree with the sentiment. It's a bit odd at this stage that the main party needed for that conversation is actually not taking part into the conversation, which make it very hard to move forward. Though there has been someone, "mkt" on Discord, actually also here mentioning is from IOG, but also would be nice to have a clear point of contact. I do agree. So far it has been Kevin, but Kevin is also busy with Vasil and other stuff at this stage. So we are a bit missing this point of contact with the IOG research team in particular. **Michael** -: There's no rush. It's more important to get it right. And not make, in my opinion, another peer review mistake. **Matthias** -: Yeah. So this is also why I've started to really poke our own researchers now at the Cardano Foundation, which is building also expertise on this, who agree on maybe trying to define an approach for evaluating the proposals and the solutions. So I've shared that as a last comment today, and I know that Reza also wants to join eventually the discussions. It was just not available today, but that would be also a step forward I think. **M. Àngels** -: Next meeting is going to be next week, but it won't match Reza's schedule. **Matthias** -: Yeah. Reza is in Canada so it's also in this time zone. **M. Àngels** -: So shall we put this on hold until Reza can jump into the meeting in three weeks? **Matthias** -: We can definitely continue the conversations on the side as it has been happening, but not on Discord channel, if possible. And get it back on, I guess, the CIP meeting, again in the US based time zone. **M. Àngels** -: Okay. **Matthias** -: We can also have a quick catch-up on it next week just to see where we're at again. **M. Àngels** -: Okay. And the thing that I would like to clarify because it is not clear to me is if we are going to do on specific channel on Discord or for the moment, it's still better to try to use GitHub as a more public reflected and official channel. **Matthias** -: I would prefer GitHub. If people strongly want a Discord channel for discussing this one, I think we can also go for that. **Robert** -: I think the only way we're going to see the improvement is if we create the Discord channel, I can't think of a better test case we will get for a topic specific discussions than this CIP we have right now. And at this panel, within a month or two, we could have similarly contended proposals. And we don't want anyone to have to do the work that Matthias just did in order to digest four weeks of discussions. So we can in the hopes of getting through it all on a single meeting. **Robert** -: So can we try to separate them and see if it works? See if we can rely upon the people to keep bringing it back into GitHub once some consensus or important points are made on Discord. And then if it seems like the balance is coming out wrong, if it seems like things are only being recorded in Discord, but not being taken back to GitHub, then we can maybe look at how that how we could make that process work. I just [crosstalk 00:36:49]. **M. Àngels** -: Can you explain it again, at least from my end, there was a little bit of background noise and I couldn't understand. I mean, I think that you were suggesting to keep the discussion on Discord, but make everyone owner of trespassing their comments. **Robert** -: I mean, a lot of the "discord" on Discord. A lot of the discussion on Discord was repetitive and we don't want that happening on GitHub. A lot of the repetitive discussion on Discord was opinionated. And we need a chance for the opinions to play out before they're recorded as actual point of view to be recorded in GitHub. So without having a forum for people to get through the preliminaries, we end up either recording too much on GitHub, which is the opinions and the bickering, or we end up recording too little because people forget to bring back the main point from the social networking channel to the developer's record on GitHub. **Robert** -: So I would say that we first try to create that channel to see how it works. And then we adjust the balance in both of those conversations to be sure that the less relevant stuff is confined to Discord and the most relevant stuff is recorded on GitHub. It will take practice, but I'm sure it can work. I do feel pretty strongly about that. And I'm willing to monitor it as well as do some of the digesting that Matthias just did, which I had intended also to do on my own at some point. **M. Àngels** -: And can I suggest to ask each participant in this casual conversation, one, not an opinion, but a more reflected position on this to ask to add it to GitHub themselves and not do the summary, the editors. **Matthias** -: I think this can work if we discuss precise question on a Discord and then our goals, if we have precise goals, and then we bring back the results, the outcome of that discussion on the GitHub. For instance, one thing I would like to see people agree on is what would it means to be decentralized for Cardano, for this whole thing here. If people can agree on a definition of what decentralization is and would entail with something that is quantifiable and have that discussions because from the past discussion, it's not yet agreed between participant what it means. **Matthias** -: But once this is agreed that at least gives one criteria upon which we can start judging the CIP and the existing solution. And that will be one question. Then we move on to a different question or a different goal. And we try to structure the conversation on Discord around those goals. Anything that deviate from those goals, well, it should be self-disciplined: don't do it basically. So try to keep an eye on each other, but just say: "no, this is not the topic. The current topic and discussion we try to solve is this particular thing". So we break that big problem into smaller chunks and organize just discussions on one particular action on Discord up until we have done or tackle all of them. **M. Àngels** -: We can give you a try. I mean, it's going to be a trial and error and we will need, as Robert said to learn from it. So let's give it a try if you agree. **Robert** -: Yes, it will be easier to do by setting up the discussion on that channel because the next time a contended issue comes along, it's going to blur the discussion. People may drop out or pay less focused attention. The framing questions that we might want to ask may get forgotten or push back farther in the discussions. I think that the only reason we've been able to focus on this particular issue is there aren't currently any ones like it that have attracted the same attention from the community. So we should move it off to a separate thread while we can do so easily before it gets mixed with other topics. So I would vote for creating that channel. Yes. **M. Àngels** -: Yeah. Are the rest of editors agreeing to create a specific channel? **Matthias** -: Yeah. So long as it can be a bit structured. Yes. Give it to try and see. **M. Àngels** -: Fred. I don't know if Sebastian is here too. **Fred** -: Yeah. All good here. **M. Àngels** -: Thank you very much. And I don't know if Sebastian... I will ask him later. So what I will do is if you agree is instead of creating a new channel as almost all the conversation in the general channel is around this CIP. I am just going to rename the channel and create another general one. So we have all the conversation or I can copy/paste it, whatever you prefer. **Robert** -: I didn't think of that, but I think that's a good idea because about 95% of the comments in that general channel are CIP-specific, and then new general comments can go into a new general channel. We don't want have a CIP 50 discussion without most of the comments that have been made already so that would actually catch them all up. I think that's a good idea. **M. Àngels** -: Okay. **Matthias** -: Fair points. **M. Àngels** -: Perfect. I think that this was all that was on the agenda for today because on our discussion there's specific topic around creating a specific channel for the CIP. I don't know if there's anything else that you like to discuss. **Robert** -: Just to be sure we don't miss this last point that Nick had made about the default channel. When people arrive in the Discord, whoever does the moving and renaming, we'll have to take a look at that of just looking at the last comment in the meeting room chat. So we have to look at that after moving the thing to be sure they're not dropped in this CIP 50 channel by default. **M. Àngels** -: So can you repeat, Rob because I thought I was understanding you and I got confused by the end. **Robert** -: Okay. Do you see the last comment that's made in the meeting, the CIP editors meeting room chat? **M. Àngels** -: Okay. Yes. This over here. So this is around CIP 50, right? **Robert** -: Yes. **M. Àngels** -: So I'll make sure to copy/paste and add this to the main conversation around CIP 50. **Robert** -: Yes. And if you're the one who creates the channel, just be sure that when new subscribers follow an invite link, they are not put- **M. Àngels** -: In the CIP 50, but in the general one. **Robert** -: ... In the renamed channel, but in the new general channel, not the old general channel. **M. Àngels** -: Sure. That's a very good point. Okay. So I suggest to do a wrap-up as we have only seven minutes left. So Matthias, would you like to do the wrap-up of the session? **Matthias** -: Yeah, let's go back. So am pulling out the Pull Request. So we looked at the royalty, the CIP about extending the royalty for NFT, to support multiple addresses, and we've asked the author to actually move that one as a separate CIP because it is essentially changing already established and active CIP. So a few comments, but those were addressed by the author. So they will be put as a rationale for the CIP. **Matthias** -: We looked into the Cardano smart NFTs on which there was also more recent comments. So we'll also have this one as last check next meeting, which is next week just to see if the author has addressed them or not. Overall, I mean, we do agree with merging the CIP as proposed, but there was a few comments first to address. **Matthias** -: CIP 25, it was already in last check in the previous call. There was so many comments done on it. And a few minor cosmetic changes we recorded last time were addressed. So we can merge that one actually. If someone can do, I think it has also didn't write number of approvals already. **M. Àngels** -: It was merged online by Robert. **Matthias** -: Thanks, Robert, didn't notice that. Then review CIP 44, additional merger for NFT market verification. All the ID looks good. The CIP is okay, but we want to have buy in from the NFT marketplaces. So as action item for the editors, we're going to share that with the prominent marketplaces on Cardano and see if that's addressing something they are also facing. **Matthias** -: CIP 381, a lot of discussion has been going on that one. And so last confirmed, it has reached a relative consensus so far. There was a discussion whether or not it should add an extra primitive, but I think, Morgan took it back. If not, please comment on the Pull Request. We also want to have confirmation from the Plutu's team that this is in the state where it can be acted upon and move from proposed to eventually being active. So we can have it as last check for the next meeting. And if nothing is said, we'll just merge it as a proposed CIP. **Matthias** -: And finally CIP 50, so we had big discussion on Discord, which we're going a bit disorganized. So we are going to set up a proper channel for discussing that one, try to be diligent also in bringing back updates. Points that are being agreed on during that channel back to GitHub so that we can also have a review on GitHub, and give like a public track record on what's happening for the CIP. Overall, we also need more investment from IO on that CIP, more engagement from IO research. So we'll wait after the Vasil Hard Fork has happened. And after that definitely, put a bit more pressure. Let's put it nicely on IO to participate on that conversation. Otherwise, figure out how we can actually move that kind of conversation forward as Cardano becomes more and more open source indeed. So let's have dedicated channel for that one and see where the conversation goes for next week or the next meeting. And that's about it, I think. **M. Àngels** -: Thank you very much all for attending to the session today. Next meeting is going to be held next week as we skip a week last week. So July the 5th at 8:30 AM UTC, I have added the next two meetings as events on Discord so you can plan in advance. The only thing is that the agenda will be added a week before each meeting. Thank you very much again. And I would like to ask to the editors if they can join me in the green room for two minutes, it's for the problem with one link that I would like to solve. So thank you very much and see you next week. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-07-05.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [July 05 2022 Transcript](#july-05-2022-transcript) * [Triage](#triage) + [CIP-0059? | Terminology Surrounding Core Features](#pr274) + [CIP-0038? | On-Chain Token Metadata Standard](#pr137) + [CIP-0030? | Events API](#pr151) + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163) * [Last Check](#last-check) + [CIP-0054? | Cardano Smart NFTs](#pr263) + [CIP-0381? | Plutus support for pairings over curve Bls12-381](#pr220) * [Review](#review) + [CIP-0044? | Additional factors for NFT market verification](#pr226) + [CIP-0050? | Shelleys Voltaire decentralization update weekly update](#pr242) * [Discussions](#discussions) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 05/07/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## July 05 2022 Transcript **Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. **Guests**: ### Triage #### PR274 [PR274 CIP-0059? | Terminology Surrounding Core Features](https://github.com/cardano-foundation/CIPs/pull/274) **Matthias** - : Yeah, we can start already and go right in the first item, right, CIP 59, which was proposed by Jared, I think after a chat on a different CIP or different debates around Vasil versus Babbage, and what do names mean exactly in Cardano. A lot of people seem to have gotten confused by the names being employed. So he wrote a small, informational CIP, there is not really much to debate in a way except maybe if people disagree with it and want to change it, but since there is a track record already... It just explains where the name come from, what they are and the rationale behind is, why they were chosen like that. Like between era, and a phase, and a network and protocol. And he has also put up a nice table which summarizes all of that, which is nice, so it gives just a bit more clarity about naming. **Matthias** - : And yeah, so I pointed to him last time a few things to do regarding the proposal of just the editorial stuff, putting a number, putting the readme in the correct folder. He did all of that and he already marked it as active as I suggested, just because as I said, it's an informational CIP explaining the terminology picked by the core team. It's from the core team itself and it's also recording or explaining things from the past six eras or so. So yeah, there is no point going to things like propose, and then active, and then whatever, unless someone disagree with that. Okay. **Sebastien** -, and your opinion maybe, if you are here. **Sebastien** -: I joined probably through the conversation, so I'm missing the beginning. **Matthias** - : Yeah. Okay, sorry. We are talking about CIP 59, the terminologies surrounding core features, which was proposed by Jared some time ago to clarify a bit of the terminology around the core features. And I was saying, this one could probably just go as active right away because it's just explaining what's in there. **Sebastien** -: Yeah, I think so. I think that makes sense. I read through it and everything, and it made sense to me. So I don't mind both merging and marking it is actually the right away. **Matthias** - : We have a question. Oh sorry, that's some other stuff. So yeah okay, let's do that. I think we have reviewed it. I would just add my review now, that's all the... Yeah, All change has been made. Happy to approve. Happy to merge. Okay. Next one, on chain token metadata standard which has been reviewed for a while. We had a few remark questions. A lot of people were debating stuff in particular. The security of that, I think Michael Peyton Jones is usually against anything that is put on chain and it is based on minting transactions because indeed it has security issues or implications. **Matthias** - : If we start heavily relying on people providing the metadata being the same as people minting the tokens, which has been generally the case in Cardano, but it's not a given. So I think he has a fair point. But yeah, the proposal has been stalled ever since, I think. It hasn't really moved, we are waiting for the author to come back to it. But yeah, I'm not sure if there is much to say on this one. Yeah. No remark, no question. I guess we can just leave it there. **Sebastien** -: Yeah. I have something on this topic, but I'm going to have to address it in maybe a minute, if you just give me a minute. **Matthias** - : Yeah, okay, okay. So depending on what you see, we'll see what to do with that one. Maybe it can also be picked up by someone else for a different standard or maybe reformulate the ID in a slightly different way. Yeah. And I don't know if there is any prior work also on that, I bet there is. So people putting all kind of metadata on chain. Now that has been the case for NFT, and I don't know if it has been the case for tokens themself -- I mean fungible tokens, at least I don't recall any project doing that. **Sebastien** -: Okay. Sorry, I'm back. Sorry, I had to step on the elevator really quickly. Yeah. So the problem with the CIP is just the metadata portion of it. And Michael Peyton Jones is correct that there is no partially good solution to this. And yeah, my understanding is that there's a lot of discussion, then we are waiting for the author. I was wondering if maybe we pick this up as part of the log standard that I talked to you about over DM. So to fill everybody in on this, basically in Plutus, you can log messages as a trace command. Apparently, this is ignored by everybody, but you... indexers that basically rerun the Plutus code, figure out what the log statements were for the execution and then make this available to indexers to do stuff on. **Sebastien** -: So if we standardize this logging format with a topic, we could do minting transactions, can basically log out the metadata only once in the transaction and then get some agreed upon standardized topic for this. And then indexers would just need to be looking for additional places for contracts, they would just look for whatever minting transaction includes log statement that provides this information. **Matthias** - : But you would also not be solving the problem that Michael was pointing at, right, which is that it's not necessarily the same person that is providing the metadata than the one doing the minting, it changes how you specify the metadata. So instead of having them as plain metadata, which is not verifiable in a way, you just have them as script logs. And I think I also agree with Les, and that's what I was telling to you in, well, private. It sounds to me like it would be very inefficient if every indexer has to run all the scripts in order to extract the metadata, although that could be worked out, I guess if we have a special maybe piece of metadata that identify those such transactions. So I don't know, a certain label if present, you know you have to execute script and extract the logs from it. So perhaps we can just bring it as a different CIP. **Sebastien** -: Yeah. But I think it does tackle the issue because it makes other person writing the contract the same person that owns the token metadata, because it's no longer going to be in the transaction metadata field. So it couples the two together, is what you wanted to solve the issue, right? **Matthias** - : So you mean that, ah, it's captured in the policy itself. **Sebastien** -: Yeah. Exactly, yeah. **Matthias** - : Yeah? Okay, okay. I guess then you could make the argument then. **Sebastien** -: I think this would solve this issue. So I feel like we could revisit this if we just come up with the solution for the logging problem, which requires us to come up with a sip for how to come handle topics for log statements, which doesn't have right now. And then another sip for how we want Cardano to change to make this efficient in some way, shape or form. **Matthias** - : Yeah, yeah, yeah. Because the logging, we have it at a stage, but you only have it, I think, if the script is failing. So when the script is happily successful, I'm not sure you can get any trace really out of it. But yeah, I guess the first good step is a CIP, which might requires another CIP, which would be a new Plutus built-in for doing this topic centric logging. **Sebastien** -: Yeah. Which I think is the right solution because we could try matching a topic into the existing logging scheme, but it would be ugly. So probably it's better just come up with a new built in, come up with a solution to make it efficiently, and then we need some hassles [inaudible 00:10:52] developer to volunteer to do it, which is obviously the hardest part. **Matthias** - : Yeah. I think you're going to get a lot of pushback on the logging idea because as I was saying, Plutus is just one big expression right now, there is no statement or imperative execution. So, when do you put a statement and where do you evaluate a statement is up to the interpreter at this stage, even though everything is strict and it's pretty much, well, intuitive. That's probably getting in the way of low-level optimizations and stuff like that. If you start requiring stuff to be done in sequence, and to be able to rely on that as a contract writer, that might be tricky. Perhaps actually, Las also has some inputs on that because from working with Pluto / Plutarch, that's maybe something you also thought of. I'm not sure if you want to. **Sebastien** -: Yeah, it don't necessarily mean to hijack the CIP meeting to discuss this, but definitely Les, if you have some thoughts on this, or if you wanted to take this offline after this call and discuss this, I'd be really interested because this is something that we want for a few different projects on our side, and I'm sure this would unlock some other stack or other use cases like this token metadata on chain registry. **Matthias** - : So sorry, I'm just writing on the chat. So yeah, let's just make a CIP offline discussions out of it for now and see. But yeah, I think my sentiment is that you would probably get some pushback from the Plutus core team because you're going to introduce side-effects. **Sebastien** -: Yeah. Yeah. We get pushback on every feature, so it's just part of it. #### PR137 [PR137 CIP-0038? | On-Chain Token Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/137) **Matthias** - : Yeah. It's part of the game, I guess. If you can argue it well enough, maybe, but yeah. Okay. So for this particular one, which was CIP 38, I think we can just park it for now on the side, meaning that we're still waiting for the author. And if the author is not willing to move it forward, we won't be doing it for him basically. So yeah, there has been a few things said already, it's all recorded on the pull request as comments. So yeah, next steps are up to the author, not us. #### PR151 [PR151 CIP-0030? | Events API](https://github.com/cardano-foundation/CIPs/pull/151) **Matthias** - : Which brings us to the next one, CIP 30, which is, I guess in a similar situation. I think we talked about that one several times in the past. Also, it was initially part of CIP 30, it was then extracted when CIP 30 was merged because there were still ongoing discussions and people were not sure whether or not they wanted it. I think there are a few wallets now that supports events as part of, not about CIP 30, but as part of this wallets extension work. And there is, I think, even a website put by this is part, right, with the state of what people support through the extension, right? Some things are labeled as experimental and I recall there was something related to events in there. **Sebastien** -: Yeah. So we put the old event that Nami had on the initial release, which is slightly different than what's in the events API PR, because the events API PR takes what Nami had originally and adds just on top of it. **Matthias** - : So I'm just trying to find, okay, the website. Here is there just for linking it in the chats for people who wonder, so this is what I was mentioning ( https://www.cardano-caniuse.io/ ). **Sebastien** -: Yeah. And I still think we should have some event scheme. It just hasn't been a priority for a new one, which is why the CIP stalled. I do think it's important to have it. **Matthias** - : Yeah, okay. So I guess when the need will arise again, that CIP will just be either resurrected or superseded by some other CIP. But at this stage, the proposal is pretty dormant and waiting for the author. So, also not much to talk about, I guess. #### PR163 [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/163) **M. Àngels** -: I added these few PRs to the agenda because we have been waiting for the author for several months. So I was wondering what to do in these kind of cases that the authors do not respond. **Matthias** - : That's a good point. We could also close the PR after all, if there's some inactivity. People are still free to come back and ask to reopen them or comment on them saying, "Hey, I'm here. I have changes," or make a new PR, but I think it's not a big deal. But if we do that, I would also first, maybe mark it as a change in our CIP process, so make an update on, CIP 1, just say, "After X months of inactivity, we'll just close the Pull Request for keeping things tidy." That doesn't mean this proposal is rejected or anything, it just means it's inactive and we need to put some order on the repo. **M. Àngels** -: Do you think it's worth it to make that change on CIP 1? **Matthias** - : Yeah. I mean just making it in CIP 1 to be upfront saying, "This is what the process is," and at least people can also disagree with process as we change it, right, it's important, I think, to leave also the conversation open for that. But yeah, I would definitely say after, I don't know, four to six months of inactivity, which is quite a lot, we just close the Pull Request and people are free to come back with a new Pull Request if they still want to promote or propose their changes. **M. Àngels** -: I think it's good because in that way, we have a process and we don't need to revisit those proposals, and they are not waiting for the author forever. **Matthias** - : Yeah. Yeah. And we avoid having too many Pull Requests stacking up, which are just waiting for author. **M. Àngels** -: Mm-hmm. **Matthias** - : Yeah. **M. Àngels** -: Good. I think that might be another one in the same study, so we can just skip if... **Matthias** - : Which is the CIP 37, right? **M. Àngels** -: Yeah. **Matthias** - : Yes. Yes. Yes. So I guess we'll just leave it there for now. I will propose the small change to CIP 1, and yeah, we can redo it next week, I guess, fast track it a bit if people really disagree with that, but I don't think it's any big deal. We'll move forward. ### Last Check #### PR263 [PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263) **Matthias** - :So next is, last check, Cardano Smart NFTs. Yes, indeed. I guess same situation here. The author was a lot more reactive, but yeah. It was a few comments last week and I think the author still haven't got time to go through them, so we can just keep it for this week and put it again to last check next week. **M. Àngels** -: I have approached some marketplaces trying to get their input. So I think it's good as you mentioned to wait until the next meeting and see if we get feedback from them. **Matthias** - : Okay. Do you think maybe we can mention it on the Pull Request, all the marketplaces you've approached just to have a track record on the PR itself? **M. Àngels** -: Yeah. Do you want me to do it myself? **Matthias** - : Yeah, since you know who you've contacted. **M. Àngels** -: Okay, cool. So I'll do that. I will add a comment after the call and mentioning the marketplace that had been approached. **Matthias** - : Yeah. And there was also a mention in the newsletter, I think Robert pointed that out on the PR. On IOG newsletter, there was a mention of two CIPs if I recall correctly, there was this one. **M. Àngels** -: Yes. He added the link in a comment. **Matthias** - : Yeah, added the link, exactly. CIP 44 and CIP 54 were mentioned, that are touching CIP marketplaces or NFTs. #### PR220 [PR220 CCIP-0381? | Plutus support for pairings over curve Bls12-381](https://github.com/cardano-foundation/CIPs/pull/220) Yeah, okay. Next one, the pairing support over BLS 381, which we discussed a bit last week. And yeah, it was discussed with the Plutus' team, reviewed, adjusted many times. So yeah. So maybe the only thing is to see if the status shouldn't be changed to propose perhaps, I think it has reached a maturing of stage to be proposed now. So I will ask Nigo if he can do that. Yeah, and it has also just renamed the file to readme. So okay, beside a few minority editorial work, this one should be ready to go. So I will just comment directly. Okay. And I think... Okay, any comment on that one? No? Yes. I think we discussed it extensively last week already. ### Review #### PR226 [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226) **Matthias** - :Okay. So CIP 44 is next, and is also one we are waiting for NFT marketplaces feedback. Well, at least it is the main one. **Sebastien** -: Yeah. I think the message asking for feedback was sent out a day or two, right? So I think we're still waiting. **Matthias** - : So there's probably not much to do today on this one. Yeah. As we said last week, the ID looks good overall, but we had the question on whether or not this is useful for NFT marketplaces or endorsed by NFT marketplaces because it has to in order to become active. So we better include them early on in the feedback loop before merging or yeah, going with the proposed CIP. #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update weekly update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias** - :So I guess we can just move to the next and last one on the agenda. Our favorite, CIP 50. I haven't got time to go through all the comments since last week, there has been a lot discussed. Again, there is a new member, I would say, in the discussions now, Robert, who is a mathematician working at Tesla, from what I got, who has got an interest in the CIP. So there has been quite a bunch of conversations between yeah, Rob and Michael, fortunately on GitHub this time, on the GitHub issue. We also have created a Discord channel for that one as we've been discussing last week, so a few more discussions have been going on here as well. **Matthias** - : And I've also spoken to Kevin Hammond from IOG last Saturday actually, about again, trying to get back the researchers from IOG into the conversation. So Kevin was quite surprised actually that this didn't happen because, to quote him, "Usually researchers are quite happy to provide feedback on their work if given the opportunity." So he's going to change that a bit and see if people can actually get into this study group that we've been trying to push up last time already, yeah, and get that moving. So I've put that in his hands so far. With the Vasil out of the way now, he has a bit more availability to pursue that on the IOG side, so yeah, fingers crossed and we'll see, I guess in the next biweekly, if this has lead to anything. I should also probably mention that on the CIP PR itself so that people who are currently discussing are also aware, and then maybe up to the author to see who he wants to include in the conversation from his side as well. **Matthias** - : Yeah. So beyond that, I haven't gone through all the comments. We could go through the comments as part of this current biweekly as well, since we have a bit of time left, or we could leave that for another time and try to do again a summary of the conversation that had been happening. Any thoughts on that? **Sebastien** -: Yeah. For this one, I feel like the summaries are nice, but I feel this one needs more than just a summary. **Matthias** - : Of course. And as I said last time, I think this one can only move forward. At some point with regards the participation of IOG research. Without that, I'd say it's very difficult for that proposal to make concrete steps. And yeah, we have, I think two, yeah, Christopher and Colette. I think you are here both of you probably for the CIP 50, so maybe you have all sorts of stuff you want to discuss or say, please bring them up. Yeah, so I guess same situation for everyone. So I don't really have anything to add mainly in this call. We're talking about safety process in general, okay. And okay, so both of you. So is there any other items then we could discuss today before we wrap it up on maybe CIP 58? I don't think we have talked about that one yet. It was proposed and then proposed again in a new format, I think. So it's not from the same author, but it's from the same team as far as I understood, so it's superseding the previous proposal. So the first proposal was... Where it is? I'd lost it now. **Matthias** - : Okay, it was PR number 268 and the second proposal was PR 283, which is a new Plutus set of built-ins about doing bitwise operations in Plutus. So manipulations on bits, which is quite common to do on low level stuff. It's been missing from Plutus so far, there is very no support from manipulating byte strings in general and doing bitwise operations in Plutus. Although it can be quite interesting because of the, well, performance aspect it can also bring in the picture. So it's a bit risky these things usually. So I haven't gone through the proposal yet, but I hope that it's introducing a somewhat safe API for doing bitwise operations and not allow people to shoot themselves in the foot with this stuff. I see it's proposed by the MLab's team and it has also been discussed with the Plutus team quite extensively, it seems. So this doesn't come out of the blue basically. So I think it'll be good to have it for review next time so that we get some good time to go through it, have a few comments and re-bring the spotlight to it on the next biweekly. **Sebastien** -: Yeah. Makes sense to me. **Matthias** - : And we can maybe do a bit of PR management at the same time and see if we can close the first one. I will just comment on this directly. It's marked as legacy deprecated already. Yeah. And Robert actually already commented on that. Okay, anything else? I see there is a small one, maybe PR number 275, sorry, which is just updating line numbers and this time, putting an actual permalink link in CIP 8, which I think is good. So initially, it was just updating line numbers, I think, but then Robert rightfully asked to just put a permalink link in there so that we don't get to update that line number every week. So **Sebastien** -, that's probably something also you would have a minor comment on. I'm not sure if you are still involved with the CSL anymore, or if you are fully switched to the multi-platform library. **Sebastien** -: Yeah. I haven't touched CSL for a long time. Yeah, for the comment related to WebPull, I don't know of a good alternative website that allows you to run WebAssembly in the browser for free. WebPull is the one of the few that did it, but I feel like now that WebAssembly is more common, there might be other platforms that work better. **Matthias** - : Because a rep needs to be paid by an owner? **Sebastien** -: Yeah. So it used to be free and then they changed it to paid, which is why it all links up probably. **Matthias** - : Okay. So at the same time, it's also filled to the current PR, so perhaps that's one good use of an issue. That's the other rep link, it doesn't work anymore, fine. But at least this PR fixes already a dead link, which is good in itself, which is comment to that actually. Okay. Nope, doesn't work. So I will open an issue following that. And where is actually the comment about rep link? Here. Rep link eight. So rep eight link doesn't work more. Okay. So this one is done. Do we have any small PR like that or should we just wrap it up for today? Or anything else people want to bring forward? Nope? Oh sorry, I've got a phone call. Okay, sorry about that. ### Discussions N/A ### Issues N/A ### Close So let's wrap it up, maybe? **Matthias** - : So we went through CIP 59 today, the terminology that runs core features. We agreed to merge it as active, as it is informal CIP bringing clarity on naming and coming from the core team directly. Then we've looked at CIP 38, CIP 30, CIP 37, I think that's the only three ones, which are waiting for an update from their authors. We discussed that for those CIPs that have been idle and dormant for a few months, it might be good actually to just close the Pull Requests and well, let the authors come back with either a new Pull Request or an update if they do. But before doing that or in parallel of doing that, also specify that, "In the CIP 1, as a small change or in the process," so that we are upfront with what's going to happen. And it'll help us keep the repository tidy. **Matthias** - : Then we discussed CIP 54 and 44, which are two CIPs about, one is smart NFTs and the second one is additional factor of verification for NFT marketplaces. In both cases, we have reached out to the community and to marketplaces in Cardano to get their feedback on it. So we've reach out to the community through the IOG newsletters, and we've reached out directly to the marketplaces to see if we can get any buy-in from them. Discussed CIP 381. This one, mostly mature to be now merged as a proposed CIP. There was two minor editor changes to be done, first, just renaming a file as readme.md and changing the status to proposed. So we've pinged the author on GitHub, once done, we can move forward and merge that one. And the path to active will be the implementation in Plutus by the Plutus team and the delivery through probably another Hard Fork. I'm not sure if this one occurs at Hard Fork though, might not be, but anyway. **Matthias** - : We discussed then also briefly CIP 50. There has been many comments done between last week and this week, and basically no one really had time to go through them, so we'll discuss it again. In the meantime, we've reached out again to our IOG research hoping that they will be joining the conversation so that we can move forward that whole conversation with them. Then we briefly touched on CIP 58 that we want to bring to review for the next biweekly meeting. It's also a subject to primitive for Bitwise manipulation and a bit more of binary manipulations on Plutus, and I think a few other minor things like broken links and yeah, small additions. That's about it, unless I forgot something. **M. Àngels** -: I think it's everything. **Matthias** - : Mm-hmm. **M. Àngels** -: Thank you very much to all the attendance. Next meeting is going to be held in two weeks, July 19 at half past eight AM UTC. Here in this court, you have the events, this is the next event. And today I am going to upload the following one so you can plan in advance. Thank you very much and see you in the next meeting. Bye-bye. **Matthias** - : Thank you. **Sebastien** -: Bye guys. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-07-19.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [July 19 2022 Transcript](#july-19-2022-transcript) * [Triage](#triage) + [CIP-0058? | Bitwise primitives](#pr283) + [CIP-0003? | Broken links on the website](#pr109) + [CIP-0030? | deprecate signTx & add chain signing](#pr206) + [CIP-0030? | Adding optional networkId parameter to .enable](#pr209) * [Last Check](#last-check) + [CIP-0054? | Cardano Smart NFTs](#pr263) * [Review](#review) + [CIP-0044? | Additional factors for NFT market verification](#pr226) + [CIP-0050? | Shelleys Voltaire decentralization update weekly update](#pr242) * [Discussions](#discussions) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 19/07/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## July 19 2022 Transcript **Attending Editors**: ~Matthias Benkort~, Sebastien Guillemot, Frederic Johnson, Robert Phair. **Guests**: Kevin Hammond ### Triage #### PR283 [PR283 CIP-0058? | Bitwise primitives](https://github.com/cardano-foundation/CIPs/pull/283) **M. Àngels** -: Thank you, Fred. So we will start with the triage. The first item on the triage is Bitwise Primitives. So this is PR 283. So any of the editors want to give a brief explanation regarding this PR and the status? **Sebastien** -: So although not an editor, Michael Peyton Jones is the main one who was kind of fitting this. And I don't think he is on this call. He's usually in these meetings. We may have to skip this one, here. **M. Àngels** -: So shall we wait until Michael joins the meeting? So he will give an overview of the PR? **Sebastien** -: Yeah. Ideally that, or somebody from mLab, the [inaudible 00:08:34] lab is here that wants to talk about this. Even though Michael Peyton Jones isn't here, who's the main person who not only is reading it, but the [inaudible 00:08:46]. That's something we can do. #### PR109 [PR109 CIP-0003: Broken links on the website](https://github.com/cardano-foundation/CIPs/pull/109) **M. Àngels** -: Okay. Sorry, if you hear a baby, it's my sister's, which is around. So, next item on the agenda is broken links on the website, which is PR 109. So this is under issues. We have the pull request, but organically by the community, we starting to receive open issues. So I can make a brief summary of what I know. So there is CIP number one. **Sebastien** -: Do we need to go over this pair, I think? Because there's a lot of people here who are not editors. So I think probably it's not worth their time. **Frederic** -: And that one is closed, right? So we good. **M. Àngels** -: Can you repeat, Fred, please? Fred, were you saying something? **Frederic** -: I was saying there is been closed. For those who know where, there's an autogen site that is started on the site that lets you access directly the body of the PRs, the equivalent of GitHub. So it's on... seems that Cardano Foundation. It's resolved. I mean to say, we can move to the next item on the agenda. **M. Àngels** -: I think that I am still having issues accessing one of the items over here. So I'm still facing a broken link. But maybe we can take this offline. #### PR206 [PR206 CIP-0030? | deprecate signTx & add chain signing](https://github.com/cardano-foundation/CIPs/pull/206) **M. Àngels** -: We can take this offline and we can go to the next item on the agenda, which is CIP 30, duplicate sign transaction and add chain signing. **Sebastien** -: I can talk about this one. So this is basically the fact that right now, whenever you want to chain transactions together, using CIP 30 is kind of awkward. The reason why is because wallets need to show the confirmation prompt that tells them what kind of transaction they're confirming and needs to know what keys to sign with for the inputs. If the input for a transaction isn't on chain yet, there's no way for the wallet to easily know this information. And this leads to problems, because users may want to submit mobile transactions on their favorite decks, but get an error saying, error, you're trying to use... So you tick so that isn't created yet, which is not a great user experience. So to solve this issue, we can allow that to kind of inject knowledge about pending transactions into the wallet. **Sebastien** -: And this is the only real way to do it, because even if the wallet has man pool support, this is not a perfect solution, because it's all the issues where the chain transactions that were all submitted to the wallet. But that's not always the case. The only kind of generic solution to this is for the DApp itself to give hints about pending transaction state so that the wallet can use this to send a transaction, and assume a specific case will be accepted. So to implement this feature, we basically modify CIP 30 to add this kind of information to the signed transaction function. At the same time, we also modify the format of the endpoint to basically make it easier to modify this in the future. Questions? **Frederic** -: So one of the question I had regarding that entire process is, is Rob on board with it? So Rob is the original author from CIP 30 and the modification of Bayou. **Sebastien** -: Yeah. **Frederic** -: Okay. **Sebastien** -: And you can see in the discussion on the CIP, there's also Marcel from Farrell that's talked on this issue as well. The problem with the CIP is, as all other modifications to the CIP, there's no governance for CIP 30 that is explicit. So it's unclear when, if, how many changes to CIP 30 should be merged. So this PR, along with the next one we're talking after this, it's just stuck in this limbo. So to avoid getting things stuck in limbo, I just want to spend some time coming up with a way to change the CIP 30 structure to make it easier to have alternatives for various endpoints. And this is also something that the catalyst team was interested in, because they also want to use the same kind of flexibility to potentially introduce a governance API into CIP 30. So it may be that you want to merge this regardless, or we may want to keep this CIP on hold until we get this extended enabled functionality that, because the team also wants to be implemented, that will help their life and also help push this proposal through. **Frederic** -: I feel that merging will be the easiest path forward, but I agree that if this goes down that path and it can just become a bigger mess later, and it might warrant a separate conversation. By the way, for anybody interested in participating, there's a CIP chat room. I can see that Andrew's in the room right there. I don't know how to proceed regarding this one. Rob, how do you feel? **M. Àngels** -: Rob? I don't know if you are talking, but at least me, I am not able to listening to you. **Sebastien** -: He's just- **Frederic** -: I am hearing Rob. **M. Àngels** -: Okay. **Frederic** -: Maria's just restarting the stream. She'll be right back. **M. Àngels** -: You can refresh the page. Now I can hear you too, Rob. **Robert** -: Okay. Both of the options that Sebastian said sound good to me. I think it would be great to have some kind of governance process for this, because there are so many contributions. I think it would be great to include Rob on the governance question itself and then maybe go ahead with this or maybe wait, I don't have any particular opinion about it. [Now I've lost everybody.] **Sebastien** -: We'll see if the Catalyst team is interested in pushing for their potential change to sit through for the [inaudible 00:17:03] function. This is something that was discussed, but not something that they've decided on. It's an open question. But if you decide to spend time on that, we may as well move in that direction if revisiting this issue in a month, two months' time [inaudible 00:17:19] before we can decide to just merge and move on. **M. Àngels** -: Shall we ping anyone in the comments? Because you were talking about a person that I thought it was Rob, but then I understood it was another person that is involved in this PR. **Robert** -: It's Rob with the nine Os in the middle. R O O O O B. **Sebastien** -: Yeah. Rob, Rob Aptius. He's a business [inaudible 00:18:02]. **M. Àngels** -: So, should I ping him? **Frederic** -: The other, more involved option... Yes, please. Ping him in the comments is going to be good. The other option will be to maybe fork the PR and just make it clear that it has a governance component where people can add and modify it, even though they're not the main author. Otherwise, if we get the access like in [inaudible 00:18:23]- **Sebastien** -: Yeah. So that's where Matthias is wanting to work on. He's talked about potentially writing this. **Frederic** -: Okay. **M. Àngels** -: So what do you want to do? How do you want to follow with this one? **Sebastien** -: I would just put this on pause because there's not really a rush to merch it, and then see it in one to two months' time what's happening with the Catalyst folks. And if they help us come up with a new registration standard for a CIP 30, that would solve this issue. **M. Àngels** -:You are okay. You are right. Because I needed to... Thank you very much for that. Okay. Now should be able to, right? So perfect, we are going to put this on hold and we are going to ping Rob. Any of you want to do it? If not, I can do it myself, but I need to know what exactly do you want from Rob? **Sebastien** -: I don't think you need to ping him. I don't think it'll prove anything for it. **Frederic** -: Thank you. We can just add a comment, Maria. Feel free to take it on. Just that this is on pause until we have [inaudible 00:20:06] back for CIP 30 and how to add public single contributors. **M. Àngels** -: This is on hold until... Can you repeat, Fred, something about CIP 30, right? That we're waiting? **Frederic** -: Until some kind of governance path can be discussed further regarding updating the CIP without being the lead author. **M. Àngels** -: Makes sense, I guess. **Robert** -: Do we also want to add something that the question is being pursued in a Catalyst proposal? Did I get that right? **Sebastien** -: No. No. It's just the Catalyst team is working on a feature that where they may also benefit from the same solution that this CIP would benefit from- **Robert** -: I got it now. Okay. Thanks [inaudible]. Nevermind then. **M. Àngels** -: Shall we [inaudible 00:21:10]? Or it's not necessary? **Sebastien** -: No, you can leave it out. #### PR209 [PR209 CCIP-0030? | Adding optional networkId parameter to .enable](https://github.com/cardano-foundation/CIPs/pull/209) **M. Àngels** -: Okay, perfect. Good. Then we can move to the next item on the agenda, which is also CIP 30, adding optional network ID parameter to enable. **Sebastien** -: And this one is stuck for the same reason. ### Last Check #### PR263 [PR263 CIP-0054? | Cardano Smart NFTs](https://github.com/cardano-foundation/CIPs/pull/263) **M. Àngels** -: Okay. Let's leave the same comment. So then we have in last sec, CIP 54, Cardano smart NFTs. **Sebastien** -: So this one was waiting for feedback from NFT marketplaces if I remember correctly, right? Or was it a separate one? **M. Àngels** -: I think it's a separate one, because there are one that includes a marketplace with its NFT market verification. And this one was added to the developers digest newsletter, but this wasn't requested a specific input from marketplaces. If you need it, we can do it. But for a conversation I had with Matthias, only the other one required a specific input from NFT marketplaces. **Sebastien** -: So what was the blocker? **M. Àngels** -: Can you repeat? **Sebastien** -: So the blocker for the CIP... Was this blocked for the same reason as the fungible token standard, which is the security concerns, but leveraging the mint transactions again? I think in general, probably the CIP will want to reflect the upcoming changes to Vasil, which gives them a better solution to the problem they're trying to solve. So their approach may be somewhat deprecated by this. And in fact, there's two CIPs that were introduced in this, we created the agenda, 66 and 68, that kind of tackle the same problem, I believe, but using Vasil features. **M. Àngels** -: From the notes that I have from previous meeting, I think that the author was about to do an implementation. And, if implemented, we are going to move it to lab dev. I don't have more information if this has happened. **Sebastien** -: That's fine. I don't remember a reason in particular to avoid merging, other than the concerns that were raised by the approach and the fact that we may want to revisit this in the context of the newly introduced Vasil hard fork changes. **M. Àngels** -: So you suggest that we wait on the Vasil? **Sebastien** -: No, no. I'm just saying that they may want to add a section about this or consider their API, given these new features, or maybe they don't care. I don't know, but as far as I'm concerned, as long as they have an implementation, I don't mind merging it. I don't think there's anything technically wrong by the proposal. **M. Àngels** -: [inaudible 00:26:08] test approved the PR right now. So we would be missing one approval. **Frederic** -: Yeah. There's conflicts to resolve. **Robert** -: Hold on a sec. Okay. **Frederic** -: It's a matter of speaking the numbering. So I think 54th will be fine. **M. Àngels** -: Now we have... oh? No. So Fred, are you trying to solve these conflicts, or shall we wait and do it offline? **Frederic** -: Do it offline. Do it after this. **M. Àngels** -: Good. So once the conflicts are resolved, shall we merge it offline? Or shall we leave it to merge online in the next meeting? **Frederic** -: I think it's going to be fine to merge after this meeting once it's there. I'm just looking at it, and it's just the tentative proposals that are in the work. And it's just a matter of moving it to Robert, Sebastien. We've been doing the last ones. If you want to do this one, otherwise it should be fine [inaudible 00:28:14]- **Robert** -: I'll have a look after the meeting goes. I'm looking at it right now, but we'll finish it up after the meeting. ### Review #### PR226 [PR226 CIP-0044? | Additional factors for NFT market verification](https://github.com/cardano-foundation/CIPs/pull/226) **M. Àngels** -: Okay, perfect. So this is going to be merged offline. And then under review, we have two items. The first one is additional factors for NFT market verification. This is the one that we send communication to some of the NFT marketplaces to give us feedback. So I don't know if any one of you would like to make a summary for our audience today on regards of this PR? I thought it was me that I wasn't listening to anyone, but I think that... Is it me? **Sebastien** -: No, I think it's just that not be as [inaudible 00:29:29]. **M. Àngels** -: Okay. So, let's go to the comments. No feedback since my last comment. Now I do. Sorry. As nobody was speaking, I thought that I had audio issues, and I reset it. Perfect. So these are the marketplace that were approached, but I am not aware that they have provided feedback either in this court or not in the PR. I mean, in the PR there are no more comments. So I don't know if you want to wait it works more. Maybe we can try to contact the marketplaces again. So if you agree, what I think we could do is to try to reach them again. So maybe now, yes, maybe to take this back after Vasil. #### PR242 [PR242 CCIP-0050? | Shelleys Voltaire decentralization update weekly update](https://github.com/cardano-foundation/CIPs/pull/242) **M. Àngels** -: So next item of the agenda is PR 242. This is the PR around [inaudible 00:31:13] decentralization. We have a specific channel here to discuss this PR. I don't know if any of you want to give a brief summary on the status of this? **Sebastien** -: I think this one is still pending some sort of response from IOG, right? **M. Àngels** -: Yes. I think there's Kevin here. I don't know. Maybe if he wants to- **Robert** -: Just that the author has accepted the possibility that maybe there won't be a response from IOG, and is prepared to go ahead with this in one way or another, is one of the things that came out in the discussion in the Discord, the other channel. **Sebastien** -: Yeah. I mean, if there's no response from IOG, there's no reason not to merge this, right? Just because it's merged. The [inaudible 00:32:50] Cardano has implemented. From that perspective, if they feel the discussion is fine, and if they've given up hope on receiving a response from IOG, then I think we should just merge this. **Frederic** -: I would be fine with that. **Frederic** -: [Inaudible 00:33:18] same here. Just want to bring your attention to the chat. [inaudible 00:33:22] is currently here for CIP 50 and can't call in, but he's currently typing some comments. **M. Àngels** -: So I'm going to bring Kevin on stage. So maybe he can give us an update from IOG. Hi, Kevin. **Kevin** -: Hi, everyone. Nice to speak to you. Hopefully you're hearing me okay. **M. Àngels** -: Yes. Perfect. **Kevin** -: Excellent. That's great. So the story of the CIP 50 is, we've looked at this, we've evaluated internally. We think it's an interesting suggestion. We're keen to progress this a bit further. We obviously have a few other things on our plates at the moment, but we think it's a great opportunity to engage with the community and to discuss these ideas. So I won't make any commitment on IOG's behalf at this point in time, but I would make positive noises to the author. I would definitely make positive noises to the author. And as Sebastien knows, we're hoping that once we've got an opportunity, probably after Vasil, we can then start to progress discussion on this and similar issues. We think it's a great way to engage with the community. I think there's some good ideas coming out this and other- **M. Àngels** -: h, perfect. Thank you very much, Kevin. [inaudible 00:35:08]- **Kevin** -: And if I could just add, I suspect people think that IOG is ignoring all the great work you're doing. That's absolutely not the case. We have people who are monitoring the steps, going through them, looking at the ideas. And as I was saying, we obviously just don't have the capacity to progress them all at the moment, but we are taking stock of them and we will see what we can do as we move forward to the new frameworks that are being set up. Alternatives, et cetera. **M. Àngels** -: Thank you very much, Kevin. That is very, very nice to hear. **Robert** -: Kevin while you're on, do you see the last question that came into the chat? **Kevin** -: No, I'm not sure I've got the chat. **Robert** -: There's a little button in the upper right hand corner. In case you can't get it, there's just a question about the- **Kevin** -: Oh yeah, I got it. **Robert** -: Do you see it? **Kevin** -: Okay. Right. So the question is from Steuf, is that right? **Robert** -: Yes. **Kevin** -: Will I be able to access game theory? We can ask the researchers that. We have common analysis that was done internally. I think most of the game theory results are published, but I don't know whether the raw data is published. Tell us exactly what you would like. When we start to engage with you, we can certainly see what we have available. And I don't think there's any issue with sharing any of that information with the community, so this information that IOG has produced. But don't quote me on that. So to reemphasize what I said earlier, there's real willingness and enthusiasm for engaging with the community to the ecosystem and core going forward. **M. Àngels** -: Good. So next meeting, which is in two weeks, from the CF, we would like to have [inaudible 00:37:56] Ramazon to join. He is a blockchain researcher, and he will also give us his input on this CIP. Anyone else has anything to add on this PR? **Robert** -: All okay, here. **M. Àngels** -: So this is everything that we had included in the agenda. So we have left 25 minutes. I don't know if you want to review any specific PR. Rob, you mentioned one that you wanted to review. Maybe we can go to it. **Robert** -: Do you mean me? **M. Àngels** -: Yeah. I think that you shared one PR to bring into the agenda that was not urgent, but as we have time left, maybe we can review that one. Just let me go through it. **Robert** -: That was an issue rather than a PR, and we dealt with it already at the beginning. It was issue 109. We have contending discussion rather than try to fix the problems as they come up in the existing system, to try to come up with an alternative framework that's going to be a little bit easier to manage. For people that weren't following issue 109, this is the website generator that generates cips.cardano.org from the GitHub's CIP repository. And it's a bit clunky, consisting of a bunch of scripts. And Matthias had some suggestions in issue 109 about maybe using Hugo, with Docusource being a little bit too heavy. But without Matthias being here at the meeting, I don't think it makes sense to include it in today's discussion. And it's also not an urgent tissue. **M. Àngels** -: Perfect. **Sebastien** -: There's a few CIPs that haven't been reviewed yet, but are ready to be reviewed, notably 62, 66, 68. I think 62 might be a bit early for that one, because there's still a lot of things in the air, but we can introduce it for anybody interested. So this is basically, Catalyst is moving towards a system called DREPS, where basically, people can delegate their Catalyst voting power to other people. And to be able to do this in centralized way, we need to enable basically anybody to sign up to be DREPS. And we also need wallets in DApps to be able to create transactions that delegate your voting power to these DREPS for other people. This CIP defines the changes to CIP 30, which is why I mentioned previously of the Catalyst team may be interested in changing the enable function for CIP 30 in general, to make it easier for making changes to CIP 30, because they also [inaudible 00:41:26] changes to CIP 30. So, that's just that background. There's still some ongoing discussions about the right format API for this CIP, but just FYI that it's out there [inaudible 00:41:47]. No other comment or questions, we can move on to maybe 68? **Kevin** -: Sorry. Could I just say, Sebastien, CIP 62, the precursor to 62, there's already been some discussion with wallet [inaudible 00:42:16]. What we're doing first is to try to open our discussion to the community. One of the procedural questions is, what's the best [inaudible 00:42:32] to extensions to- **Frederic** -: Kevin, your audio's cutting in and out somehow. Anybody else having issues? **Kevin** -: It's Discord. Let me try again. So what I was saying is, there's been some discussion with some wallet providers on CIP 62, the proposed adapt connector. What we're doing here is to open up the discussion to the broader community and to ask for general feedback. One of the procedural points that's come up is what's the best way to provide extensions to CIP 30. So what we don't want to do is to completely replace it. What we want is a mechanism that says, you've got CIP 30, here's an extension. And in this case it's for voting, but it might be that we need extensions to CIP 30 for other purposes, too. So we want to waive, to be able to say, oh, you have access to CIP 30, but not CIP 62. You have access to CIP 30 and some new CIP, and so on. So that there's a way to basically select sensibly between different extensions to the base DApp connector. That's the question, I think, for people on this call. **M. Àngels** -: So maybe Kevin, if you want to make the question again, so the editors can answer you, if they know it? **Kevin** -: Yeah. So it's not a question we need answered immediately. We are happy just to raise it with you and for you to think about it. But one of the core questions is, when we provide extended capability to CIP 30, what is the mechanism that we should be using to enable that? So should we be providing some completely self-contained CIP? Should we be saying, oh, this CIP requires CIP 30. What if you've got two incompatible CIPs, both building on CIP 30? So it's starting to raise questions about how do you extend existing capabilities, and how do you enable interoperability? Happy to raise these questions on the PR itself, of course, just to make sure you're aware of them. **M. Àngels** -: But the... Go ahead, Rob. **Robert** -: Oh. Well, an issue came up like this with CIP 13, which is for a URI scheme. And it seemed for two or three months that there were going to be other people presenting different syntaxes into the URI scheme, and that if there was the possibility of getting more than one or two of those, it would make sense for each of those to be presented as its own CIP. So that turned out not to be necessary, but we were prepared to have the individual authors for each of those extensions to the URI scheme, submit their own CRP explaining it in detail, so it wouldn't have to be coordinated or accountability or advocacy for this CIP wouldn't have to be shared with the original authors of CIP 13. So I think that this is one of those cases that would do well with that approach, as well. **Kevin** -: Yes, we're absolutely happy with that. This is more of a technical question about enabling the extension. So, how do you enable the extension consistently in the API? So there needs to be some discussion about that. Sebastien can probably comment on this, but you can imagine having, say, CIP 62 and CIP 63, which both provide extensions to CIP 30, but which are mutually incompatible. And then you need to have some way to say, I can support CIP 62, but not CIP 63, or I can support CIP 30. There actually has to be a way for the user to select between the different capabilities in a consistent way. Let me make sure that question gets raised properly as a comment on CIP. **M. Àngels** -: That would be fantastic. Thank you very much, Kevin. So shall we move to CIP 68? I think you mentioned, Sebastien, that this was one that was worthwhile mentioning. **Sebastien** -: Yeah. So basically with the introduction of Vasil, it's possible to mimic global estate for a smart contract, but basically having some UTX entry that holds some special NFT be denoted as the UTX entry that contains the global estate of the contract. This CIP, CIP 68, is basically a standardization for this exact feature, with some emphasis on NFTs, but also not just for NFT. **Sebastien** -: The interesting about their proposal is that they want to have a single minting policy that handles everything. So instead of having one minting policy for the global estate NFT, one minting policy for the actual NFT series, if this is an NFT mint, and then one NFT for other standards, or sorry, one script for other standards, they all want to have all of this handled by a single script, all in one script. And they document how they would do this with all in one script, by basically stuffing information into the asset name, which as you may remember, asset name on Cardano is just the arbitrary binary strain. So they can [inaudible 00:49:12], they want it there as sort of standard. That's basically the idea of the CIP. The downside of doing this is one, of course, you need to have one master minting script. It maybe kind of awkward to deal with, especially if new standards come out in the future, you can't support these new standards with your existing antique projects. **Sebastien** -: And the other thing that's awkward about this is the cost of the approach. The approach line described in the CIP is also extremely large. And then last thing [inaudible 00:49:55] Fred mentioned is that also this reduces these amount of space you have for asset deeds, because it adds a pretty big [inaudible 00:50:05]. These are the three core issues with the CIP, but I don't see any technical issues with the CIP as it's described. Obviously there's some practical issues that may mean that people may not want to take this approach. And actually, if you're interested in a separate way to tackle basically the exact same problem, you can look at CIP 56, which is by end maker, which is a proposal for DIDs on Cardano. But actually the approaches for DIDs is another alternative structure that's kind of like, I wouldn't say a competitor, but an alternative to CIP 68 that we're looking at right now. **M. Àngels** -: Any comments on this one? Shall we bring any of these two last PRs to the next meeting agenda? **Sebastien** -: Yeah. **Robert** -: Yeah. I think that sounds great. These are things that I'd like to hear from Matthais about. The last couple of them are technically, I can't really contribute anything about them. I'm sure that he could, though. **M. Àngels** -: Perfect. We have 12 minutes left. Do you want to review another one, or do you want to go directly to a wrap up and close the session? **Robert** -: I'm okay with wrapping up. **M. Àngels** -: Perfect. Any one of you want to do the closing? If not, I have notes on the PR and I can do it myself. **Frederic** -: One check on for request 263, the conflicts have been resolved. Sebastien, if you want to add your take on this one and nudge it, I think we're good to move it forward at CIP 54. **M. Àngels** -: Nice. **Frederic** -: Good to close, otherwise. **M. Àngels** -: So if you like to merge it online, that would be great. **Frederic** -: Sebastien, do you want to do it? **Robert** -: Oops. I- **Sebastien** -: Yeah, if they're not interested in making changes of their functionality based off the Vasil hard work, then I don't see any problem merging it. Worst case, they can just come in and modify their while we merge the IP later. ### Discussions N/A ### Issues N/A ### Close **M. Àngels** -: Okay, perfect. So let's do a wrap-up of the session today. We have briefly mentioned CIP 58, Biblase Primitives, but we have decided to wait until we have Michael Paton in the call. We did the review of broken links on the website that we are going to leave this discussion offline. We have reviewed two PRs related to CIP 30, duplicate signed transaction and chain signing, and adding optional network ID parameter to enable. Both of them are on hold, because we are waiting on a governance process on CIP 30. Then we have PR 263, Cardano smart NFTs. It is the one that we have merged now online. This has been approved and merged during the meeting. We have CIP 50. We had Kevin on stage, and he has mentioned that the IOG is really willing us to engage with this PR and this is probably to be done after Vasil hard fork. And if they have not engaged it yet, it is for a lack of capacity. I would like to thank Kevin for his intervention today, it's very much appreciated. Then we have reviewed CIP 44, additional factors, NFT market verification. This one, what we are going to do is to think again the marketplaces and try to get their feedback. And then we have reviewed CIP 62, governance API for that connectors dot wallet web bridge. And Sebastien has walked us through this PR. And Kevin has raised a question regarding how to extend the capability of CIP 30. And this question is going to be added to the PR itself, and the editors are going to review and go back to Kevin with an answer. And finally, we have reviewed CIP 68, data metadata standard, where Sebastien has walked us through the PR, and we are going to keep this CIP 68 and 62 for review in the next meeting. Thank you very much all for attending. A special thanks to Kevin, that has shared his view on state. And well, next meeting is going to be held on August 2 at half past 8:00 AM, UTC. I'll be on holidays, so my colleague Anthony Mayer, will take over. And I wish you all a very great summer, and see you after the summer. Bye-bye. **Frederic** -: Bye-bye. **Robert** -: You too. Bye-bye. ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-08-02.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 02 2022 Transcript](#august-02-2022-transcript) * [Triage](#triage) + [CIP-0027? | Fix status header](#pr214) + [CIP-0030? | Added walletExperimentalApiVersion](#pr225) + [CIP-0045? | Decentralization: Using Pledge as a Bidding Param](#pr229) * [Last Check](#last-check) * [Review](#review) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) + [CIP-0062? | Governance API for dApp Connectors (dApps<->Wallet Web-bridge)](#pr296) + [CIP-0068? | Datum Metadata Standard](#pr299) * [Discussions](#discussions) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 02/08/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## August 02 2022 Transcript **Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, ~Robert Phair~. **Guests**: ~Morgan Thomas~, Michael Liesenfelt ### Triage #### PR214 [PR214 CIP-0027? | Fix status header](https://github.com/cardano-foundation/CIPs/pull/214) **Matthias** -: Yes. So we're looking into that one. It's a pretty old one, I think. Yeah, ninth, February. It was just changing the status of a CIP number 27, which I think is... And debated here, not the CIP, but the fact that this is an active CIP nowadays, there have been people disagreeing with that standard and coming up with new standards, which is also fine. But as far as we are concerned, it's indeed active. So there is no problem with the change for me. Robert has approved. The only thing is we will also need to update the top-level README, with that to reflect it. So we can do this as part of a recent PR updating the README and yeah, just get to move on with this particular one, unless you, I don't know, have something to say Sebastien. But- **Sebastien** -: No. #### PR225 [PR225 CIP-0030? | Added walletExperimentalApiVersion](https://github.com/cardano-foundation/CIPs/pull/225) **Matthias** -: Nope. So let's go. I'm just merging that and I will do the README update in the other PR, which is PR #311, just for the record. And okay, next one, also a quite old one. CIP 30 Wallet experimental API version. **Anthony**-: Okay. Apologies. Sorry. I'm behind you. All right. Excellent. Let me just launch this one up here. **Matthias** -: Let me also watch the stream. Yeah. Well I guess that's one of those lingering CIPs for which we have no news from the author, probably came from a discussion. They made a change to the CIP 30, I think Sebastian response is... **Sebastien** -: Yeah. Because the problem with this one is that the way they're doing it is different from the way Eternl did this. **Matthias** -: Yeah. **Sebastien** -: So somebody needs to decide how they want to resolve this mismatch. **Matthias** -: So do you think we should pull Marcel in the discussion or- **Sebastien** -: Yeah. We can try and ping them or sell it to them and see if they want to resolve this or if they want to drop the CIP. They need to figure this out. **Matthias** -: Yeah. I mean, since there has been no activity for four months on that one, I would assume it's probably being dropped. So I would just ping, Ruslan and maybe Marcel to see if they have anything to comment. **Matthias** -: Okay. And I will just mark it as waiting for author. **Anthony**-: Amazing. Excellent. So is everybody happy to move on to CIP 45? **Matthias** -: Yes. Yes. Now just make sure we keep this CIP 30 update for last check, maybe next meeting. And if no activity has happened, then we'll just I think close it. **Anthony**-:Okay. Excellent. I'll do so. Great. Thank you, Matthias. #### PR229 [PR229 CIP-0045? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229) **Matthias** -:So CIP 45. Yeah. So I had a quick look at this one this morning and also at the forums messages. So this is yet another CIP to address incentives, rewards, and things that are in that realm, specifically focused on the pledge, Stake Pool pledge that one. So it sounded a lot similar to a CIP that was discussed in the past, which was the dynamic saturation based on pledge. So the idea of CIP 45 is to make the pledge for pools also dynamic in a way, and depends on the actual number of ADA being stable, the circulating supply, and that way make sure that both the pledge and the saturation levels kind of reflects the actual state of the network. So I haven't been through all the equations just yet, only been through the comments on the forum. **Matthias** -: So yeah, I think it's a good one to put under review as well. And I would be interested to see a discussion comparing that with CIP 37, and how they do defers on that. I'm pretty sure both authors know or that the two proposals exist, if they don't and it's a good thing we put them together maybe for a chat as well. **Anthony**-:Okay, excellent.So... Apologies. So from my perspective, this is something that's going to be placed under review. **Matthias** -: Yeah. I've been also quite late to address that one in a way, because I see it's been published on the 1st of March, so it's been sitting there for quite a bit, might be a bit of effort to resurrect the conversation, but I would definitely yes, love to spend some more time to go through this one point by point, maybe have a kind of comparisons of that with CIP 37. I'm not sure if you had time to go through it, Sebastien, if you have any remarks as well on this one. **Sebastien** -: No, I don't actually. And do you know why this one was missed for so long? Did we talk about this? And then there was a reason why we lost over it. **Matthias** -: And I think it just got lost in translation, slipped through the cracks. So I don't know. That's the kind of CIP we also wants to get IOG attentions about, and we know it's been a difficult task. We could probably also pass it through Reza at the CF, who is also now getting to more and more into looking into these things, just at least to get some research feedback on this. And I will also ping Kevin Hammond about that, who is now our point of contact with IOG and our best chance to get something through IOG research. **Matthias** -: I'm not sure if Michael also, who is here today, you have seen that there is some overlap with CIP 50, as far as I can tell. Both could be complimentary solutions. Not sure if you have seen, or if you had time to also read through that? **Michael**-: I need to refresh myself on it, but I did. I might have even cited it in my references of CIP 50. **Matthias** -: Okay. So nothing really substantial, but you are aware that this exists as well. Well, at least now you are. **Matthias** -: Okay. So yes, let me try to ping also people on that. **Matthias** -: So the next call would be on the 16th of August, right? **Anthony**-: Yes. **Matthias** -: Yes. **Anthony**-: That's correct. **Matthias** -: So I'm just commenting that we'll like to do a more of an in-depth review for the next biweekly call, August 16. That it'll be good to have a comparison with CIP 37. **Matthias** -: Can I ping the right people or what? Yes. **Matthias** -: Okay. **Anthony**-: Okay. Fantastic. **Matthias** -: Okay. So that's it for this one. Let's have it for review next week. **Anthony**-: Okay. ### Last Check N/A ### Review #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias** -: Sorry. In two weeks, in the next call and maybe let's start with CIP 50 now, since we have Michael and Christophe with us. So I did put a small update from what I got from the Discord chat, or there was few thread discussions, but from what I could get is there was this idea that if we end up doing a model or actual simulations of that particular model, it would be nice to use some kind of either genetic algorithms or neural network to try to model a bit more complex behaviors of the different actors, all players, in that sense in the whole simulation. There was also in the meantime, a response shared by IOG research and was specifically Aggelos and Christina, with some well comments on CIP 7 and CIP 50 in particular. I think there are some comments on these two. And I think Michael, you suggested to maybe do a point by point kind of response to address various claims that have been made and try to point to either the inconsistency or disagreement in particular with the interpretation of the CIP 50 proposal. **Michael**-: Next action item, maybe to open source what they actually have. **Matthias** -: Yeah. So we could perhaps ask for maybe not a deadline, but at least an estimate or something along those lines. When could we expect to have this particular simulation engine, because yes, that response is mentioning a new simulation engine that they have been using to compare these solutions to the existing protocol, which is planned to be made public, but still hasn't so far. So it would be good to get some... How would you say? Some view on that, just to know when we could expect this to be available to play also. So that's a good point. **Michael**-: Clear that their new simulation engine is deviating from the original RSS publication paper simulation engine. The figures of merit have changed. Some of the methodologies have changed. They're updating and they're learning from CIP 50, which is good. **Matthias** -: Okay. So some positive notes still. **Michael**-: Yeah. On CIP 50, we are formulating a section on a recommended ranking equation. Marcel has shared what Eternl uses, we've considered a couple of others and it's not a binding part of the specification, but rather an advisory recommended section, but we figure it's important to include. Also in development is potentially another three equations that could be tried as part of the equation competition, so to say, with variable leverage. And so instead of a fixed constant leverage to have egalitarian and bias forms of the equation that have a reducing leverage as increasing as pledge increases, we're still considering adding those as well. **Michael**-: So the more pledge you have, the less it gets you in terms of total stake size that could help address the idea of pool moguls or a pool emperor emerging. But one won't know that until simulation is actually being applied. And then of course, there's vigorous discussion on many aspects of CIP 50 in the discussion channel. And we're updating all of the figures and charts to reflect a reality that after the saturation point, there is not truly a diminishing return because individuals can split pools and continue the returns. **Matthias** -: Okay, which actually would affect a bit some of the strategy. I think this was something that was a bit mentioned before, that with the CIP 50, there is an actual optimal point of pledge beyond which you want to actually split your pool to maximize your returns. **Michael**-: Well, there would be a limit. So the design would be to be the "optimal" is as much as you have up to the limit and then as much further pledge as you want to contribute to make your pool more relatively attractive and lower leverage, that would be the concept. **Matthias** -: Okay. And so that limit would be below the saturation limit and like now, right? **Michael**-: Yes. It would always be a fraction of the saturation limit proportional to the leverage limit, but the scheme doesn't limit from putting more pledge than what would be required to maintain a saturated pool and the factor there isn't technical, but mainly social around pool ranking and perception of pool leverage in a ranking equation or an ecosystem of competing pools. **Matthias** -: Okay. I'm just thinking about something, which is just a wild idea to maybe test social behavior as well. But we could imagine having a ranking formula that is based on CIP 50, and see if you can get some buy-in from existing Wallets, for instance, to display that ranking and the potential rewards for different pools as if CIP 50 was implemented sort of to start getting an idea of what it would mean for that CIP. You can showcase this one under CIP 50, would be expected to have this ranking and earn this particular amount of reward. Maybe that would make things a bit more concrete for people also. **Michael**-: Yep. That's part of what's in development under a sub topical thread of the CIP 50 PR discussion here on this Discord. There's been a couple of screenshot images shown of almost exactly that, but as I mentioned, I think we're still under development with those ideas and not ready for inclusion yet. **Matthias** -: Okay. Okay. Good. Good. I somehow missed that from the discussions. **Michael**-: Yeah. The sub threads auto archive after 24 hours. So you might have to scroll back and find it from the main PR discussion topic. **Matthias** -: Yeah. Yeah. I think I see it now, these pool ranking work sub threads on... Yeah. There are 30 different messages in there which I missed. Okay. Then I will try to go through that. Also bring that back to the GitHub issues just for the sake of sharing. Okay. **Matthias** -: Anything more on CIP 50 from your side? **Michael**-: Apart from updating all of the charts, I also have a thought that I haven't implemented yet that I should include charts, not relative to the delegator yield, but relative to the pool owner operator yield. And so that would be an additional few charts that would show their return on invested capital that I think is Prometheus pool correlate has done a great criticism and job showing that those charts and those relationships are important relative to the owner. And I agreed that those charts could be included, but haven't yet. And so I think that could be wise to do. **Matthias** -: Thank you. **Michael**-: Because the Cardono as a whole, isn't just optimizing the reward equation for what the delegators earn, it's also trying to ensure that the relationships for yield or the operators are also aligned with what we want decentralization to be. **Matthias** -: Well, I think that was actually the primary goal of the RSS paper originally, not to maximize rewards for people, but actually to incentivize to reach that `k` parameter - the optimal number of stake pool. The reward is just the incentives or the means by which we reach that equilibrium point. But I think the end goal has always been reaching that equilibrium point. **Michael**-: True. That gets into a very deep philosophical discussion of whether you can use central economic planning to bias the network to a goal target number, a goal target rate, a goal target yield, a goal target count. Obviously the original IOG perspective is that they can, and the K parameter can do that. And so that bias and central planning number works, but the equilibrium point has now become about 10 times less than intended. **Matthias** -: Yeah. That's the thing. **Michael**-: Yeah. So then it gets to the philosophy of for the values of Cardano, do we want to have a centrally planned system or do we want the system to become the best version of itself, find its own equilibrium without bias? **Matthias** -: No. I mean, it's always been an interesting discussion to see that. You want decentralization, but not too much, because there is this `k` that dictates you how much decentralization we tolerate for the system, which I think is also to correlate to the actual networking side of things, because the system that is too decentralized might also have a problem propagating blocks and getting the job done. So I think that's why there is an actual optimal `k`, kind of that is currently being fixed by one party, which also happened to be the party developing the networking stack because it's all a proof of stake system in the end. The network working is way more complicated than it could be compared to a proof of work system. **Matthias** -: Because there are tons of assumptions that you cannot make and you have those actual hard limits on the block propagation; I mean, how much of the networks needs to reach consensus within a certain time window, which means that in practice, you can't probably reach a point where you have 10K different block producing nodes. I mean, I'm just shooting numbers here. Don't quote me on that. But there is definitely an optimal number from an engineering perspective. And then there is an optimal number from a social perspective also, and we kind of have to find the right balance between the two. **Michael**-: Yeah. We're hoping that... I'm personally hoping that with some of the peer to peer technologies, the number of network supported relays under the block propagation threshold is increased by hopefully an order of magnitude, maybe two, such that the network capabilities are much more than what the equation is set up to do. That's my hope. I think we're starting to see some evidence that that might be maturing and growing as more peer to peer nodes are adopted on the network. But I agree that could be a problem if you don't have peer to peer. If you do have peer to peer, the ceiling might go up by an order magnitude. And then I think if we unlock the centralization, then what we might have to do is make sure that any network consensus and block propagation stays half an order of magnitude to an order of magnitude, more capable ahead of where the actual community is decentralized to. **Michael**-: And one of my buddies, Rob, he recently got into this space, he's... There are global consensus mechanisms that scale, even another couple of order of magnitudes beyond which could be considered on an engineering side. Much more complicated, but they're used for things like synchronizing the video of a super bowl or world cup across thousands of data centers globally for a live broadcast, for example. So they exist, other people who are using these technologies on the internet to do global scale consensus, but we might not need to adopt them to enhance a fledgling peer to peer yet. **Matthias** -: Yeah. And I mean, I guess there's also questions of how many of those scheme are also Byzantine resistant and fault tolerant because that's kind of the point here. We don't just want a consensus, a distributed consensus algorithm, we want one that can resist attacks of various kinds, but that's both an engineering problem and a political problem at the same time. So I mean, I think there are explanations as for why there is a `k`-parameter today. So sort of my point, would that be needed once we have peer to peer enabled? Maybe not. That's kind of the hope. And as you say, let the system auto-balance itself and find its equilibrium regarding decentralization and what's the right amount of decentralization? **Michael**-: To become the best version of itself. **Matthias** -: Yes. Let's maybe quote that under the CIP title. **Matthias** -: Okay. So let's keep the discussions going also and have CIP 50 back for review next week. We haven't got any updates from IOG, think they have been busy with Vasil with some of the recent problem and bugs found. So I haven't heard of Kevin on that. I think Christophe mentioned that he... I mean Kevin said something recently online on the 360 or something like that, but it was nothing really substantial, just that they were looking at it. They were aware that it existed, wanted to well provide also feedback. We'll still a bit waiting on that sentence. So let's see next meeting. **Anthony**-: Amazing. Great. #### PR296 [PR296 CIP-0062? | Governance API for dApp Connectors (dApps<->Wallet Web-bridge](https://github.com/cardano-foundation/CIPs/pull/296) **Matthias** -: CIP 62 is next in line, right? **Anthony**-: That's correct. **Matthias** -: I've been trying to click on the link for 15 seconds and I just realized it was a stream. One can't click on a video, obviously. Anyway, governance API for DApp, which was proposed by Bruno Martins, who is now the tech lead regarding Wallets at IOG if I recall correctly. And this is a proposal to extend CIP 30 with capabilities that would make that voting process a bit more streamlined. Sorry, I did a first run of review on that one this morning and mainly suggested to simplify a bit some of the methods in particular to make things a bit more orthogonal, meaning not to have the API provide five different ways of doing the same things or in that case two different ways. **Matthias** -: And I'm also asking for a rationale section mainly because, we need a rationale section for any CIPs in general, and because that gives the bases for discussions and that explains, at a later time, why the decisions were made, the context within which they were made. And for that one in particular, because there are a few suggested API or endpoints, you could say, or interfaces, that can be done currently through existing libraries and I don't see why adding them to the bridge, the wallet interface so to speak, makes sense. Or at least there is no justification for it. I can get that it's maybe a bit more simple and that removes some of the burden from the apps implementing that, but those apps are mainly Wallets anyway. So that was a bit some form of the gap in the justification here that I'm liking. I don't know, Sebastien, if you had a look at that yet. **Sebastien** -: No, unfortunately I was hoping to look into it today, but as you may have heard, there's other stuff that came up. There's still some discussion going on internally related to the CIP, so stuff may still change, but definitely it's good to over it. I agree that it's probably over complicated the way it's testified now and I'll try and find some time to give my thoughts on this. **Matthias** -: Okay. Because my main understanding on this, or I mean, experience that's... I mean the catalyst voting in general, it's always been done by wallet implementors themselves; [Inaudible] So I don't quite see the need for an external API for that to let any DApp do the registration themselves. **Sebastien** -: Oh, so the reason for this is because they want to have this de-rep system. So basically anybody can propose themselves to be a representative for catalyst voters and you can delegate your aid out to this representative. Similar to stake pools, there needs to be some sort of stake pool viewer just like there needs to be some sort of de-rep reviewer. So there'll be websites that are made for this. And then some of these dealers may have their own website with a click here to delegate me on all those kind of interface. So the motivation for this is almost only the direct feature. **Matthias** -: Okay. So, then I don't get the API cause a lot of the API are- **Sebastien** -: Yeah. **Matthias** -: It's leveraging key derivation path, which suggests that the key belongs to the Wallet and not to some delegated- **Sebastien** -: Yeah. I think this is a mistake. It should be like other standards where you start with zero and then if zero is huge to get one and the Wallet handles this, I think. Having the debt analysis is going to be a huge disaster. **Matthias** -: So okay. Definitely a need for some of the motivation and rational. So I've already flagged that on the PR waiting for some comments now on this. Yeah. So I guess we can just leave it there for now. If we have any of update from the author before the next meeting, we can discuss that again in the next meeting otherwise, I just wait. #### PR299 [PR299 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/299) **Matthias** -: To do. Next one on the agenda, CIP 68. Datum metadata standard, which comes as a replacement or an iteration on the existing metadata standards. But this one aims to be a bit general, although the specification is also focused on NFTs at this stage because that's the main use case driving that proposal. **Matthias** -: The main spirit as for... I think the main rationale as for why put a metadata in the datum instead of in the transaction is because you cannot access metadata of the transaction as part of your Plutus script, which is a little odd. And it truly sounds like at a political issue, at least the transaction metadata and the datums have become kind of redundant with one another. So having access to the metadata inside the script allows for some extra validations to be done in particular when moving NFTs around. **Matthias** -: Without access to that, your scripts are basically blind to what happened, which makes it very hard to just update metadata, for instance, if that's ever needed. So I think that's the core motivations behind that CIP. Beyond that the structure is kind of similar to what was already proposed for the NFT standards, except that it's fully accessible from the script's context and something that is meant to be provided as datums, so Plutus built-in data, and possibly interpreted as JSON once again. And well, that's about what I have for now on that. There have been a lot of discussions on it. I admittedly, didn't go through all the comments yet. Sebastien, I see you've been a bit more active than me on this one. So maybe you have some inputs as well. **Sebastien** -: Yeah. So for this CIP, as you mentioned, is kind of a solid, better version of 25. The problem of 25, of courses is that I have to rely on this initial mint transaction and there is no guarantees that this is the actual mint. This one is slightly better, but still has the same issue, which is that now it's including stuff as part of the asset name. And now you have no way to know if the asset name is really by design or if this was a smart contract where users got to pick the asset name, this is a bit rarer of a situation. So it's slightly better. I still think it's slightly problematic. Personally, I prefer the option that [inaudible 00:44:11] maker came up with. So if there's another CIP that's the DID standard for Cardano and inside, they did standard. They did something very similar to this metadata standard, except they added another layer of indirection to avoid having to have the asset name stuffing, which I think is probably the better approach, but all things considered, I don't think there's anything wrong with CIPP the way it stands now. Obviously there's some issues with it as I mentioned, but if people use it, understanding of these issues, then I don't see anything wrong with it in particular. **Matthias** -: Okay. We haven't really looked at CIP 66. So this DID standard proposed by the team, which might be good then to bring on the table, at least in the next meeting or next to the new metadata discussion, especially if they have some conflicting opinions on these. **Sebastien** -: Yeah, I think there were three PRs with conflicting implementations of this many data standard. So there's the metadata standard for us as the end maker one. Then there's a third one that also had something similar. I don't remember. **Matthias** -: Well, there was on chain metadata proposed by this web team a while back, but I think this one got... **Sebastien** -: Cardano Smart NFTs. **Matthias** -: Oh no, that was yet another one, the smart NFTs. The smart NFT were about embedding actual codes on the blockchains that makes those NFT... I mean, that's an API for those NFTs to be embedded. Speaker 4: Right. And they want the way to upgrade these... **Matthias** -: Yeah. To make them programmable and interactive in a way. But there is some overlap maybe less than with CIP 66. Okay. So that would be important to mention and to see if we can get maybe both offers to discuss where there is no problem in having two different proposals. That's always a pain down the line. So platform that need to implement both of them as that both gets really adopted. So we might as well want to have only one. So I'll mention that on the request. **Matthias** -: Let's put the link. **Matthias** -: So I will suggest you have maybe a discussion with the two authors as part of the next CIP biweekly, if they can both make it, that would be great. Just to compare trade off and see if there is perhaps one that should prevail over the other. **Matthias** -: Yeah. And well, that's kind of it from my end. So I guess we can finish things up now. **Anthony**-: Excellent. Thanks. Thanks Matthias. That's great. **Matthias** -: Yeah, I'm just finishing up a comment on CIP 68. I can do a small summary of the session after that. No problem. Just trying to get the handle for the author. ### Discussions N/A ### Issues N/A ### Close **Matthias** -: Okay. So back to the meeting and the agenda. So we've been through, well CIP 27 of the status of the exchange with move it to active. **Matthias** -: Then CIP 30, there was the discussion of adding a Wallet experimental API version to it, which happened while back has been idle since. There was a suggestion from Sebastien a while back also to use the Wallet name, to address what that particular suggestion was about. So waiting for the author and we'll close it in the next biweekly if there is no update on that one. **Matthias** -: CIP 45, which is another proposal that tries to address the pledge/incentives issues on Cardano. We somehow completely missed that one in the past because it's been there since the 1st of March. So we're trying to get back to the author now and see if we can spark back the discussions on this. We reflect this to you as well, to see if we can get that into their feedback pipeline. **Matthias** -: We'll discuss also updates on CIP 50, mainly related to the recent blog posts that were shared by IOG and the research team. A few action items on that being, make a response to those blog posts and as well, update some of the graphs to take a slightly different perspective. Then what we currently have. And there was also these discussions of maybe trying to make some of the data available to wallets or applications, which also happened on this call as well. We discussed briefly CIP 62, which is an extension of CIP 30 to add methods regarding the catalyst voting registration. It wasn't clear as for why one would want that as part of the CIP 30, that connector. And so if like that, asking for a rationale or some justifications from the original author. **Matthias** -: And finally CIP 68 regarding the datum metadata standard, which comes as a replacement of CIP 25, there seems to be some overlap with CIP 66. They have both different, slightly different trade offs. So we are suggesting to have a discussion between the authors of the two CIPs and so have that your discussion next week. And that's about it. **Anthony**-: Excellent. Thank you, Matthias. **Matthias** -: Yeah so- **Anthony**-: Anybody else on the call, is there anything that you'd like to discuss or add on or can we complete like that? **Matthias** -: I think we're good. So thanks everyone for joining and Michael for speaking and updating us also on the CIP 15 and see you in two weeks. **Anthony**-: Great. Thank you everybody. Bye. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-08-16.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [August 16 2022 Transcript](#august-16-2022-transcript) * [Triage](#triage) + [CIP-0051? | Preserve submitter's ordering of transaction inputs](#pr231) + [CIP-0048? | Extended 721 metadata](#pr249) * [Last Check](#last-check) + [CIP-0030 | Added walletExperimentalApiVersion](#pr225) * [Review](#review) + [CIP-0045? | Decentralization: Using Pledge as a Bidding Param](#pr229) + [CIP-0050? | Shelleys Voltaire decentralization update](#pr242) * [Discussions](#discussions) + [CIP-0068? | Datum Metadata Standard](#pr299) + [CIP-0066? | NFT Identity](#pr294) + [CIP-0060? | Music Token Metadata](#pr307) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 16/08/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## August 16 2022 Transcript **Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. **Guests**: Christophe Garant, Michael Liesenfelt, Andrew Westberg, Alessandro Konrad, Thomas Vellekoop ### Triage #### PR231 [PR231 CIP-0051? | Preserve submitter's ordering of transaction inputs](https://github.com/cardano-foundation/CIPs/pull/231) A technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused. #### PR249 [PR249 CCIP-0048? | Extended 721 metadata](https://github.com/cardano-foundation/CIPs/pull/249) A technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused. ### Last Check #### PR225 [PR225 CIP-0030 | Added walletExperimentalApiVersion](https://github.com/cardano-foundation/CIPs/pull/225) A technical issue resulted in this discussion not being recorded. Please review the CIP summary under Close. Apologise for any inconvenience caused. ### Review #### PR229 [PR229 CIP-0045? | Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229) **Matthias** -: CIP 45 seems to incentivize pools to create, oh sorry, stake pool operators to create many, many pools by giving them an optimal pledge to follow and is wrongly making the assumptions that one pool equals one individual. Whereas in practice, we know that to be untrue, there are several groups that are run by single individuals, and therefore many of the assumptions of the rationale from that CIP crumbles a bit from that. So I haven't read yet through the comments that the author has made on that, but it seems that those points are being considered at least. **Matthias** -: There are also a few suggestions purely on the form itself, mainly that this, the CIP contains quite a lot of equations and visualizations, which are so far linked through an external Google drive as images. So I suggested the author to actually use the new latest support from GitHub that landed some months ago to actually display equations directly in GitHub, or at least to use an image, but hosted next to the CIP itself, that will simplify a bit. And the author has acknowledged those points and said it would be working on updating that according to the suggestions. So some more to come, I guess. **Robert Phair** -: As far as using the equations in CIPs and in GitHub content, the difficulty they ran into with another CIP 50, did they ever work out the presentation of LaTeX type equations on the mobile platform? Someone said they weren't working. **Matthias** -: So there is only Christophe on the chat commenting that. Yeah, they have done equations on GitHub, prone to some issues as you learn from CIP 50. So you are saying it's specifically on a mobile device, that it is not supported yet? **Robert Phair** -: That's what I think Christophe was saying. **Matthias** -: Which is probably okay. I mean, if you are reading a CIP of that magnitude on a mobile that's, I mean, you're pretty brave I would say. **Robert Phair** -: I get it. I hadn't thought of it that way. They could go back to the original form if they want to see that kind of detail in the equations. **Matthias** -: Probably, it looks good in VS Code and Jupyter Notebooks, says Christophe. But then in GitHub, some stuff can't render, I guess. And it does not render on mobile. I can't speak if, yeah, not, actually, since you are here, it'll be faster than just writing on the chat. Can we just unmute you. Yes, it's done. **Christophe** -: Can you guys hear me? **Robert Phair** -: Yes. Hello? **Christophe** -: Oh, Hey everybody. Yeah. So as I learned in CIP 50, yeah, the mobile definitely doesn't render, but then there's some brackets, especially curly brackets that doesn't render on GitHub even on desktop. So that's why we reverted back to basically screenshot equations from external source. Pictures. **Matthias** -: Is it a problem from GitHub specifically, or is it MathJax in general that is just- **Christophe** -: No it's specifically GitHub and I did some digging and I don't know, I guess the layman's interpretation, it was something with like Java... Sorry, I just got a call. JavaScript rendering on the website itself with GitHub. And there were some conflicts and it seems like a mess, but it'll look good in VS Code and even Jupyter Notebooks and just regular [inaudible 00:04:25] it's fine. But when it's in GitHub README, it breaks. So you have to add some extra back slashes and curly brackets and yeah, we eventually just reverted back. For simpler equations, it is probably okay. But for more complex things, it breaks it seems. **Matthias** -: Okay. Yeah. I mean, it's a brand new feature, so that's not yet fully ready I imagine. Although it was shipped, but yeah. Okay. I think the equations in CIP 45 are a bit simpler than those on CIP50 or at least I was able to render some of them quite easily, but I haven't tried to render all of them, arguably. So there are some more complex equations below after that. **Christophe** -: Yeah. If it works great, but yeah, just be prepared to check. **Matthias** -: Yeah. Okay. Is, by the way, do you or, and I see we have also Michael here, have any comments on CIP45? More on the content of the proposal and how it reflects to CIP 50. There is some kind of overlap, but it's definitely taking a slightly different route or at least just focusing on the pledge parameter here. **Christophe** -: I personally haven't reviewed it, but now I will. I wasn't that aware of it so... **Matthias** -: Good. That's why we have the meetings then. **Christophe** -: But I'll do that. **Matthias** -: Yeah. Maybe we can move it to review for the next meeting again, just to let people have time to go through the content. It's quite, I mean, the overall idea is quite simple, but the details as always, right, the complexity lies in the details and some of the equations are not quite obvious. So it takes a bit of effort to process. **Robert Phair** -: Michael, this is a time one that I got you to chime in on the forum about, you made a comment there. So I think it is one of the ones that you've seen. **Michael** -: The notes. I was looking at a couple of those and there was that I believe it's CIP 37, this one, 45 and I guess 50, that is all with pledge and the centralization metrics is concerned. It's very, well, it's hard to go through you, you'd expect so. [inaudible 00:07:03] so I don't know, I wish I could give us [inaudible 00:07:04] and maybe there's a way that we can bundle them, simpler path to a review. I don't remember its particularities on the whole. **Matthias** -: The way I see it currently is, we have CIP 50, where most of the [inaudible 00:07:22] discussion really happens, which is probably the most structured of all those proposals that we have at least in terms of the [inaudible 00:07:30] operations, if I can say, or how the feedback is incorporated in the CIP. So all those other CIPs that are kind of overlapping, but not exactly the same, are they think the same issues as CIP 50, I think they should be part of the same discussions because they all have a similar set of assumptions. And they all have a similar set of outcomes. The question is now, which one are we going to adopt in the end? So if there is a more generic discussion happening on this decentralization concern, we want an incentive on [inaudible 00:08:07]. I think it's best driven from CIP 50 and includes feedback or update from all those other side proposals that happened. **Matthias** -: I think this is a bit what Michael is also saying in the chats, by saying "I've included CIP 45 in the CIP 50 references since the first draft". And I think it's good to keep that as part of this, the discussions, because in a way it's part of the whole same discussions. And as we are now trying to get more and more attention from IOG research, I mean, we're not going to have that discussion five times, one for each of those CIPs, but probably once and for all, at least for the next proposal to come and see which direction we take. **Robert Phair** -: I've also suggested to the CIP 45 author that he come into the discord on the CIP 50 channel, and to review what's already happened and to explain to others that have been following the issue for their issue, how his presentation is different and similar. **Matthias** -: Yeah, so perhaps that's also kind of, I don't know, part of CIP 50 rationale section, they have a kind of alternatives considered and list a bit of the pro and cons of those various other CIPs and why maybe what was taken from them, what was rejected from them for which reason, because it might actually also have discussions and having one place to centralize all the results there might help too. **Robert Phair** -: Just quickly. Might there be a benefit to changing the name of the PR 242 discord channel to decentralizations DIPs to encourage a more general discussion like that? **Matthias** -: Perhaps, but then I would suggest more rewards and incentive rework because I mean, decentralization is of a consequence of that, but this is really about reworking the rewards and incentives of Cardano and how do we currently define stake polls, rewards and all of that? **Robert Phair** -: Yes. **Matthias** -: Any comment on those points? Is that no? **Robert Phair** -: You saw when you, at the [inaudible 00:10:43] when you looked over that there was a suggestion that the MAC addresses on the machine might be considered relevant to the point of CIP 45. And I've suggested that maybe that should be moved off to the Cardano forum and kept out of this CIP 45 discussion on GitHub. I believe it's irrelevant to the CIP as stated and, I think the rationale for doing that is not correct. **Matthias** -: Yeah. I need to read through that comment a bit more in detail. **Robert Phair** -: Anything regarding the MAC addresses and how the MAC address could be used to further the ambitions of that CIP I think can be skipped over in considering the CIP. It's been a digression. **Matthias** -: Okay. So let's have it on the next biweekly that would give people some more time to go through it and hopefully a bit of time for the author to address some of the points that we mentioned. Okay. No comments. So moving to the next one. So we have CIP 50 on review here, but I would like to jump actually on CIP 68 and CIP 66 first, since we've been talking about CIP 50 for pretty much every past meetings. And I would like maybe to keep it for the end more as a closure kind of discussion if people are okay with that. **Anthony Meyer** -: Yeah. That works for me. **Robert Phair** -: That's fine. #### PR242 [PR242 CIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias** -: Or US friendly. So, okay. I want to keep some time for CIP 50 as we discussed initially. So maybe Michael, if you're still around and want to give us a short update on progress on that side, there was a discussions with Argulus that happened last week. If I recall correctly in the SPO call. So maybe some news on that. You should be able to speak. But I can't hear you. **Anthony Meyer** -:I'm also still not hearing Michael. Is it only me? **Matthias** -: No. Okay. So there is no one speaking, right? I see Michael keeps unmuting himself, but we can't hear you somehow. I thought it might just be me, but no. **Anthony Meyer** -: No, I'm also not hearing him. **Matthias** -: Christophe is also unmuted. If you also maybe have some info on that. So he rejoined and we still can't hear you. Nope. Well, that's unfortunate too, I'm not seeing any Michael. Michael is in chat. You don't see him? He's in the list. **Anthony Meyer** -: I did see Michael at the start of this call. **Matthias** -: I'm failing on audio. Yeah, we can see that. So I don't know if Christophe maybe wants to give us that shorter bit. I think you've both chatting on that. Okay. Or we can leave it for next time or has it written a update maybe? On the meeting windows app. Yeah. **Christophe** -: I guess I, can you guys hear me? **Anthony Meyer** -: Yes. **Matthias** -: Yes, we can hear you. **Christophe** -: Thanks, Michael can't speak, but I guess I just put on, I just updated a pull request on the rank leverage based ranking recommendation last night, which we've removed a grading system to kind of be a little bit more objective. So it's just kind of a 10 is the best and then zero is the worst kind of recommendation, but again, it's just a recommendation, not actually core to it. **Matthias** -: Okay. So, well let's maybe keep room for CIP 50 at the beginning of the next meeting next time to make sure we got time to discuss it and maybe resolve geo problems during the call. I will also try to maybe just post the summary of, again, the conversation that happened on this calls. I haven't been keeping track of that lately, but bit of things have been said, and yeah, so I wasn't part of the SPO call with Argulus, and I would have been curious to just hear what was said. I'm not sure if it was recorded or not. That's cool. Probably not. They are not usually recorded. But anyway, so it's time. ### Discussions #### PR299 [PR299 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/299) **Matthias** -: Okay. So let's have it on the next biweekly that would give people some more time to go through it and hopefully a bit of time for the author to address some of the points that we mentioned. Okay. No comments. So moving to the next one. So we have CIP 50 on review here, but I would like to jump actually on CIP 68 and CIP 66 first, since we've been talking about CIP 50 for pretty much every past meetings. And I would like maybe to keep it for the end more as a closure kind of discussion if people are okay with that. **Matthias** -: Okay. I see one thumbs up in the chat, two thumbs up in the chat. So CIP 68, which is also a big peace to be discussed. Wait, wait, can I click on that? Anthony, do you think you can bring that one on screen, on the stream? **Matthias** -: Yeah. Great. So, yeah, I also been through that one today, made quite a few comments and I try to summarize some of the discussion that happened between people. There has been mainly three discussions tracks, as far as I could tell. One between kind of Michael and Alessandro on the metadata spoofing that is currently possible with CIP 25 and how this is still possible with CIP 68, but far less likely. And so discussing possible alternatives or how to mitigate that, or make it even less likely to happen. There has been another conversation discussing the costs, more of that CIP since in this proposal, there is an implied creation of UTXOs. **Matthias** -: So the core idea is to have, per token two different UTXOs, one capturing the actual asset and one carrying the metadata of that asset, evolving on two separate track, which means that compared to the current approach, there is an extra UTXO being generated that incurs obviously ada deposits and additional costs. So that was being discussed and it'll be nice to have numbers on that maybe, just as a kind of high level analysis and finally, a third discussion on whether or not to store the data on chain as CIP 68 suggests, or do it more like in an option manual, like CIP 54. And in particular, there was quite some disagreement about whether or not CIP 25 should be deprecated in favor of that one. And I think this is a completely separate discussion. So there is a new proposal that offers an alternative to CIP 25 and next to that, there will need be a discussion on whether or not CIP 25 should be deprecated and rendered obsolete. Even though there are now 5+ million tokens that have been minted under CIP 25, despite all the flaws. So yeah, that was more for discussions. **Sebastien Guillemot** -: Yeah, so [inaudible 00:15:32]. **Sebastien Guillemot** -: So my summary of CIP 68, I do not think there's anything technically wrong with the proposal. And I think most of the discussion around the CIP is not so much, well not there's anything technically wrong with the proposal. It's mostly discussion about whether or not people think that this standard will get adoption, which is a fine discussion to have, especially because people, their point of view may, I'll clear the specification itself. But I feel like we're at a point with CIP 68 where I would feel comfortable to say that this looks like it, if nothing comes up in the next, two weeks, we can move this to a draft standard and then set some sort of adoption requirements to mark this as active. **Sebastien Guillemot** -: If, we say this is technically correct, and nobody's really discussing the technical aspects of this anymore and then it ends up that's [inaudible 00:16:46] is the only project that adopts it, then okay, it just stays as draft forever and never got adoption and that's a fine result. If, people end up bringing this and then decide it's worth whatever trade offs that are involved and gain adoption that we can mark it as active. But I think, the discussion about deprecating CIP 25 for discussions around adoption, I think are a separate discussion of the technical correctness of this spec. And I think at this point we're kind of past the technical correctness stage, is my thoughts on this, but I'm open to hearing what other people think. **Matthias** -: Yeah. I pretty much agree on that from the technical point of view. So I came quite late in the conversation and really just read for the CIP today and beyond a few minor things. I didn't really spot anything technically wrong. I think I made a few suggestions regarding at least the "implicitness" of some privileged labels. Just assuming that some asset labels are blessed and always implicitly present in that CIP since there is this whole registry concept now. I think it would be better to just go for generic and I have also the CIP itself embraced this history for self-defining itself and possibly future evolutions. But yeah, beyond that, indeed. And- **Sebastien Guillemot** -: Yeah, I noticed here as well, he's under here as well if he wants to comment anything. **Matthias** -: That's what I was about to ask. Yes. We have a list on also. Let's unmute. You can now speak. Yeah. **Alessandro Konrad** -: Can you hear me? **Matthias** -: Yes. **Alessandro Konrad** -: Okay, great. So first of all, regarding CIP 68 versus CIP 25, the thing is that CIP 68 is defining a more generalized metadata standard for any token. And this is pretty much overseeing because anyone who is commenting on costs is mostly referring to NFT drops. If I meant NFT, the costs are pretty much not there. They are irrelevant. It's really only for NFTs. But the thing is that these costs are, if you implement the amending policy, I would say correctly, the costs are temporarily because you could implement native burning mechanism and then redeem the data at some point, if the NFT is getting worthless. So I think, I don't know if this is, yeah, really a cost then, and CIP 68 kind of forces you to make use of Plutus and I think everyone who is using CIP 25 is making use of very simple native scripts, just the time locking policy. **Alessandro Konrad** -: And over time, these NFTs are completely locked. There's no way to burn them. So I don't think that's great either because, yeah, I'm pretty sure from all of the five million assets, 90% will probably get worthless over time. I don't know. But these assets are simply then, yeah. [inaudible 00:20:52] simply locked forever and with CIP 68, we could get rid of this because people are more or have to get more into Plutus and then they realize, well, we could actually have some kind of native burning mechanism and redeem the data again because maybe over time we will have less and less data in total supply. **Matthias** -: Sounds, this could even be framed that way perhaps more clearly on the motivations behind the CIP. What is revealed on the table is this programmability of NFTs. If you don't need that, then CIP 25 is probably a good fit because of its adoption and despite its other problems. But if you need programmability, if you want to be able to manipulate either NFTs or just need metadata access within the script, then that is a sound standard for that. So perhaps, yeah. I don't know, frame it bit more like it, indeed, like you said, right? A generic standard on metadata storing and NFT being one possible component of that, but perhaps not the main use case either. **Alessandro Konrad** -: Yeah. **Matthias** -: We have a lot of activities in the chats and maybe it would be worth to bring some of those people on the vocal. So we have Andrew saying: "I agree, technically, correct. I wouldn't want to deprecate CIP 25 though. NEWM is using CIP 25 to mint NFT". Thomas: "disclaimer, you do not need to use produce native script can also be used for the CIP". Phillip saying: "I also agree, but forcing people to learn a new standard is not the right way, I think". Okay. Andrew: "producer's minting/burning with an unlock policy while guaranteeing that they are true NFTs, non fungible", and finally Thomas: "this CIP perfectly allows you to pre-mint assets as a creator and later distribute them with native scripts." Should we bring a few people on the vocal maybe to discuss that a bit more? **Matthias** -: So I would love that then. Andrew, if you [inaudible 00:23:23]. **Alessandro Konrad** -: Yeah. Maybe Thomas because he's the other author. **Matthias** -: Okay. So Thomas and Andrew, you can unmute yourself if you want to speak, if you don't want to speak, well stay mute. **Thomas** -: Hi, nice to meet you all. I'm Thomas the other author of this CIP. Yeah. So I think this CIP doesn't force you to use Plutus, but it allows you to use Plutus and fully use it. So as I said, you can pre mint these assets by yourself and then distribute the reference NFTs to a script that you like, you can lock them indefinitely, you can lock them, yeah. And at any address you would like, this here doesn't specify that. But what it does, it allows you to mint with Plutus and that opens a lot of doors. So that... **Andrew** -: Yeah, I would agree overall I like the CIP. I think it allows for programmability when the NFT requires programmability, but I do like the simplicity of CIP 25. So what we're doing on my new project is we are using Plutus to mint, but we're not following this CIP 68 because we don't need all of those. All of that complexity, all we need Putus for is just to have this continually unlocked policy while at the same time, guaranteeing that you can't reinvent the same NFT twice. So that's what Putus gives us there. So it's basically unlocked policy forever guaranteeing that everything you spit out of that is a true NFT. But I do like that CIP 25 is very simple because we don't have very complex needs as far as programmability I guess. **Thomas**-: If I can comment on that, I think, I agree with you and I think both CIPs will exist alongside each other, but I think perhaps in the future, when more tools are built for CIP 68, so that it's easier to mint, things are predefined. You can just copy stuff from other people that went before, that this barrier that you're describing will be lowered. So I don't see it as a problem in the future. **Andrew**-: The new Plutus scripts are all open source. So people could use that as well. If you wanted to have an NFT that has an always open policy, you can always mint more, but then they'll still be guaranteed to be NFTs that you can't do with a simple script. **Matthias** -: Okay. So I would suggest more concretely to move the proposal maybe to last check for the next call. And as Sebastian was suggesting, so merge it as draft or even proposed I think, in the sense that modulo a few minor points raised today, the proposal is probably already in a shape that is close to final and as soon as we get some adoptions from wallets, market places and the like, move it to active, right? Once we have reference implementations and perhaps a few tools around that. **Thomas** -: Can I mention, I like the idea of that and what I still want to discuss about the CIP and, well, it was mentioned in the discussions as well, get up, we use this label and this is to distinct tokens that use this CIP and who don't, but this is arbitrary. And I think it'll be good to have a discussion about what a good label should be and so first we came up with these brackets and I think these are bad from the discussions that we get and then we mentioned the new bite and other things, but I think that is something that's still open or at least, yeah, we have a proposal, but I would like to hear others about it, what they find important there. **Matthias** -: Wouldn't that be a discussions more for CIP 67? Which is proposing this asset name, label or history. **Thomas** -: That's true. That's true. Yeah. **Matthias** -: So yeah, perhaps we can have it in the next agenda for next time and make sure that the question is sent out before that. So have a call for comments or call for feedback on that particular CIP 67, expressing the question that's basically there. That would be interesting and collect then the feedback on the next bi-weekly meeting. **Thomas** -: Sounds good. #### PR294 [PR294 CIP-0066? | NFT Identity](https://github.com/cardano-foundation/CIPs/pull/294) **Matthias** -: Okay. So jumping to the other metadata proposal we have, which is CIP 66 on NFT identity. We wanted to discuss a bit of, I mean, both because I think it was Sebastian two weeks ago that mentioned there might be some overlap between the two. I've been through CIP 66 today and so it's naturally overlapping as far as I could say, but I could definitely see CIP 66 use or make use of CIP 68 to define this identity standard. So the thing I pointed out on CIP 66 is mainly that it's still relying on the same, or it seems to be relying on the same principle as CIP 25. And therefore in there is the same flows as for who is really minting the token and who is providing metadata. And should it just be always the same person? Apparently yes or implicitly, yes because of how the proposal is defined, which has further complications. **Robert Phair** -: Is the title of the CIP specific enough for people to understand what it's really about? **Matthias** -: Yeah. **Robert Phair** -: There was some other suggestions just like maybe NFT verification or verifier identity, if that's what it, in terms of its function or maybe NFT collection, or I thought maybe issuer identity, if it's who is doing it. **Matthias** -: From what I've grasped also from that proposal, it's mainly about taking the W3C recommendations for the DID standards that came out recently and kind of embed that in transaction with that data on Cardano. So, I mean, that is then very, very specific to the W3C recommendations. And I think the title should maybe mentioned that explicitly that this is a kind of card integration for this particular [inaudible 00:31:28]. **Robert Phair** -: Something like NFT DID. Or- **Matthias** -: Yeah. NFT DIDs W3C recommendation integration, or maybe it's a bit too verbal, I don't know [inaudible 00:31:42] but it's, from the specification standpoint, it's also very rough on the edges, I would say, and refers a lot to the specifications on the W3C recommendations. It's basically the same, just adapting the format and putting it on kind of metadata. So in that sense, right, it's really just a wrapping CIP; that is wrapping another existing specification and translating the format from Json to [inaudible 00:32:15] somehow, which is also specified at this stage. So- **Sebastien Guillemot** -: Yeah, my comment about the similarity is that basically, so in CIP 66, you basically have two levels of indirection implementing, whereas in CIP 68, there's only one level of indirection. And with the two levels of indirection, you don't need this kind of asset name stuffing with the brackets and everything, all that goes away. So it's kind of different ideas for how you can go about this. I understand this is not the main innovation that CIP 66 was attempting to bring, which is why they didn't elaborate at all. But their core concept, as you mentioned, would not be compatible with CIP 68 because they went with a double layering direction. So it would be nice if somebody proposed a alternative to CIP 68 that uses a double layer of indirection solution, which as a entirely personal opinion is I think the better approach. But that was just the rationale for that comment. **Matthias** -: Okay. Is there any more comments on that one actually? Yes Thomas. **Robert Phair** -: Have Thomas. Yeah. **Matthias** -: You are now unmute. **Thomas** -: So that's end. Thanks for that. Could you specify more how you mean by these two layers, any improvement to our CIP is welcome so, but I didn't follow it quite clearly, what you meant with that. **Sebastien Guillemot** -: Yeah, so basically the way that CIP 68 works is that you have the asset names define the different categories of the assets or the different use cases rather, right? So for a specific name, you have specific utility that this name encodes, whereas the second layer of direction, you basically have a minting policy that will be in charge of other minting policies and these other minting policies are than what name based the split functionality. **Thomas** -: Okay. Thank you for clarifying. Yeah, I get it. **Sebastien Guillemot** -: Yeah. So you have two minting policies instead of a single minting policy, you have next to [inaudible 00:35:05] direction. **Thomas** -: Yeah. I think this processes a bit with an image shared in our CIP as well, that Alisandro made when we proposed this, the CIP doesn't specify this because you don't have to, but you could do it. Yeah. **Sebastien Guillemot** -: So it would be nice if we had a CIP standard where we did not right away out of the gate, have it, do it standard, come out and not be compatible with it, but baring that discussion, which is kind of tangential. I don't see any problem with CIP 66 as it is from a technical perspective. **Matthias** -: Well, I do see a few, but I've commented that on the proposal, especially the fact that it seems to narrate the same flows as CIP 25, which seems highly undesirable for something like this, where you would want perhaps to enforce an additional layer of security or make sure that it's not that easy to spoof someone else's identity. Plus, yeah, a bit like some remarks we made on previous CIPs that, it feels a bit rushed on the writing. There were many examples, but not so much details on the specifications and how you should interpret this or that particular scenarios. So yeah. I'm happy to have this [inaudible 00:36:50]. **Sebastien Guillemot** -: Yeah. Which is why I feel like this CIP would've been better had it been something more like CIP 68's approach where they had a CIP that just defines this double indirections scheme up, the scheme they came up with and then made their NFT I think CIP reference saying this word, generic CIP. **Matthias** -: Would you mind maybe commenting on that? I mean, on the core request itself. **Sebastien Guillemot** -: Yeah. That's what my comment was supposed to indicate, but I think maybe I wasn't clear enough and maybe people got confused. #### PR307 [PR307 CIP-0060? | Music Token Metadata](https://github.com/cardano-foundation/CIPs/pull/307) **Matthias** -: So, okay. Let's keep it on the agenda for review for the next meeting. And since we have 10 minutes left, let's quickly go through the CIP 60, which on my end, I'm a bit, sorry. That's the only one I haven't got really time to go through today. So since we have Andrew, I'm happy if you can give us a small introduction on that and yeah, just let's have a bit of a chat on it. You are probably muted. Yes. Now you can. **Andrew** -: Okay. Yep. I can speak now. Yeah. So CIP 60 came about because of there was a lot of, the standard for visual NFT metadata is very well defined in CIP 25. It's kind of geared towards that. It allows music and audio in the files section on CIP 25. But what we needed is more metadata for things like players or wallets that wanted to play music NFTs in a nice format and display all the necessary information like who the various artists are, publishers, et cetera, all the information that's really needed in a music player. And so that's what this CIP is designed to do, is just kind of define some structure extend CIP 25 with a well defined structure for something that is a music NFT, so that wallets and aggregators, and everybody can build players for the music that's in people's wallets. This was in collaboration with I think maybe 10 to 20 different individuals who are all building music type businesses on Cardano. **Andrew** -: And so we had a lot of input as to what fields were absolutely required. And so that's kind of how the CIP is broken up, is there's required fields and then there's kind of optional fields for defining what it looks like and then players, of course, they can make sure they implement it minimum, all the required fields for playing the music. And then, it again is still an open standard, so if certain music projects will add additional functionality on top of this, but it, again, doesn't need to be specified in the CIP. This is very specifically just so people can have the bare minimum to know that, yes, this is the music NFT and here's how you can play the music inside of it. **Sebastien Guillemot** -: Yeah. I think for this CIP, we could try and bike shed on the specific fields, but I think this probably will not be super useful on this versioning to help with this anyway. So I think from this one, the tricky part will be trying to measure how much backing the CIP has but as you mentioned, this was then a combination with a few projects, so it'd be good if these projects [inaudible 00:41:11]. **Andrew** -: : Most of them are all signed, to contributors. **Sebastien Guillemot** -: Yeah. So I know they're all the authors, but it'd be good if they just, being just like, oh yes we're actually using this for real project of some kind. Or if you had a wallet, I know [inaudible 00:41:26] wallet included music NFTs in their wallet. So maybe it'd be good to have them. **Andrew** -: Yeah. So they're actually one of the people that is involved with this. So maybe if we can get them to comment on it, I'll talk to them about that. **Matthias** -: And this is something I would love to see in the rationale section as well. Exactly what you just explained. This is a collaborative effort between actual people building with, in the music industry, on, kind of, i don't know, the blockchain in general and that's also why we justifying some of the choices that have been made. **Andrew** -: Okay. **Matthias** -: That just gives a bit of context on where the decision comes from in the legitimacy of that. **Andrew** -: Okay. **Matthias** -: From a technical standpoint, just to clarify things, this is proposing to extend the on chain with the data and the set of fields that is provided alongside current NFTs from the CIP 25 right? **Andrew** -: That's correct. It supports CIP 25 version one and version two. **Matthias** -: Okay. Then should we maybe move it to last check for the next goal provided that this was already discussed with a few? **Andrew** -: Yeah. We've had several two hour meetings with people. There was 20 different groups in the room, either producing music on Cardano or representing wallets or players or things like that. So yeah, I will add to the rationale section before next meeting that this comes up. **Matthias** -: Okay. Thanks. **Andrew** -: Probably not next meeting, but maybe the meeting after, because the next meeting is always in the times I can't be at. **Matthias** -: You're right. So let's keep that in for the US based next meeting. **Andrew** -: Yep, thank you. ### Issues N/A ### Close **Matthias** -: So let's just wrap up quickly on what we just discussed. We've been through CIP 51 at the beginning, which we agreed to rediscuss, bring back on the table after the Vasil hard-fork has happened. Since this anyway won't happen before Vasil and further discussions are needed, then CIP 48 extended submitted data for CIP 25. The proposal was is a bit rushed out in terms of quality and format. So the content itself is okay technically-wise, but there are quite a few shortcomings when it comes to how it is written. So we asked the author to fix that. CIP 30, we have agreed to just close up requests. It's been inactive for a while. The author is not responsive. I can't close it myself, unfortunately, because I'm on windows. But if any of the other auditors want to do it, please do. CIP 45 then the using pledge as a bidding program, there is some overlap with CIP 50. This is part of the broader discussions about rewards and incentives and there were concerns being raised about this actually incentivizing large pledge owners to just create more stake pools without actually impacting the decentralization of Cardano. At least not in a good way. Then we went through CIP 68, which we agreed to put that last check for next week and merge as proposed given that's, the technical content was, already has been through many iterations although there were a few points raised regarding this two-step beta data identifications that could perhaps, they discussed as well. So anyway, that will be a full two weeks before we go to the last check and we'll see for further updates after that. We've been through the NFT identity proposal to CIP 68, which also sounds technically okay, in the context of CIP 25, although it narrates the same shortcomings and flaws. So perhaps further discussions are needed. The format of that one is also a bit fleshed out and could deserve well, that be a bit more love and especially some more details on, well, the actual details of the CIPs. Possibly also some renaming, since this seems to be heavily inspired by the W3C recommendations, maybe could be made a bit clearer from the CIP title and finally CIP 60, the token metadata extension for music-related tokens, which comes as an extension of CIP 25 and has been a collaboration between many different individuals in the music industry around Cardano. It is mainly proposing a set of 20+ new fields that are specific to music-related NFTs. And we agreed to discuss it as the last check for not the next biweekly, but one after which will be also in the US-friendly time zone. And that's it, sorry, we are four minutes beyond the clock and thank you all. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: BiweeklyMeetings/2022-09-06.md ================================================ **Table of Contents:** - [Summary](#summary) - [Editors Meeting Flow](#editors-meeting-flow) - [September 06 2022 Transcript](#september-06-2022-transcript) * [Triage](#triage) + [CIP-0049? | ECDSA and Schnorr signatures in Plutus Core](#pr250) + [CIP-0037? | Dynamic Saturation based on Pledge](#pr163) + [CIP-0038? | Arbitrary Script as Native Script spending conditions](#pr309) + [CIP-0039? | Language annotated address](#pr310) * [Last Check](#last-check) + [CIP-0060? | Music Token Metadata](#pr307) + [CIP-0068? | Datum Metadata Standard](#pr225) * [Review](#review) * [Discussions](#discussions) + [CCIP-0050? | Shelleys Voltaire decentralization update](#pr242) * [Issues](#issues) * [Close](#close) ## Summary Rough transcript of 06/09/22 Editors CIP meeting, to increase transparency and dialogue with the community regarding proposed changes, implementations and considerations. _Transcript might contain errors or miss pieces - call out issues as needed_ Editors meetings are [public](https://discord.gg/36ezQYTvgk), [recorded](https://www.youtube.com/c/CardanoFoundation/videos) and [transcript](https://github.com/cardano-foundation/CIPs/tree/master/BiweeklyMeetings): do join and participate for discussions/PRs of significance to you. ## Editors Meeting Flow **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.. **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) **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. **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord. **Issues**: Review of the open Issues on the CIP GitHub **Close**: Recap of actions taken and decisions. List the CIPs that are due for review. ## September 06 2022 Transcript **Attending Editors**: Matthias Benkort, Sebastien Guillemot, ~Frederic Johnson~, Robert Phair. **Guests**: Las Safin ### Triage #### PR250 [PR250 CIP-0049? | ECDSA and Schnorr signatures in Plutus Core](https://github.com/cardano-foundation/CIPs/pull/250) **Matthias** -: Okay. Let's start with Sebastien, and first is PR number 250, which is adding some Schnorr compatible signature to Plutus built-in to get some form of Bitcoin support or Bitcoin compatibility support into Cardano or enable some protocols to move assets from one chain to another to smart contracts. So I think this is pushed by MLabs, but in discussion with Input-Output, in particular with Michael Peyton Jones as well. So I see, Inigo has been commenting on that one for a few bits, but it's still ongoing, I think, the draft. **Matthias** -: I did a very, very sort of basic review today, and on the surface, it looks good. What's going on? Okay. So I don't have much more comment on that one. I think it's probably good to have it for review or last check for next time, given that the various points are being addressed. I would try to get more maybe buy-in from other parties, because right now most of the work is really done behind those walls between IOG and MLabs, but maybe we could get more people on board on that one. **Robert** -: You had just recently asked Michael to come back into the discussion, and I think that sounds great to just leave it on hold until we hear from him. **Matthias** -: Yeah. That was, I think, that the list I had to do. He has commented in the past and approved for the best. I think he has even co-written that. That's why. But yeah, I guess it's just an ongoing discussion happening for signing through to Schnorr, and there is maybe not much to add in the end. That is a helpful one as well. **Matthias** -: There was one thing I was missing from the rationale maybe, because they mentioned they change a bit the serialization format compared to what Bitcoin uses, which I find interesting or curious, so I will be interested in the rationale, why change the serialization format? That can create some layer of frustration between parties integrating after that. If it's nothing really stands out, then that's probably not a big issue, but yeah. Okay. So maybe we leave it as last check for the next biweekly and see if the discussion settles or not and perhaps advertise that on a few more channels or at least it's here. #### PR163 [PR163 CIP-0037? | Dynamic Saturation based on Pledge](https://github.com/cardano-foundation/CIPs/pull/307) **Matthias** -: Next one is the dynamic saturation based on pledge. Not sure why we put this one on triage. It's a last-check item, because we've been reviewing that one for a while. I think the last time we agreed to merge it as proposed. Saying it was only missing a path to active, mentioning the last steps were now to get this idea reviewed by the IOG's research team. Important to see implementation feasibility or not. A bit like CIP 0050 and other of the like, so this has been added by the author, so I think we can just move forward with that one and merge it as planned. **Anthony**-: Yes. It seems like either you or Sebastien would just be able to put it through. **Matthias** -: Yep. Let me try that. And that one is 0062. Sorry. I have to do that on the phone. Okay. Good. And I will put a note to add it or modify it with me after the call to include that one now. I have no news on that update from IOG regarding a study group for CIP 0050 or CIP 0037 and the likes. So I will contact Kevin Hammond again to see. I think IOG is at a workshop this week, so they won't probably be much responsive, but maybe we can get some form of response. #### PR309 [PR309 CIP-0038? | Arbitrary Script as Native Script spending conditions](https://github.com/cardano-foundation/CIPs/pull/309) **Matthias** -: Let's jump then maybe to the two CIP you proposed, Sebastien, last week or two weeks ago, since you are here. Oh, a month ago, actually. Well, quite late. So the first one, CIP 0038, competitively for request number 300-09, arbitrary script as native script spending conditions. **Sebastien** -: Yes. So basically, the problem is that Plutus scripts are not treated the same as native scripts. These are two different kinds of scripts. The reason there's a difference is because Plutus scripts require phase-two validation whereas native scripts do not. This difference makes it tricky to use Plutus scripts for a variety of reasons. And then on top of that, there's no way to specify datum when you're sending to a Plutus script. It's a totally unrelated limitation to Plutus scripts. So these two problems, as I mentioned earlier, make it really hard to basically compose protocols together in Cardano. So for example, if you're using Catalyst and you want the result of the Catalyst vote to be paid out to your DOW address, you can't do it at the moment, because you can't specify a Plutus script as the receiver of the Catalyst rewards. **Sebastien** -: So there are a few ways we can improve the situation. One of them, of course, would be getting rid of the requirements that Plutus scripts have to have datum and allowing some kind of default case. But a different way to handle this, which I think is a lot easier and also has the added benefit of getting rid of this collateral requirement in these phase-two issues, is to extend the native script functionality. **Sebastien** -: Native scripts on Cardano are how you can do basic multisig, and they have as one of their conditions the ability to say, "Oh, you need three out of five public keys to sign this transaction." What we can do is extend native scripts, so you can also have similar conditions on script hashes. So you can say that, "Oh, for this new script to pass, it needs, for example, three of five script hashes to be included in this transaction and succeed." So I think this will make it much easier to use native scripts to compose different protocols together without having to introduce user interface validation you have to worry about and without requiring the presence of a datum. **Matthias** -: Okay. I'm not sure to fully understand the motivations behind it, because as far as I ... I understood your main point is when you send to Plutus script, you have to send to associate also a datum with it. But surely that datum can just be an empty datum, like a unit. **Sebastien** -: No, because not every API has a way for you to even easily set the datum. For example, if you're spending through data lists, there's no way for you to add the datum in the spend page. If you're specifying an address in Catalyst, there's no way for you to tell the Catalyst team, "Oh, yeah, and provide this datum." So there are a lot of cases where you can't easily provide this information. **Matthias** -: Then that's more a problem of software interface than a problem with the protocol itself, right? **Sebastien** -: Well, so the root problem is that Plutus requires a datum, there's not really any protocol needed to add this restriction, and it is something that we can remove and that I think we should remove as a separate CIP. But as you know, changing Plutus' behaviour is quite a large change in this group of things. And then even if we take this path of getting rid of this default Plutus datum behaviour, there's still a difference in functionality between native scripts and Plutus scripts. So I still think even if we had a CIP like this to get rid of the requirement, it would still make sense to provide this kind of composability feature, both as a Plutus script feature and as a native script feature. **Matthias** -: Okay. I think I will also take the time to go through the CIP. I haven't really been reviewing that one yet. I see it's had mostly comments from IOG folks. What's been the sentiment so far since Michael's and Jared's? **Sebastien** -: Yeah. Mostly the sentiment has been nobody's particularly objecting to this. People would prefer to spend the time making the Plutus change to get rid of the datum requirement. I think that's definitely something that's worth doing, but I would prefer if we had both options, especially because adding a new feature to native scripts, as we know, is very easy because we've done this in the past, whereas making a change to Plutus is more involved. And so if we only have that path, it would be also kind of delay the time it takes to add this function to the protocol. **Matthias** -: Yeah, yeah. This sounds like two separate functions in a way. I mean this would solve one problem while not necessarily preventing this to be also enhanced next to it. **Sebastien** -: Yeah, exactly. So I would like to have both. The discussion of that CIP is mostly a question of prioritisation, which one should core developers focus on first, but I think that's kind of not really the decision we need to make [inaudible 00:27:05] Mostly, this CIP is just mostly studying it. This is a good idea, if we want. **Matthias** -: Okay. Jared comments on the impact of extending any native script in that direction regarding the ledger holes and the validation that this would ensure. **Sebastien** -: I don't recall anything that was complicated about this. I looked at the code myself, and currently, we already have two native script versions because, if you remember, at some point, we added time locks, so we already have native script v1, native script v2, so it'd just be a question of adding in native script to v3 with this proposed change, and it's not a breaking change either. **Las Safin** -: Hello. **Matthias** -: Hey. **Las Safin** -: Good day, Sebastien and Matthias. I have a few questions with regards to the CIP items. I sort of understand the motivation, because you have the whole issue. I understand the whole issue. You have a datum, and you can't really specify that datum as part of those steps, but that's partly an issue with DApps being implemented poorly and partly an issue with the UX of Cardano being bad. But I don't think this actually solves the issue, because if you have some sort of smart contract, have got funds, and you have it now, and everyone votes to send the funds to some DEX, right, and the DEX just sends the funds back. **Las Safin** -: Or imagine if it's more automated, you can actually do this, even with this native script thing, because what return address do you specify when you send the funds to the docks, not the docks, to the DEX? Well, you want the native script return address, but how do you compute that? It's a hash. Doing that on chain is certainly possible, but it's very inefficient, and I don't see how this solves the problem, myself. I think this is a problem worth solving. I thought about it myself too, but I'm not sure that native scripts are solutions to the problem. I thought maybe what about just adding datums to the address. That's a bit radical, but what are you think about this? How does this solve the problem? **Sebastien** -: So the key point is that the native script that you're creating can specify a list of scripts that are required, and scripts in Cardano don't have to be deployed on chain, right? So if you want to add extra logic, like how to handle returning something or handling an error case or whatever, you can generate what the Plutus script for that will be, take the hash of it, include that hash inside one of the native script requirements, and then use that as your native script address. **Las Safin** -: Yeah. I don't think this solves the problem actually, though. I'll give you all a convincing example. Imagine you have some fully automated thing, and I guess the presence of [inaudible 00:30:25] state machine, it does something automatically. At one point, it wants to send funds to a DEX, and the funds should go back to some other script, and the datum will depend on the current state of the state machine. Maybe we just want to send the state machine to the new script actually, and I don't see any way to do this with this mechanism, because there is no way of specifying what datum you want to send back to. Sure, of course, you can specify- **Sebastien** -: Yes, there is. So basically you create a Plutus script that takes the datum you want to return to as a parameter. Not a runtime parameter, but parameter in the construction of the script itself, like a template. **Las Safin** -: But that doesn't work, because you can't check this, you can't check this on chain. Although if you check this on chain, you have to do bit-fiddling, you have to check the content of the script, because there's no way to do the parameterisation on chain in a fully automated manner and fully trust this manner on chain, unless you do the bit-fiddling. Of course, that's certainly possible. It doesn't really solve the problem to a satisfactory level in my mind. **Sebastien** -: If you know what you want the return address to be at the time the user's generating the address, then this is not an issue. If you want to compute this dynamically, then you'll need to have some more complex interaction for this. For example, you could have the script associated instead of native script require [inaudible 00:32:08] smart contract, which then figures something else later or triggers something else later, and you have to do multiple steps. But I think this is more a question of not being able to do this in one go, and the situation you're describing will require multiple steps of execution, but I don't think that's necessarily problematic. **Las Safin** -: I mean, you're going to have the problem with necessitating multiple steps and then multiple extra transactions to do some sort of wrapping. But in this scenario, it's a very, very minor step forward, because there are very few use cases where this is actually useful, where you'd have a static return address. In almost all DApp interactions, you need to have a dynamic return where you would ... There are two issues here. You, first of all, want to ... It's like an [inaudible 00:32:58] You want to send state to the return address in the form of datum or something, but you also want the party that sends to the return address. For example, the DEX sends funds to some dynamic statements being incentivised. This DEX should also be able to specify extra information. And sure, you can do that for tokens, actually, so it's not a huge problem. The problem is you're also specifying the return name. Because this doesn't really solve it, it's a very minor fix. I mean, sure you could, you could just add this and be like, "Okay, we've solved this for one particular use case, but maybe we should think of a more general solution before going ahead with this.” **Sebastien** -: Well, this has everything we need to basically build proxy contracts for layer twos and side chains, which is the main thing that we want. If you want something more complicated, you'll have to do multiple steps, as we discussed, or you may want to use this other functionality described where we allow Plutus scripts with no datum. But the situation you were describing, I don't think it's not possible. It's tedious. It is possible if you're not- **Las Safin** -: It is impossible because of the CPU limit. It's [inaudible 00:34:14] handle the concept of the serialization of the script on chain, hash it on chain, then modify it on chain. Sure, it's possible, but it's not really the way we should go. What's wrong with just adding the datum to the address, because the datum, is actually part of the address in some sense from a semantic perspective? What about just making it part of the status life once it [inaudible 00:34:38] **Sebastien** -: You can have a script, part of the native script requirement list, and this script as part of the native script requirement list says the next transaction needs to contain an output with this datum as part of it. It's not great, I agree, but if you want to specify a datum, arbitrary datum, instead of adding this datum to the address itself, you could just encode the requirement of adding this datum as part of this native script that's embedded into the address. **Las Safin** -: I think ... Yes, but what about just adding the datum to the address? Would this solve your problems, or would it not solve your problems if we just add the datum to their address? **Sebastien** -: It would not solve the problem for our situation, but I can imagine cases where this is sufficient for them. **Las Safin** -: Why would it not solve your case? What do you seek to do? Because if you want some datum action, you just say send to this address, and you specify it as part of the address, and that datum may just an NCA [inaudible 00:36:09] **Sebastien** -: So this would solve your ... So I guess we would get into the same situation where this would solve our problem if we had multiple steps. Basically, if we did this other option you're proposing, where we had the address with the datum embedded inside the address, you would first be sent to a Plutus script, which in our case would then be a Plutus script that then requires composability within native scripts, which is what we're using. So I guess the solution you're providing solves our solution as long as we're okay with multiple steps as well on our side. **Las Safin** -: Okay. I think actually I also think of a few other more general solutions, so maybe I'll also write up some thoughts, because I think we can maybe just bring more advanced here. Because I think there's also the more general problem of parameterisation being highly non-trivial on chain, but I think we can actually make a solution where you can parameterise any hash by another hash if we change the serialisation format of pieces of it. **Sebastien** -: Yeah. So again, I think the solution you're providing falls into kind of the same bucket as the ongoing discussion inside the CIP, which is that there are multiple ways we can deal with composition. Each way has some advantages. The implementation I'm proposing is very simple and solves a certain set of issues. The version you're proposing is also interesting. It solves also some set of issues. There's no reason we can't have both, and so I don't see it as a detriment to this CIP in any way. **Las Safin** -: Yeah. Maybe it's fine to have both. I mean, the one question I didn't actually say my answer, it says requires, so does that mean it can be anyone in the script cons? Can it be a state validator, mainly policy, a validator can be anything, or does it have to be something specific? **Sebastien** -: Yeah, that's a good point. We might want to add extra functionality for you to be able to insert more about where the script hash is. I'm not sure if we want to go that far, because I feel like this kind of goes down a rabbit hole of adding too much functionality. It's meant to be fairly simple. So I would say it is just any script that's part of the transaction. **Las Safin** -: That's fine. I think that's fine. My concerns are over. I think this CIP to step forward and it's certainly useful, but I think we should also think of a more general solution from what [inaudible 00:39:29] **Sebastien** -: Yeah, I agree. I think we should definitely increase composability in multiple different ways to handle multiple situations. **Las Safin** -: Right, thank you. #### PR310 [PR310 CIP-0039? | Language annotated address](https://github.com/cardano-foundation/CIPs/pull/310) **Sebastien** -: And on a related note, we have a second CIP that's also proposed by me that's also partially related to this one and partially related to the discussion we just had, which is CIP 0039 for language annotated addresses, which basically says that right now addresses in Cardano, you can't tell the difference between a native script and a Plutus script. But CIP 0039 tries to set a standard for being able to differentiate between script kinds. **Sebastien** -: There's two ways that can be implemented. It can be implemented as a purely off-chain construct, and the blockchain itself has no knowledge of this difference, or we could go all the way and implement this as an on-chain construct. The discussion inside the CIP is mostly people talking about how they prefer to have this as an on-chain construct, but there is no clear way to make this an on-chain construct that really works for everybody. And so that's kind of the summary of this discussion. **Matthias** -: So are you proposing to extend the address type to have new types that can now carry a script in the space? **Sebastien** -: Yeah, that's the basic idea. So basically, we extend the existing address format on Cardano to annotate them to include the script type used inside the address. But as you know, the addresses are parsed by wallets and these things are not necessarily on chain, and so you could have the wallets take an address, use it to assert the script type, and then strip the script type information to submit that off-chain. I assume that part on chain. So that's how you implement the CIP without having to make any changes to the blockchain itself, which I think is more like the first implementation because trying to change the on-chain format of access is one, complicated, and two, there's really no good way to have the chain really enforce script types. **Matthias** -: But this is kind of the nature of my questions because you have two options also regarding your address. You can either modify the existing types or add new types that will include scripts, which means that you will still have the ability to use the old address type that does not include the script namespace. So I think this makes it slightly easier to implement in a non-breaking manner. **Sebastien** -: And I said this back in the CIP. So basically, there are two ways. There's one way of allocating new types, like the [inaudible 00:43:08] numbers, and the other way is to extend the existing types. We can extend the existing types without introducing a new number in the header, and this will work except for pointer addresses. The reason why is, because if you change the existing types, you can differentiate between them based on the length of the address. If it's one length, it's one standard. If it's another length, it's a different standard. This doesn't work for pointer addresses, because they have an undefined length, so there's not really a good way to parse them. **Matthias** -: Maybe there is a CIP to make here to suggest the removal of pointer addresses, since I think we are amongst the two individuals that have been using them on the chain, the only two. So yeah, that will simplify a bit the things. Okay. Should we get that CIP for review next week? Is the discussion still ongoing? Or I see mostly happened months ago, but no, no- **Sebastien** -: No, I don't think there's any ongoing discussion anymore. I think everybody has said their thoughts on the proposed path. I think some of the stuff has not been decided for the CIP 0039, the language annotated addresses. Michael Peyton Jones and Jared wanted to try and figure out how we can make this an on-chain construct that is actually validated by the blockchain itself. But then you need some way for the blockchain to know ahead of time whether not an address is a native script or a Plutus script. Or the other option is that if you don't validate this ahead of time, but then if somebody sends to the wrong script type, they can never spend from it, which is also not great. **Matthias** -: So it could be done fully optionally. So if you specify a type and you provide the script part of the transaction, then the ledger validates it. And if it doesn't validate, then it fails. So as a client, you have a way to sort of enforce that there is a ledger validation on top, but if you don't provide it, then yes, the ledger has no way to validate it. Then it's just blindly accepts it, like it does now. **Sebastien** -: Yeah. And the question is whether not this validation should have been when you send to the address or when you spend from the address. **Matthias** -: Well, I would say if you can do it when you send to the address, that's where the interest is at this stage, because that's where I think it can happen right now. **Sebastien** -: Yeah. That was my preference as well. Michael Peyton Jone's preferred to do the validation when you spend from the address. **Matthias** -: When you spend from it, you can always do it, because you have the script at this stage. But then what happens if you have sent to an address which has a mismatch between the type and the actual script, you are just locked forever. **Sebastien** -: Yeah. That's Michael Peyton Jones's suggestion. **Matthias** -: Okay. That's an interesting suggestion. **Sebastien** -: Yeah. I prefer to avoid people accidentally potentially locking funds forever, if possible, which is why I'm not the biggest fan of that proposal, but also, I understand that the chance that you get this wrong, you send the wrong script type, is also fairly small. It's not the biggest concern, but I think figuring out which validation we will take if we make this an on-chain construct is the main thing that needs to be decided. But if we're in disagreement about the way we want to do the validation, but we're in agreement on the binary format of this, then we can just make this CIP be the off-chain standard only, and then have another discussion about how to do any on-chain validation in the future. **Matthias** -: I don't quite see the benefits of doing on-chain validation after the fact on this, because this is really a feature to prevent people from shooting themselves in the foot, and now we are just giving them one more way of doing that if we do the validation after the fact. So if it's purely informative for wallets and applications downstream to be able to identify whether or not a certain asset is locked behind a Plutus script or a native script, then I don't see what validations would add on top. **Sebastien** -: Yeah. I 100% agree with you. **Matthias** -: Okay. Maybe to move that CIP forward then is to also decide on how you want to implement that between the off-chain or on-chain. And perhaps it can start, as you said, off chain, having wallets already recognising that format, using it, but stripping the parts when actually submitting things on chain. I think that will be quite hard to get adoption across the entire ecosystem in a way, because now you will also get some discrepancies. Some wallets will show an address, and an explorer might show a slightly different address, which might be very confusing for people. So my own preference would be to have that enforced on chain fully, even if there is no validation or extra validation done yet on top of it. That wouldn't be worse than the current status quo, and then we can take a bit more time to think about how we want to validate that if we want to validate it. That's my thoughts, yeah. **Matthias** -: Regarding the implementability of that CIP, did you discuss that with Jared also on the PR? **Sebastien** -: Nothing beyond validation rules. **Matthias** -: Okay, because I imagine if it's just adding new addresses, it should be pretty straightforward implementation-wise, as it's just extending an existing sum type basically. And yeah, it doesn't introduce new validation logic in that sense. It's just a script address that carries some additional information with it. But yeah, that would be to discuss. I will make a more formal review also after the call, adding some comments on itself. And let's see. Let's have it for either review for next biweekly. See if we can get more insights from the core team as to whether this is implementable and what the plan is. ### Last Check #### PR307 [PR307 CIP-0060? | Music Token Metadata](https://github.com/cardano-foundation/CIPs/pull/307) **Matthias** -: Last check, also, we have CIP 0060, Music Token Metadata, which we reviewed last time. I think we had a few minor comments which were addressed, that it seems. Okay, yes, we're going to need to change the tips, sadly, change the time zone as it's my bad. I suggested to change the type to processes, but it's actually process. I believe that there's no type of ... We can probably do it ourselves. Far as I'm concerned, this one is also good to go. Any comments, Sebastien or Robert? **Robert** -: I think since they chose all of their metadata items based on meetings that they already had, that part of it seems complete. They also in the discussion thread answered some questions about the scope of the proposal, so I really don't see that there's anything else to do with this other than merge it. That's already the outcome of their own consensus, their media group. **Matthias** -: Yeah, exactly, exactly. So it's nice of them to actually put that in paper and record it. And well, I still have reasons to, regarding CIP 0025, but since this one is based on safety, 0025 acts as an extension of it. But that's something which is a bit off-topic here. So I would approve, but under the condition that we change the processes, I mean the type from process to process. I think we can do it, unless Andrew Givens has prevented commit from his branch. If he did, then I think he would just modify it. That'd be fine. And also the status, we need to change it to proposed. **Matthias** -: What would be the best to active in that one, I guess, some of those parties used the CIP. So if this is already in use, maybe we can even merge it as active right away. Also, that doesn't [inaudible 00:13:14]. I'm just commenting on the branch. Maybe if you want to move to the next one, which is CIP 0068. #### PR225 [PR225 CIP-0068? | Datum Metadata Standard](https://github.com/cardano-foundation/CIPs/pull/225) **Robert** -: We don't have any of the CIP 0068 participants here today on the guest list, it looks like. **Matthias** -: No. They are US based, so they are unlikely to join today. **Robert** -: Oh, on the wrong time zone. **Matthias** -: Yeah. **Anthony**-: So if everybody's happy, I will leave CIP 0068 in the agenda for the US time zone meeting next week. **Matthias** -: No, no. CIP 0060. **Anthony**-: CIP 0060. Apologies. **Matthias** -: Oh, CIP 0060, I think we will be able to merge it after the call once we have done just the two changes we mentioned, fix the type and change the status to either proposed or active, depending on whether or not this CIP is already used by these artists, music industry companies, which is what I'm capturing on the pro-request comments. But I was simply suggesting maybe to move to CIP 0068 in the meantime. **Sebastien** -: Keep in mind that for CIP 0068, it depends on CIP 0067, which had a non-trivial update last week. **Matthias** -: CIP 0067, the label registry, right? **Sebastien** -: Yeah. **Matthias** -: Yes. So you want to work us through that bit, Sebastien? **Sebastien** -: To be honest, I haven't had the time to read through it all. **Matthias** -: Okay. So should we keep then CIP 0067 for review for the next bi-weekly call and CIP 0068 in the meantime, because they both go hand-in-hand, basically? Is that what you're suggesting? **Robert** -: Yes. For the USA-friendly time zone, that sounds like it would yield a better discussion. **Matthias** -: Yeah. I think CIP 0068. It's mostly European folks behind it in spots. **Sebastien** -: Yeah, I don't think the US time zone quite particularly helped for CIP 0068. I have no issues as it is, but my comment last time, other than seeing whether or not it gets any adoption, it's just the main thing. Just love to see if CIP 0067 had some changes, but I'll need to review it. But for 0068, I have no issue with it. **Matthias** -: Sorry. I just finished commenting on this one, so CIP 0068, we'll keep it as review for the next meeting, part with CIP 0067 first to make sure- **Sebastien** -: [inaudible 00:17:58] **Matthias** -: What? Sebastien, you said something or ... **Anthony**-: Yeah, I'm also struggling to pick up on Sebastien's line. **Sebastien** -: I was saying, Matthias, he is really quiet for me. Is he quiet for anybody else? **Anthony**-: He's not that quiet from my side, no, but Sebastien, your volume and clarity has just improved quite a lot for me. **Matthias** -: I try to increase my volume maybe a bit, Sebastien. **Sebastien** -: Way better, way better. **Matthias** -: Okay, good. So I was just saying CIP 0067 and CIP 0068 for review for next time. We'll go through CIP 0067. There is, I think, already quite some discussions happening on this one, although it's happening in various places. So yeah, probably they've got enough attention. We don't necessarily need to bring more people into the discussion, particularly CIP 0068, which has been going over a lot in a lot of chats. Yeah, okay. So I'll keep them for next time then. ### Review ### Discussions #### PR242 [PR242 CCIP-0050? | Shelleys Voltaire decentralization update](https://github.com/cardano-foundation/CIPs/pull/242) **Matthias** -: Okay. So I would say we have about 10 minutes left, so that gives us a bit of time to go through maybe CIP 0050 and some updates on the discussions there. I haven't been following the latest items on that, so I'm not sure if any individual has. Robert, maybe. **Anthony**-: I'm not getting any audio from Robert. Is it just me? **Matthias** -: Yes, I do hear you, Robert, but I think Anthony doesn't. **Robert** -: ... there was hope for, because it's been up for so long, it's become a magnet for proposals that are similar that are coming in and out of the CIP 0050 thread. So there has been commentary, but not really about CIP 0050 itself. **Matthias** -: I think it was a bit the goal of CIP 0050 also to become the hive mind, as Michael calls it, right, [inaudible 00:53:46]. **Robert** -: Yes. **Matthias** -: Welcome discussions on incentives, rewards, and how to do better with an initial proposal, but not necessarily the finite proposal, being CIP 0050. I mean, it will be eventually, but it might be vastly different from what was initially submitted. I think that was kind of the idea. **Robert** -: Yes. And one of those that we just recently merged without the meeting was sort of a really quick and dirty way of dealing with the problem just by a linear relationship between pledge and saturation, something that would work for some centralisation cases, but allow others. So I think we're still looking for something that is going to deal with the civil attack problem and the centralisation problem, all in a nutshell. It's a bit like the grand unified field theory. Everyone has an idea how to tackle a different part of it, but it's hard to put the whole thing together. So since the author is a scientifically rigorous person, it seems to be a theory that hasn't promoted any particular practical application yet. People are still talking about different ways of doing it. **Matthias** -: Also, new participants in the discussions recently, which is interesting. Okay. So I guess we'll also need to go through a bit about the discussion that happened on GitHub, and also this call, try to make a summary for next time and see. And as I said earlier in the call today, I need to reach out against you, Kevin Hammond from IOG, to see if we can get any more attention from IOG researchers. It would be very nice to get more collaboration on that in an ongoing effort with milestones and actually actionable items a bit. I guess they have Vasil now plans to be held out for September 22nd, so that kind of topic should be next on the pipeline, hopefully. ### Issues N/A ### Close **Matthias** -: Okay. I think it's a good time to wrap up maybe. So I will try to do that. Let me pull back the agenda. Yes, we've been through CIP 0049, candidate CIP, which is adding two new primitives to Plutus to verifying Schnorr and ECDSA signatures, which would bring some form of Bitcoin compatibility into Cardano. It's been mostly discussed by IOG and MLabs. It's in good shape, so we'll have it next time for review and last check. Then we've finally merged CIP 0037 as proposed, although this is a CIP that falls in the same category as CIP 0050, discussing rewards and incentives. For Cardano, it has different pros and cons as discussed in CIP 0050. So this was more a way to put the closure on that discussion on CIP 0037 to also move it more to the more general CIP 0050 discussion. Then we've had a last look at CIP 0060 for the music token metadata, which was already reviewed, discussed, and it was really just a last sanity check. We agreed to merge it. We fixed the typo in the type and changed the status to either proposed or active, depending on whether or not industry members are already using it extensively. We've postponed the discussion on CIP 0068, because it needs to go hand in hand with CIP 0067, and we haven't really got enough time to go through that CIP 0067 recent update. So we'll have both as review for next week, sorry, for the next meeting I mean. We have discarded CIP 0045 and CIP 0066 from the discussion from the agenda today, because there have not been any substantial updates since last time we discussed them, and we instead looked at CIP 0038 and CIP 0039, which sparked an interesting discussion during the meeting and specifically on how do we maybe improve a bit the overall UX surrounding scripts on Cardano and, in particular, how do we prevent users from shooting themselves in the foot when sending to script addresses. So CIP 0038 proposed one way to alleviate some of the problems or some of the difficulty that there is currently with the usage of Plutus scripts and datums. The discussion was now to move forward, we wanted to make a decision on how we want to enforce that, on chain or off chain. On chain, meaning that this requires some buy-in also from the core teams to implement. CIP 0039, which is more on the side of addresses and how do we improve address. Sorry, I mixed them both. So on chain versus off chain discussions is on CIP 0039, and CIP 0038 was about the extension of the native script to introduce validation of Plutus scripts as the next type constraint, possibly many if combined with the existing primitives of the native scripts. I think that was it. So thank you all for joining and see you in two weeks. **Sebastien** -: Thank you. **Anthony**-: Thank you, everybody. Just a short note, Matthias, that the next CIP will take place next week, just because this was a delayed CIP. **Matthias** -: Okay, sorry. **Anthony**-: Okay. No, just to clarify. **Matthias** -: Next week then. **Anthony**-: All right. Thank you. **Matthias** -: Cheers. --- ## Extra ### [Current CIPs in the CIP repository and their status](https://github.com/cardano-foundation/CIPs/blob/master/README.md) :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":_ ![Mary interacting with community and editors for a Cardano Proposal](../sequence_diagram.png?raw=true "sequence_diagram.png") ### Understanding CIPs further [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw) [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo) © 2022 GitHub, Inc. Terms Privacy Security Status Docs Contact GitHub Pricing API Training Blog About ================================================ FILE: CIP-0001/CIP-0001.md ================================================ Moved to [CIP-0001/README.md](./README.md). ================================================ FILE: CIP-0001/README.md ================================================ --- CIP: 1 Title: CIP Process Category: Meta Status: Active Authors: - Frederic Johnson - Sebastien Guillemot - Matthias Benkort - Duncan Coutts - Michael Peyton Jones - Robert Phair Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/366 - https://github.com/cardano-foundation/CIPs/pull/331 - https://github.com/cardano-foundation/CIPs/tree/3da306f3bfe89fa7de8fe1bf7a436682aeee25c5/CIP-0001#abstract - https://github.com/cardano-foundation/CIPs/pull/924 Created: 2020-03-21 License: CC-BY-4.0 --- ## Abstract A Cardano Improvement Proposal (CIP) is a formalised design document for the Cardano community and the name of the process by which such documents are produced and listed. A CIP provides information or describes a change to the Cardano ecosystem, processes, or environment concisely and in sufficient technical detail. In this CIP, we explain what a CIP is, how the CIP process functions, the role of the CIP Editors, and how users should go about proposing, discussing, and structuring a CIP. The Cardano Foundation intends CIPs to be the primary mechanisms for proposing new features, collecting community input on an issue, and documenting design decisions that have gone into Cardano. Plus, because CIPs are text files in a versioned repository, their revision history is the historical record of significant changes affecting Cardano. ## Motivation: why is this CIP necessary? CIPs aim to address two challenges mainly: 1. The need for various parties to agree on a common approach to ease the interoperability of tools or interfaces. 2. The need to propose and discuss changes to the protocol or established practice of the ecosystem. The CIP process does not _by itself_ offer any form of governance. For example, it does not govern the process by which proposed changes to the Cardano protocol are implemented and deployed. Yet, it is a crucial, community-driven component of the governance decision pipeline as it helps to collect thoughts and proposals in an organised fashion. Additionally, specific projects may choose to actively engage with the CIP process for some or all changes to their project. This document outlines the technical structure of the CIP and the technical requirements of the submission and review process. The history, social features and human elements of the CIP process are described the [CIP repository Wiki][Wiki]. ## Specification ### Table of Contents - [Document](#document) - [Structure](#structure) - [Header Preamble](#header-preamble) - [Translations](#translations) - [Repository Organization](#repository-organization) - [Versioning](#versioning) - [Licensing](#licensing) - [Statuses](#statuses) - [Status: Proposed](#status-proposed) - [Status: Active](#status-active) - [Status: Inactive](#status-inactive) - [Path to Active](#path-to-active) - [Categories](#categories) - [Project Enlisting](#project-enlisting) - [Process](#process) - [1. Early Stage](#1-early-stages) - [1.a. Authors open a pull request](#1a-authors-open-a-pull-request) - [Naming CIPs with similar subjects](#naming-cips-with-similar-subjects) - [1.b. Authors seek feedback](#1b-authors-seek-feedback) - [2. Editors' role](#2-editors-role) - [2.a. Triage in bi-weekly meetings](#2a-triage-in-bi-weekly-meetings) - [2.b. Reviews](#2b-reviews) - [3. Merging CIPs in the repository](#3-merging-cips-in-the-repository) - [4. Implementors work towards Active status following their 'Implementation Plan'](#4-implementors-work-towards-active-status-following-their-implementation-plan) - [Editors](#editors) - [Missions](#missions) - [Reviews](#reviews) - [Nomination](#nomination) ### Document #### Structure A CIP is, first and foremost, a document which proposes a solution to a well-defined problem. Documents are [Markdown][] files with a _Preamble_ and a set of pre-defined sections. CIPs authors must abide by the general structure, though they are free to organise each section as they see fit. The structure of a CIP file is summarised in the table below: Name | Description --- | --- Preamble | Headers containing metadata about the CIP ([see below](#header-preamble)). Abstract | A short (\~200 word) description of the proposed solution and the technical issue being addressed. Motivation: why is this CIP necessary? | A clear explanation that introduces a proposal's purpose, use cases, and stakeholders. If the CIP changes an established design, it must outline design issues that motivate a rework. For complex proposals, authors must write a [Cardano Problem Statement (CPS) as defined in CIP-9999][CPS] and link to it as the `Motivation`. Specification | The technical specification should describe the proposed improvement in sufficient technical detail. In particular, it should provide enough information that an implementation can be performed solely based on the design outlined in the CIP. A complete and unambiguous design is necessary to facilitate multiple interoperable implementations.

This section must address the [Versioning](#versioning) requirement unless this is addressed in an optional Versioning section.

If a proposal defines structure of on-chain data it must include a CDDL schema. Rationale: how does this CIP achieve its goals? | The rationale fleshes out the specification by describing what motivated the design and what led to particular design decisions. It should describe alternate designs considered and related work. The rationale should provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.

It must also explain how the proposal affects the backward compatibility of existing solutions when applicable. If the proposal responds to a [CPS][], the 'Rationale' section should explain how it addresses the CPS and answer any questions that the CPS poses for potential solutions. Path to Active | Organised in two sub-sections (see [Path to Active](#path-to-active) for detail):
Acceptance Criteria
Describes what are the acceptance criteria whereby a proposal becomes _'Active'_.
Implementation Plan
Either a plan to meet those criteria or `N/A` if not applicable. _optional sections_ | May appear in any order, or with custom titles, at author and editor discretion:
**Versioning**: if [Versioning](#versioning) is not addressed in Specification
**References**
**Appendices**
**Acknowledgements** Copyright | The CIP must be explicitly licensed under acceptable copyright terms ([see below](#licensing)). > [!NOTE] > Each of these section titles (*Abstract* onward) should be an H2 heading (beginning with markdown `##`). Subsections like _Versioning_ or _Acceptance Criteria_ should be H3 headings (e.g. `### Versioning`). Don't include a H1 title heading (markdown `#`): for web friendly contexts, this will be generated from the Preamble. ##### Header Preamble Each CIP must begin with a YAML key:value style header preamble (also known as _front matter data_), preceded and followed by three hyphens (`---`). Field | Description --- | --- `CIP` | The CIP number (without leading 0), or "\?" before being assigned `Title` | A succinct and descriptive title. If necessary, use a `-` delimiter to begin with an applicable classification (see [Naming CIPs with similar subjects](#naming-cips-with-similar-subjects)). Don't use backticks (`) in titles since they disrupt formatting in other contexts. `Category` | One of the editorially accepted [categories](#categories) covering one area of the ecosystem. `Status` | Proposed \| Active \| Inactive (.._reason_..) `Authors` | A list of authors' real names and email addresses (e.g. John Doe ) `Implementors` | A list of implementors committed to delivering an implementation of the proposal, when applicable. `N/A` when not applicable and `[]` when there's currently no implementor. `Discussions` | A list of links where major technical discussions regarding this CIP happened. Links should include any discussion before submission, and _must_ include a link to the pull request that created the CIP and any pull request that modifies it. `Solution-To` | A list of [CPS][] that this CIP addresses, if any. Omitted when not applicable. `Created` | Date created on, in ISO 8601 (YYYY-MM-DD) format `License` | Abbreviation of an approved license(s) For example: ```yaml --- CIP: 1 Title: CIP Process Category: Meta Status: Active Authors: - Frederic Johnson - Sebastien Guillemot - Matthias Benkort - Duncan Coutts Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/366 Created: 2020-03-21 License: CC-BY-4.0 --- ``` Especially because Markdown link syntax is not supported in the header preamble, labels can be added to clarify list items; e.g.: ```yaml Discussions: - Original-PR: https://github.com/cardano-foundation/CIPs/pull/366 ``` > [!TIP] > A reference template is available in [.github/CIP-TEMPLATE.md][CIP-TEMPLATE.md] ##### Repository Organization A CIP must be stored in a specific folder named after its number (4-digit, left-padded with `0`) and in a file called `README.md`. Before a number is assigned, a placeholder folder name should be used (e.g. `CIP-my-new-feature`). After a number has been assigned, rename the folder. Additional supporting files (such as diagrams, binary specifications, dialect grammars, JSON schemas etc.) may be added to the CIP's folder under freely chosen names. For example: ``` CIP-0010 ├── README.md ├── registry.json └── registry.schema.json ``` ##### Translations While CIPs are mainly technical documents meant to be read primarily by developers -- and thus often written in English; some may be translated into various languages to increase their outreach. Any file in a CIP folder may also include translated content satisfying the following rules: - Any translated file shall share a common basename with its original source. - Translation file basenames must have a suffix using an [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) language code, separated by a dot `.` character. (e.g. `README.fr.md`). - When no language code is provided as suffix, the default language for the document is assumed to be English (UK/US). - Translated CIPs (i.e. `README` files), must not include the original preamble. They must, however, include the following preamble as yaml frontmatter data: Field | Description --- | --- `CIP` | The CIP number (without leading 0) `Source` | The canonical GitHub link to the original CIP document `Title` | A translation of the CIP's title `Revision` | Whenever possible, the commit hash (7 first hex-digits, e.g. `12ab34c`) of the source in the main repository. If the source was not committed to the main repo, use the best known translation date in ISO format (if unknown, use the date posted in the translation's PR branch). `Translators` | A list of translators names and email addresses (e.g. `John Doe `) `Language` | An [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) code of the target language (e.g. `fr`) - Translated CIPs inherit the same licensing terms as their original sources. ##### Versioning CIPs must indicate how the defined Specification is versioned. **Note** this does not apply to the CIP text, for which annotated change logs are automatically generated and [available through the GitHub UI](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/viewing-and-comparing-commits/differences-between-commit-views) as a history of CIP files and directories. Authors are free to describe any approach to versioning that allows versioned alterations to be added without author oversight. Stipulating that the proposal must be superseded by another is also considered to be valid versioning. A single Versioning scheme can be placed either as a subsection of the Specification section or in an optional Versioning top-level section near the end. If the Specification contains multiple specification subsections, each of these can have a Versioning subsection within it. ##### Licensing CIPs are licensed in the public domain. More so, they must be licensed under one of the following licenses. Each new CIP must identify at least one acceptable license in its preamble. In addition, each license must be referenced by its respective abbreviation below in the _"Copyright"_ section. | Purpose | Recommended License | | --- | --- | | For software / code | Apache-2.0 - [Apache License, version 2.0][Apache-2.0] | | For documentation | CC-BY-4.0 - [Creative Commons Attribution 4.0 International Public License][CC-BY-4.0] | > [!WARNING] > All licenses not explicitly included in the above lists are not acceptable terms for a Cardano Improvement Proposal unless a later CIP extends this one to add them. #### Statuses CIPs can have three statuses: `Proposed`, `Active` or `Inactive`. [The CIP Process section](#process) highlights how CIPs move through these statuses; no CIP should be given one of these statuses without satisfying the criteria described here below. > [!NOTE] > There is no "draft" status: a proposal which has not been merged (and hence exists in a PR) is a draft CIP. Draft CIPs should include the status they are aiming for on acceptance. Typically, but not always, this will be _'Proposed'_. ##### Status: Proposed A _'Proposed'_ CIP is any CIP that meets the essential CIP criteria but is not yet _'Active'_. The criteria that must meet a CIP to be merged as _'Proposed'_ are: - It must contain all the sections described in [Structure](#structure). - The quality of the content must be to the Editors’ satisfaction. That means it must be grammatically sound, well-articulated and demonstrates noticeable efforts in terms of completeness and level of detail. - Its technical soundness should have been established. Where necessary, this may require review by particular experts and addressing their concerns. Note that the requirement is that the proposal makes sense (i.e. be technically sound), yet no consulted experts need to think it is a good idea. - It must have a valid [Path to Active](#path-to-active) as defined below. ##### Status: Active An _'Active'_ CIP has taken effect according to the criteria defined in its _'Path to Active'_ section. Said differently, each CIP defines by which criteria it can become _'Active'_ and those criteria are included in the review process. Exact criteria thereby depends on the nature of the CIP, typically: - For CIPs that relate to particular projects or pieces of technology, it becomes _'Active'_ by being implemented and released; - For changes to the Cardano protocol, a CIP becomes _'Active'_ by being live on the Cardano mainnet within one or more implementations; - For ecosystem standards, it means gaining sufficient and visible adoption in the community. - It must have a valid [Path to Active](#path-to-active) as defined below: even the CIP is already acknowledged as `Active` or being documented retroactively (after acceptance and implementation). A proposal that is _'Active'_ is considered complete and is synonymous with "production readiness" when it comes to the maturity of a solution. _'Active'_ CIPs will not be updated substantially (apart from minor edits, proofreading and added precisions). They can, nevertheless, be challenged through new proposals if need be. ##### Status: Inactive An _'Inactive'_ CIP describes any proposal that does not fit into the other types. A CIP can therefore be _'Inactive'_ for various reasons (e.g. obsolete, superseded, abandoned). Hence the status must indicate a justification between parentheses; for example: ``` Status: Inactive (superseded by CIP-0001) ``` #### Path to Active This must be subdivided into two sub-sections: - _'Acceptance Criteria'_ This sub-section must define a list of criteria by which the proposal can become active. Criteria must relate to observable metrics or deliverables and be reviewed by editors and project maintainers when applicable. For example: "The changes to the ledger rules are implemented and deployed on Cardano mainnet by a majority of the network", or "The following key projects have implemented support for this standard". - _'Implementation Plan'_ This sub-section should define the plan by which a proposal will meet its acceptance criteria, when applicable. More, proposals that require implementation work in a specific project may indicate one or more implementors. Implementors must sign off on the plan and be referenced in the document's preamble. In particular, an implementation that requires a hard-fork should explicitly mention it in its _'Implementation Plan'_. > [!NOTE] > The statuses of `Proposed` and `Active` _both_ require a _Path to Active_ section, making this a _required_ section for all viable proposals. Even if a CIP is edited or submitted with an `Inactive` status, it may still be helpful to have a `Path to Active` if there are conditions that might lead to its acceptance or implementation. #### Categories CIPs are classified into distinct categories that help organise (and thus, find) them. Categories are meant to be flexible and evolve as new domains emerge. Authors may leave the category as `?` should they not be sure under which category their proposal falls; editors will eventually assign one or reject the proposal altogether should it relate to an area where the CIP process does not apply. Submissions can be made to these categories whenever relevant, without following any particular submission guidelines: Category | Description --- | --- Meta | Designates meta-CIPs, such as this one, which typically serve another category or group of categories Wallets | For standardisation across wallets (hardware, full-node or light) Tokens | About tokens (fungible or non-fungible) and minting policies in general Metadata | For proposals around metadata (on-chain or off-chain) Tools | A broad category for ecosystem features not falling into any other category Additionally, representatives of ecosystem categories may explicitly _enlist_ their categories (see next section) to suggest a closer relationship with the CIP process. The following categories are confirmed as enlisted according to CIPs which define that relationship: Core Category | Description --- | --- Plutus | Changes or additions to Plutus, following the process described in [CIP-0035][] Ledger | For proposals regarding the Cardano ledger, following the process described in [CIP-0084][] These tentatively enlisted categories await CIPs to describe any enlistment relationship: Core Category | Description --- | --- Consensus | For proposals affecting implementations of the Cardano Consensus layer and algorithms Network | Specifications and implementations of Cardano's network protocols and applications #### Project Enlisting Project representatives intending to follow an "enlisted" category above agree to coordinate with related development by sharing efforts to review and validate new proposals. It should be noted that single organisations can no longer represent any ecosystem or development category, which makes these enlistment guidelines both decentralised and cooperative, including whenever possible: - allocating time to **review** proposals from actors of the community when solicited by editors (i.e. after one first round of reviews); - defining additional rules and processes whereby external actors can engage with their project as part of the CIP process; - defining boundaries within their project for which the CIP process does apply; - establishing points of contact and any designated reviews for a category; - agreeing upon how proposals move from the state of idea (i.e. CIP) to actual implementation work; - writing CIPs for significant changes introduced in their projects when it applies. Any guidelines for this cooperation should be described by a dedicated CIP whenever possible. When such a CIP is posted or supersedes another one, it will be entered into the above table in the Categories section. Participants of enlisted categories should follow the requirements outlined in that CIP and should update such proposals whenever these requirements or relationships change. > [!WARNING] > A positive review by any enlisted project representative does not constitute a commitment to implement the CIP. It is still the CIP author's responsibility to create an implementation plan and identify implementors. Editors occasionally invite representatives from enlisted categories to speak during review meetings and solicit them for ultimate approvals of proposals in their area of expertise. **Note** Optionally, projects may show their enlisting using the following badge on their introductory README: ![https://github.com/cardano-foundation/CIPs](https://raw.githubusercontent.com/cardano-foundation/CIPs/master/.github/badge.svg) > > ```md > ![https://github.com/cardano-foundation/CIPs](https://raw.githubusercontent.com/cardano-foundation/CIPs/master/.github/badge.svg) > ``` ### Process #### 1. Early stages ##### 1.a. Authors open a pull request Proposals must be submitted to the [cardano-foundation/CIPs][Repository] repository as a pull request named after the proposal's title. The pull request title **should not** include a CIP number (and use `?` instead as number); the editors will assign one. Discussions may precede a proposal: early reviews and discussions streamline the process down the line. PRs should not contain commits that also appear in other repository PR's: usually the consequence of re-using a branch in your fork or submitting your work from your fork's `master` branch. To avoid this, please: - Don't submit your PR from your fork's `master` branch. - Create a new branch for every pull request that you intend to submit. > [!TIP] > The CIP title in the pull request should be kept consistent with the CIP header `Title:`. > [!IMPORTANT] > Pull requests should not include implementation code: any code bases should instead be provided as links to a code repository. > [!NOTE] > Proposals addressing a specific CPS should also be listed in the corresponding CPS header, in _'Proposed Solutions'_, to keep track of ongoing work. ###### Naming CIPs with similar subjects When a CIP title *and* subject matter share a common element, begin the CIP title with that common element and end it with the specific portion, delimited with the `-` character. Example (CIP-0095): > *Web-Wallet Bridge **-** Governance* CIP editors will help determine these common elements and, whenever necessary, rename both CIP document titles and PR titles accordingly. The objective is to provide commonly recognisable names for similar developments (e.g. multiple extensions to another CIP or scheme). ###### Link to proposal from PR first comment In the original comment for your pull request, please include a link to the directory or the `README.md` for the CIP in your working branch, so readers and reviewers can easily follow your work. This makes it easier for editors and the community to read and review your proposal. > [!NOTE] > If this link changes (e.g. from the CIP directory being renamed), please keep this link updated. ###### Follow a reviewer- and editor-friendly review process As review progresses: - When editors and reviewers submit changes that you accept, commit them from the GitHub UI so these review points are resolved. - Even if resolving these in your own environemnt, mark any review points Resolved as they are resolved: otherwise your PR will appear stalled and merging will likely be delayed. - **Don't "force push"**: which overwrites commit histories and disrupts change visibility during the review process. Instead, `git merge` the PR branch back into your local environment: which will preserve any collaborative editing history. ##### 1.b. Authors seek feedback Authors shall champion their proposals. The CIP process is a collaborative effort, which implies discussions between different groups of individuals. While editors may provide specific inputs and help reach out to experts, authors shall actively seek feedback from the community to help move their proposal forward. Discussions and comments shall mainly happen on Github in pull requests. When discussed on other mediums, we expect authors or participants to report back a summary of their discussions to the original pull request to keep track of the most critical conversations in a written form and all in one place. As much as possible, commenters/reviewers shall remain unbiased in their judgement and assess proposals in good faith. Authors have the right to reject comments or feedback but **are strongly encouraged to address concerns in their 'Rationale' section**. Ultimately, CIP editors shall make the last call concerning the various statements made on a proposal and their treatment by the author(s). By opening pull requests or posting comments, commenters and authors agree to our [Code of Conduct][CoC]. Any comment infringing this code of conduct shall be removed or altered without prior notice. > [!NOTE] > For acceptability guidelines, including a concise review checklist, see [CIP Wiki > CIPs for Reviewers & Authors](https://github.com/cardano-foundation/CIPs/wiki/2.-CIPs-for-Reviewers-&-Authors). #### 2. Editors' role ##### 2.a. Triage in bi-weekly meetings CIP editors meet regularly in [a public Discord server][Discord] to go through newly proposed ideas in a triage phase. As a result of a triage, editors acknowledge new CIPs, and briefly review their preamble. Editors also assign numbers to newly proposed CIPs during this phase. Incidentally, the triage allows new CIPs to get visibility for potential reviews. ##### 2.b. Reviews In every meeting, editors will also review in more depth some chosen CIPs (based on their readiness and the stability of the discussions) and assess if they meet the criteria to be merged in their aimed status. During review sessions, editors will regularly invite project maintainers or actors from the ecosystem who are deemed relevant to the meeting's agenda. However, meetings are open and held in public to encourage anyone interested in participating. A dedicated Discord channel may also be created for some long-running discussions to support quick chats and progress on particular topics (while still being regularly summarised on the repository). #### 3. Merging CIPs in the repository Once a proposal has reached all requirements for its target status (as explained in [Statuses](#statuses)) and has been sufficiently and faithfully discussed by community members, it is merged with its target status. > [!WARNING] > Ideas deemed unsound shall be rejected with justifications or withdrawn by the authors. Similarly, proposals that appear abandoned by their authors shall be rejected until resurrected by their authors or another community member. CIPs are generally merged with the status _'Proposed'_ until they meet their _'Path to Active'_ requirements. In some rare cases (mainly when written after the facts and resulting in a broad consensus), proposals may be merged as _'Active'_ immediately. Each proposal is unique and has a bespoke _'Path to Active'_, which must be reviewed case-by-case. There must be sufficient time between the first appearance of a proposal and its merge into the repository to ensure enough opportunity for community members to review it. #### 4. Implementors work towards Active status following their 'Implementation Plan' Once merged, implementors shall execute the CIP's _'Implementation Plan'_, if any. If a proposal has no implementors or no _'Implementation Plan'_, it may simply remain as _'Proposed'_ in the repository. > [!WARNING] > It is perfectly fine to submit ideas in the repository with no concrete implementation plan, yet they should be treated as such: ideas. Besides, once all of the _'Path to Active'_ requirements have been met, authors shall make another pull request to change their CIP's status to _'Active'_. Editors may also do this on occasion. ### Editors For a full, current description of Editor workflow, see [CIP Wiki > CIPs for Editors](https://github.com/cardano-foundation/CIPs/wiki/3.-CIPs-for-Editors). #### Missions CIP Editors safeguard the CIP process: they form a group enforcing the process described in this document and facilitating conversations between community actors. CIP editors should strive to keep up to date with general technical discussions and Cardano proposals. For each new draft proposal submitted on [cardano-foundation/CIPs][PullRequest] an editor might review it as follows: - Read the proposal to check if it is ready, sound, and complete. - Check if it has been [properly formatted](#structure). - Check if sufficient time has been allowed for proper discussion amongst the community. - Ensure the motivation behind the CIP is valid and that design choices have relevant justifications or rationale. - Confirm licensing terms are acceptable. - Assign a CIP number - Assign a given category to help with searching - Request wording/grammar adjustments CIPs that do not meet a sufficient level of quality or don't abide by the process described in this document will be rejected until their authors address review comments. #### Reviews Note that editors **may** provide technical feedback on proposals in some cases, although they aren't expected to be the sole technical reviewers of proposals. CIPs are, before anything, a community-driven effort. While editors are here to facilitate the discussion and mediate debates, they aren't necessarily technical experts on all subjects covered by CIPs. Therefore, CIPs authors are encouraged to reach out to known experts to demonstrate their good faith and openness when they champion a proposal. Editors may help with such efforts but cannot be expected to do this alone. #### Nomination Existing editors or the community may nominate new editors, provided they have proven to be already existing and active contributors to the CIP process and are ready to commit some of their time to the CIP process regularly. The missions of an editor include, but aren't exclusively limited to, any of the tasks listed above. Active members that seek to become listed editors may also come forth and let it be known. Any application will take the form of a pull request updating this document with a justification as the pull request's description. Current editors are listed here below: | Robert Phair
[@rphair][] | Ryan Williams
[@Ryun1][] | Thomas Vellekoop
[@perturbing][] | | --- | --- | --- | [@rphair]: https://github.com/rphair [@Ryun1]: https://github.com/Ryun1 [@perturbing]: https://github.com/perturbing Emeritus editors: - Frederic Johnson - [@crptmppt](https://github.com/crptmppt) - Sebastien Guillemot - [@SebastienGllmt](https://github.com/SebastienGllmt) - Matthias Benkort - [@KtorZ](https://github.com/KtorZ) - Duncan Coutts - [@dcoutts](https://github.com/dcoutts) - Adam Dean - [@Crypto2099](https://github.com/Crypto2099) ## Rationale: how does this CIP achieve its goals? ### Key changes from CIP-0001 (version 1) #### Introduction of Cardano Problem Statements A significant friction point regarding complex CIPs is often how the main problem is stated. The _'Motivation'_ is often insufficient (or simply underused) to describe various aspects of a problem, its scope, and its constraints. This lack of clarity leads, in the end, to poorly defined issues and debates over solutions that feel unclear amongst different participants. The introduction of [CIP-9999: Cardano Problem Statements][CIP-9999] addresses this gap by introducing a formal template and structure around problem statements. However, requiring any CIP to be preceded by a CPS would likely be overkill and become an obstacle to the overall adoption of the CIP process for more straightforward problems. At this stage, it is reasonable to think either (a) that CIP authors would foresee the complexity and state their problem as a CPS beforehand or (b) that editors or reviewers will require authors to write a CPS to clarify a perhaps ambiguous motivation on complex CIPs. We also anticipate project maintainers or community actors will write standalone CPS to document well-known issues for which the design space is still to be explored. #### Explicit enlisting A recurring pain point with the previous CIP process was the lack of clear ownership/accountability of some proposals affecting remote parts of the ecosystem. On several occasions, proposals from community members have concerned, for example, core components of the Cardano architecture. However, those proposals have been hard to move forward with and to either reject or turn into concrete action steps. Authors usually do not have the technical proficiency required to implement them and rely on the core engineering team in charge of projects to do so. Thus, explicit compliance and collaboration of those engineering teams are necessary to propose changes affecting their work. By asking teams to explicitly state their compliance with the CIP process with clear, accountable owners (as individuals), it becomes plausible to now establish a dialogue between community members and technical leadership responsible for specific ecosystem projects. Furthermore, projects that, on the contrary, do not seek to participate in CIP or receive contributions in the form of CIP/CPS are automatically taken out of this process, saving time and energy for both reviewers and authors. #### Nomination of new editors The _'Editors'_ section now details how to become a CIP editor. The process aims to be simple and define those involved the most with editorship tasks as editors. Thus, being an active contributor to the CIP process as a prerequisite only makes sense. We want to leave the room open for either existing editors to refer an existing community as an editor or for community members to formulate that request explicitly. There are no delays or number of contributions necessary to pretend to become an editor. Those criteria are often less relevant than others and more subjective, such as the quality of one's participation or their relevance. Since editors also need to work with one another in the end, it seems logical that existing editors have their final say about whom they intend to work with. #### Removal of `type` in the preamble The `type` field in the header has shown to be: - confusing (often authors are getting it wrong); - not-too-useful (as a `type` tells you very little about the nature of the CIP). An ad-hoc classification by non-rigid categories, which may evolve over time to reflect ecosystem areas, seems better suited. Therefore, we do not require authors to categorise their CIPs; instead, categories will be added and maintained by editors as a side task atop the CIP process. #### Simplification of the statuses Over time we've learnt that the valuable information a status should convey is really about the readiness of a CIP, especially regarding standards. For a long time, many CIPs have lived as `Draft` despite some being used in dozens of systems. Consequently, the `status` has lost a bit of its meaning. The frontier between `Draft` and `Proposed` hasn't always been clear, and it has proven challenging to come up with good statuses to describe all possible rejections. So instead, the current division of statuses is as simple-as-it-can-be and remains flexible regarding rejections. ### Choice of CoC The choice of a code of conduct follows other popular open source initiatives. It serves as a good, unilaterally accepted foundation which can be later revisited if necessary. ## Path to Active ### Acceptance criteria - [x] The proposal has been reviewed by the community and sufficiently advertised on various channels. - [x] Cardano Forum - [x] IOG Technical Community Discord - [x] Twitter - [x] Reddit - [x] Cardano Summit 2022 - [x] IO ScotFest 2022 - [x] All major concerns or feedback have been addressed. The document is as unambiguous as it can be and it outlines a process that a supermajority of reviewers is happy to follow. ### Implementation Plan - [x] Rework existing draft CIPs to adopt this new format and process. In particular, CIPs affecting enlisted projects should be brought to the attention of the respective project maintainers. - [x] Edit / align old CIPs preambles and sections to at least reflect also this new format. ## Copyright This CIP is licensed under [CC-BY-4.0][]. [Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0 [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode [CIP-0035]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035 [CIP-0084]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084 [CIP-9999]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999 [CIP-TEMPLATE.md]: https://github.com/cardano-foundation/CIPs/tree/master/.github/CIP-TEMPLATE.md [CODE_OWNERS]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners [CPS]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999 [Discussions:editors]: https://github.com/cardano-foundation/CIPs/discussions/new?category=editors [Markdown]: https://en.wikipedia.org/wiki/Markdown [PullRequest]: https://github.com/cardano-foundation/CIPs/pulls [RFC 822]: https://www.ietf.org/rfc/rfc822.txt [Repository]: https://github.com/cardano-foundation/CIPs/pulls [CoC]: https://github.com/cardano-foundation/CIPs/tree/master/CODE_OF_CONDUCT.md [Discord]: https://discord.gg/J8sGdCuKhs [Wiki]: https://github.com/cardano-foundation/CIPs/wiki ================================================ FILE: CIP-0002/CIP-0002.md ================================================ Moved to [CIP-0002/README.md](./README.md). ================================================ FILE: CIP-0002/README.md ================================================ --- CIP: 2 Title: Coin Selection Algorithms for Cardano Category: Wallets Authors: - Jonathan Knowles Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/2 - https://github.com/cardano-foundation/CIPs/issues/232 Status: Active Created: 2020-05-04 License: CC-BY-4.0 --- ## Abstract This article describes, in _human-readable terms_, the coin selection algorithms used by [Cardano Wallet](https://github.com/cardano-foundation/cardano-wallet/) and other parts of the Cardano ecosystem. In the context of this article, **coin selection** refers to the process of choosing _unspent coins_ from a wallet (or [UTxO set](#utxo-set)) in order to pay money to one or more recipients. ## Motivation: why is this CIP necessary? This document was written to help people gain an understanding of the coin selection algorithms used in Cardano _without_ having to read through and understand Cardano source code. We aim to provide descriptions of algorithms that: - don't require prior experience with any particular programming language; - are understandable for people who are unfamiliar with coin selection; - are precise enough for software engineers to be able to reimplement these algorithms in their preferred programming languages. Where appropriate, we also provide mathematical descriptions, for added clarity. ### Scope Coin selection is a large, complex topic, with many difficult problems to solve. However, all software that performs coin selection must ultimately deal with at least the following pair of problems: - How to _generate_ a coin selection, by choosing unspent coins from a wallet (or [UTxO set](#utxo-set)) in order to pay money to one or more recipients. - How to _adjust_ a coin selection in order to pay for a _network fee_, so that the coin selection can be published as a transaction on the blockchain. This article concerns itself with the _former_ problem of _how to generate_ a coin selection. Problems relating to network fees, and how to adjust coin selections to pay for such fees, are outside the scope of this article. ### Background This section introduces the fundamental concepts behind coin selection, provides a discussion of why coin selection is a non-trivial problem, and describes important goals of coin selection algorithms. #### What is Coin Selection? Coin selection is the process of choosing unspent coins from a wallet in order to pay money to one or more recipients. ##### Coin Selection in the Physical World In the familiar world of _physical_ money, our wallets hold value in the form of _coins and banknotes_. When making a payment to someone, we typically select a combination of coins and banknotes from a wallet that, when added together, have enough value to cover the amount required. Ideally, we'd always be able to select _just enough_ to cover the exact amount. However, given that coins and banknotes have fixed values (and cannot be subdivided without destroying their value), it's often impossible to select the exact amount required. In such cases, we typically give the recipient _more_ than the required amount, and then receive the excess value back as _change_. > :bulb: **Example** > > Alice wishes to pay for her lunch. > > The total price comes to €2.50 (2 euros and 50 cents). In her wallet, she has > **five** _one-euro_ coins, and **one** _ten-euro_ note. > > Note that there is _no_ combination of coins (or notes) in her wallet that > when added together give a total of €2.50, but there _are_ several possible > combinations that _exceed_ the total. > > To solve this problem, Alice selects _one_ of these combinations: **three** > _one-euro_ coins. She uses the coins to make the payment, and then receives > **one** 50-cent coin as change. ##### Coin Selection in Cardano Similarly to how a physical wallet holds value in the form of _unspent coins and banknotes_, a Cardano wallet holds value in the form of _unspent transaction outputs_. An [unspent transaction output](#unspent-transaction-output) is the result of a previous transaction that transferred money to the wallet, where the value has not yet been spent by another transaction. Each unspent transaction output has an associated [coin value](#coin-value), and the total value of a wallet is the _sum_ of these coin values. Collectively, the set of unspent transaction outputs is known as the [UTxO set](#utxo-set). When using a Cardano wallet to make a payment, the wallet software must select a combination of unspent outputs from the wallet's [UTxO set](#utxo-set), so that the total value of selected outputs is enough to cover the target amount. Just as with physical coins and notes, unspent outputs from the UTxO set _cannot_ be subdivided, and must either be spent completely in a given transaction, or not be spent at all. Similarly to a transaction with physical money, the wallet software must select a combination of unspent outputs whose total value is _greater_ than the target amount, and then arrange that _change_ is paid back to the wallet. Coin selection refers to the process of selecting a combination of unspent outputs from a wallet's [UTxO set](#utxo-set) in order to make one or more payments, and computing the set of change to be paid back to the wallet. #### Why is Coin Selection Non-Trivial? There are a number of issues which make the problem of coin selection more complicated than would initially appear. ##### The Transaction Size Limitation Each [transaction](#transaction) has a _maximum size_, as defined by the protocol. The size of a transaction increases as we add more [inputs](#transaction-input) or [outputs](#transaction-output). Therefore, there's a practical limit on the number of coins we can select for any given transaction. ##### The Problem of Dust One simple strategy for *selecting coins* might be to mimic what we do when making a payment with coins and banknotes in the physical world. By giving the recipient an amount that's as close as possible to the amount they're expecting, we can minimize the amount of change they need to return to us. However, trying to replicate this strategy with a UTxO-based wallet has an undesirable effect: minimizing the total value of selected coins will also minimize the value of change returned to the wallet. When repeated over time, this strategy will tend to cause an accumulation of tiny outputs in the wallet's [UTxO set](#utxo-set) known as [**dust**](#dust-output). Dust outputs are a problem, because even if the total value of dust in a wallet is more than enough to cover a given target amount, if we attempt to include that dust in a given transaction, we may run out of space (by reaching the [transaction size limit](#the-transaction-size-limitation)) before we can cover the target amount. For more information on dust avoidance, see [Self Organisation in Coin Selection](#self-organisation-in-coin-selection). ##### The Problem of Concurrency One simple strategy for *generating change* might be to mimic what a shop assistant does when accepting a payment in the real world, which is to minimize the *number* of coins and banknotes that they return to the customer. This is beneficial for the shop, as it reduces the chances of them running out of change, and beneficial for the customer, as it reduces the amount of change that they have to carry around in their wallet. Analogously, when generating change for a UTxO-based wallet, we might be tempted to use the simple strategy of just creating a single [change output](#change-output) with the exact excess value. However, using this strategy has an undesirable effect: the repeated act of minimizing the number of change outputs will tend (over time) to reduce the number of entries in a wallet's [UTxO set](#utxo-set). This is bad for two reasons: 1. Having a small [UTxO set](#utxo-set) limits the number of future payments that we can make in parallel. 2. The approach of coalescing all change into a single output is widely considered to have negative privacy implications. #### Goals of Coin Selection Algorithms In light of the issues described above, we'd ideally like for our coin selection algorithms to be able to: * limit, over the course of time, the amount of [dust](#dust-output) that accumulates in the [UTxO set](#utxo-set). * maintain, over the course of time, a [UTxO set](#utxo-set) with _useful_ outputs: that is, outputs that allow us to process future payments with a reasonably small number of [inputs](#transaction-input). ## Specification ### Structure The [Background](#background) section introduces the fundamental concepts behind coin selection, provides a discussion of why coin selection is a non-trivial problem, and describes the goals of coin selection algorithms. The [Interface](#interface) section gives a description of the common interface unifying all coin selection algorithms used within Cardano Wallet, the standard parameter types, result types, and error types used by this interface, and a description of the properties that all conforming implementations are expected to satisfy. The [Algorithms](#algorithms) section gives detailed descriptions of each of the individual coin selection algorithms used in Cardano Wallet, along with step-by-step descriptions of the computations involved. The [Reference Implementations](#reference-implementations) section provides links to reference implementations of each algorithm in various languages. ### Contents * [Abstract](#abstract) * [Motivation](#motivation-why-is-this-cip-necessary) * [Scope](#scope) * [Background](#background) * [What is Coin Selection?](#what-is-coin-selection) * [Coin Selection in the Physical World](#coin-selection-in-the-physical-world) * [Coin Selection in Cardano](#coin-selection-in-cardano) * [Why is Coin Selection Non-Trivial?](#why-is-coin-selection-non-trivial) * [The Transaction Size Limitation](#the-transaction-size-limitation) * [The Problem of Dust](#the-problem-of-dust) * [The Problem of Concurrency](#the-problem-of-concurrency) * [Goals of Coin Selection Algorithms](#goals-of-coin-selection-algorithms) * [Specification](#specification) * [Structure](#structure) * [Definitions](#definitions) * [Address](#address) * [Coin Value](#coin-value) * [Transaction](#transaction) * [Transaction Input](#transaction-input) * [Transaction Output](#transaction-output) * [Spent Transaction Output](#spent-transaction-output) * [Unspent Transaction Output](#unspent-transaction-output) * [UTxO Set](#utxo-set) * [Change Output](#change-output) * [Dust Output](#dust-output) * [Interface](#interface) * [Parameters](#parameters) * [Requested Output Set](#requested-output-set) * [Initial UTxO Set](#initial-utxo-set) * [Maximum Input Count](#maximum-input-count) * [Results](#results) * [Coin Selection](#coin-selection) * [Remaining UTxO Set](#remaining-utxo-set) * [Properties](#properties) * [Coverage of Payments](#coverage-of-payments) * [Correctness of Change](#correctness-of-change) * [Conservation of UTxO](#conservation-of-utxo) * [Conservation of Outputs](#conservation-of-outputs) * [Failure Modes](#failure-modes) * [UTxO Balance Insufficient](#utxo-balance-insufficient) * [UTxO Not Fragmented Enough](#utxo-not-fragmented-enough) * [UTxO Fully Depleted](#utxo-fully-depleted) * [Maximum Input Count Exceeded](#maximum-input-count-exceeded) * [Algorithms](#algorithms) * [Largest-First](#largest-first) * [State](#state) * [Available UTxO List](#available-utxo-list) * [Unpaid Output List](#unpaid-output-list) * [Accumulated Coin Selection](#accumulated-coin-selection) * [Computation](#computation) * [Random-Improve](#random-improve) * [Cardinality](#cardinality-1) * [State](#state-1) * [Available UTxO Set](#available-utxo-set) * [Accumulated Coin Selection](#accumulated-coin-selection-1) * [Computation](#computation-1) * [Phase 1: Random Selection](#phase-1-random-selection) * [Phase 2: Improvement](#phase-2-improvement) * [Termination](#termination-1) * [Rationale: how does this CIP achieve its goals?](#rationale-how-does-this-cip-achieve-its-goals) * [Motivating Principles](#motivating-principles) * [LargestFirst](#largest-first-2) * [Random-Improve](#random-improve-2) * [Principle 1: Dust Management](#principle-1-dust-management) * [Principle 2: Change Management](#principle-2-change-management) * [Principle 3: Performance Management](#principle-3-performance-management) * [External Resources](#external-resources) * [Self Organisation in Coin Selection](#self-organisation-in-coin-selection) * [Path to Active](#path-to-active) * [Acceptance Criteria](#acceptance-criteria) * [Implementation Plan](#implementation-plan) * [Reference Implementations](#reference-implementations) * [Largest-First](#largest-first-1) * [Random-Improve](#random-improve-1) * [Copyright](#copyright) ### Definitions This section defines common terms that are used throughout this document. #### Address An _address_ is a unique identifier that represents a payment recipient, a destination for a payment. Addresses are typically owned (and generated) by individual wallets. In general, coin selection algorithms are agnostic to the type of addresses used to identify payment recipients. Any address type may be used, so long as the set of possible addresses is totally-ordered. #### Coin Value A _coin value_ is a non-negative integer value that represents a number of [Lovelace](https://cardanodocs.com/cardano/monetary-policy/). One [Ada](https://cardanodocs.com/cardano/monetary-policy/) is _exactly_ equal to one million Lovelace. #### Transaction In a [UTxO](#utxo-set)-based blockchain, a _transaction_ is a binding between [inputs](#transaction-input) and [outputs](#transaction-output). ``` input #1 >---+ +---> output #1 \ / input #2 >-----+------+ / \ input #3 >---+ +---> output #2 ``` #### Transaction Input A _transaction input_ is a _unique reference_ to a single [output](#transaction-output) from a previous transaction. In general, coin selection algorithms are agnostic to the type of references used to identify outputs from previous transactions. Any type may be used, so long as the set of possible references is totally-ordered, and so long as it is possible to determine the [coin value](#coin-value) associated with any given reference. In the case of Cardano and other UTxO-based blockchains, this reference generally consists of a pair of values (**_h_**, **_n_**), where: * **_h_** is a _unique identifier_ for an existing transaction **_t_**; * **_n_** is a 0-based integer index into the output list of transaction **_t_**. #### Transaction Output A _transaction output_ consists of a pair of values (**_a_**, **_v_**), where: * **_a_** is the [address](#address) of a recipient. * **_v_** is the [coin value](#coin-value) to pay to the recipient. #### Spent Transaction Output A _spent transaction output_ is an [output](#transaction-output) from an existing [transaction](#transaction) that has already been referenced as an [input](#transaction-input) within a later transaction on the blockchain. In effect, the [coin value](#coin-value) associated with that transaction output has been _spent_, and cannot be reused. #### Unspent Transaction Output An _unspent transaction output_ is an [output](#transaction-output) from an existing [transaction](#transaction) that has not yet been referenced as an [input](#transaction-input) within a later transaction. In effect, the [coin value](#coin-value) associated with that transaction output has _not yet_ been spent, and is still available. #### UTxO Set A _UTxO set_ is a set of [unspent transaction outputs](#unspent-transaction-output). This term is commonly used in two ways: * To describe the _complete set_ of all unspent transaction outputs within a _blockchain_. * To describe the _subset_ of unspent transaction outputs associated with a _wallet_. The UTxO set of a wallet represents the total unspent value associated with that wallet. From the point of view of a coin selection algorithm, each member of a UTxO set can be represented as a pair of the form (**_u_**, **_v_**), where: * **_u_** is a unique reference to an [unspent output](#unspent-transaction-output) from a previous transaction. * **_v_** is the [coin value](#coin-value) associated with **_u_**. In general, coin selection algorithms are agnostic to the type of references used to identify unspent outputs from previous transactions. Any type may be used, so long as the set of possible references is totally-ordered. In practice however, the type of each unique reference **_u_** is equivalent to the type of a [transaction input](#transaction-input), as transaction inputs are simply references to unspent outputs from previous transactions. #### Change Output In the context of a wallet, a _change output_ is a [transaction output](#transaction-output) that transfers value _back_ to the wallet, rather than to an external payment recipient. The [address](#address) associated with a change output is generated by the wallet, and belongs to the wallet. Change ouputs are necessary in a UTxO-based blockchain, as the value associated with any given [transaction input](#transaction-input) must be spent _entirely_ by the transaction that includes it. When selecting entries from a [UTxO set](#utxo-set) to include as inputs in a transaction, a coin selection algorithm will generally not be able to select inputs that precisely match the total value of all payments to external recipients, and will therefore need to select more than is strictly required. To avoid the destruction of value, selection algorithms create _change outputs_ to return the excess value back to the wallet. #### Dust Output A _dust output_ is a [transaction output](#transaction-output) with an associated [coin value](#coin-value) that is: * small in comparison to payments typically made by the user of the wallet; * small in comparison to the marginal fee associated with including it in a transaction. Dust outputs are a problem, because even if the total value of dust in a wallet is more than enough to cover a given payment amount, if we attempt to include that dust in a given transaction, we may run out of space (by reaching the [transaction size limit](#the-transaction-size-limitation)) before we can cover the target amount. ### Interface All coin selection algorithms used by Cardano Wallet implement a _common interface_. At the most fundamental level, a coin selection algorithm is a _mathematical function_ that when applied to a [requested output set](#requested-output-set) and an [initial UTxO set](#initial-utxo-set), will produce a [coin selection](#coin-selection): the basis for a [transaction](#transaction) in a UTxO-based blockchain. This section describes: * the [parameters](#parameters) accepted by all coin selection algorithms; * the [results](#results) they produce when successful; * the [error conditions](#failure-modes) that may occur on failure; * the [properties](#properties) that apply to all coin selection algorithms: mathematical laws governing the relationships between parameters and results. In this section, the terms _coin selection algorithm_ and _coin selection function_ will be used interchangeably. #### Parameters All coin selection functions accept the following parameters: 1. **Requested Output Set** A list of payments to be made to recipient addresses, encoded as a list of [transaction outputs](#transaction-output). 2. **Initial UTxO Set** A [UTxO set](#utxo-set) from which the coin selection algorithm can select entries, to cover payments listed in the [requested output set](#requested-output-set). In the context of a wallet, this parameter would normally be assigned with the wallet's complete [UTxO set](#utxo-set), giving the coin selection algorithm access to the total value associated with that wallet. 3. **Maximum Input Count** An _upper bound_ on the number of UTxO entries that the coin selection algorithm is permitted to select from the [initial UTxO set](#initial-utxo-set). This parameter is necessary for blockchains that impose an upper limit on the size of transactions. #### Results All coin selection functions produce the following result values: 1. **Coin Selection** A _coin selection_ is the basis for a [transaction](#transaction) in a UTxO-based blockchain. It is a record with three fields: * A set of **_inputs_**, equivalent to a subset of the [initial UTxO set](#initial-utxo-set). From the point of view of a _wallet_, this represents the value that has been selected from the wallet in order to cover the total payment value. * A set of **_outputs_** (see [transaction output](#transaction-output)). Represents the set of payments to be made to recipient addresses. * A set of **_change values_** (see [change output](#change-output)), where each change value is simply a [coin value](#coin-value). From the point of view of a _wallet_, this represents the change to be returned to the wallet. 2. **Remaining UTxO Set** The _remaining UTxO set_ is a subset of the [initial UTxO set](#initial-utxo-set). It represents the set of values that remain after the coin selection algorithm has removed values to pay for entries in the [requested output set](#requested-output-set). In the context of a _wallet_, if a coin selection algorithm is applied to the wallet's _complete_ UTxO set, then the _remaining_ UTxO set represents the _updated_ UTxO set of that wallet. #### Properties All coin selection algorithms satisfy a common set of _properties_: general rules that govern the relationship between the _parameters_ supplied to coin selection functions and the _results_ they are allowed to produce. ##### Coverage of Payments This property states that the total value of _inputs_ in the resulting [coin selection](#coin-selection) result is sufficient to _cover_ the total value of the [requested output set](#requested-output-set). In particular: * **_v_**selected ≥ **_v_**requested Where: * **_v_**requested is the total value of the [requested output set](#requested-output-set) * **_v_**selected is the total value of the _inputs_ field of the [coin selection](#coin-selection) result. ##### Correctness of Change This property states that the correct amount of _change_ was generated. In particular: * **_v_**selected = **_v_**requested + **_v_**change Where: * **_v_**change is the total value of the _change_ field of the [coin selection](#coin-selection) result. * **_v_**requested is the total value of the [requested output set](#requested-output-set) * **_v_**selected is the total value of the _inputs_ field of the [coin selection](#coin-selection) result. ##### Conservation of UTxO This property states that every entry in the [initial UTxO set](#initial-utxo-set) is included in _either_ the inputs set of the generated [coin selection](#coin-selection), _or_ in the [remaining UTxO set](#remaining-utxo-set), but _not both_. * If a UTxO entry _is_ selected by the coin selection algorithm, it is included in the [coin selection](#coin-selection) inputs set. * If a UTxO entry is _not_ selected by the coin selection algorithm, it is included in the [remaining UTxO set](#remaining-utxo-set). The following laws hold: * **_U_**initial ⊃ **_U_**remaining * **_U_**initial ⊇ **_U_**selected And: * **_U_**remaining ∩ **_U_**selected = ∅ * **_U_**remaining ⋃ **_U_**selected = **_U_**initial Where: * **_U_**initial is the [initial UTxO set](#initial-utxo-set). * **_U_**remaining is the [remaining UTxO set](#remaining-utxo-set). * **_U_**selected is the value of the _inputs_ field of the [coin selection](#coin-selection) result. ##### Conservation of Outputs This property states that the [requested output set](#requested-output-set) is _conserved_ in the [coin selection](#coin-selection) result. In particular, the _outputs_ field of the [coin selection](#coin-selection) result should be _equal to_ the [requested output set](#requested-output-set). #### Failure Modes There are a number of ways in which a coin selection algorithm can fail: * **UTxO Balance Insufficient** This failure occurs when the total value of the entries within the [initial UTxO set](#initial-utxo-set) (the amount of money _available_) is _less than_ the the total value of all entries in the [requested output set](#requested-output-set) (the amount of money _required_). * **UTxO Not Fragmented Enough** This failure occurs when the _number_ of entries in the [initial UTxO set](#initial-utxo-set) is _smaller than_ the number of entries in the [requested output set](#requested-output-set), for algorithms that impose the restriction that a single UTxO entry can only be used to pay for _at most one_ output. * **UTxO Fully Depleted** This failure occurs if the algorithm depletes all entries from the [initial UTxO set](#initial-utxo-set) _before_ it is able to pay for all outputs in the [requested output set](#requested-output-set). This can happen _even if_ the total value of entries within the [initial UTxO set](#initial-utxo-set) is _greater than_ the total value of all entries in the [requested output set](#requested-output-set), due to various restrictions that coin selection algorithms impose on themselves when selecting UTxO entries. * **Maximum Input Count Exceeded** This failure occurs when another input must be selected by the algorithm in order to continue making progress, but doing so will increase the size of the resulting selection beyond an acceptable limit, specified by the [maximum input count](#maximum-input-count) parameter. ### Algorithms This section describes the coin selection algorithms used by Cardano Wallet, along with step-by-step descriptions of the computations involved. All algorithms implement a _common interface_, as described in the [Interface](#interface) section. There are two main algorithms used by Cardano Wallet: * [Largest-First](#largest-first) * [Random-Improve](#random-improve) In general, Cardano Wallet gives _priority_ to the [Random-Improve](#random-improve) algorithm, as experimental evidence shows that it performs better at [minimising dust](#goals) and maintaining a UTxO set with [useful outputs](#goals). (See [Self Organisation in Coin Selection](#self-organisation-in-coin-selection) for more details.) However, in rare cases, the [Random-Improve](#random-improve) algorithm may fail to produce a result. In such cases, Cardano Wallet will fall back to the [Largest-First](#largest-first) algorithm. #### Largest-First The **Largest-First** coin selection algorithm considers UTxO set entries in _descending order of value_, from largest to smallest. When applied to a set of [requested outputs](#requested-output-set), the algorithm repeatedly selects entries from the [initial UTxO set](#initial-utxo-set) until the total value of selected entries is _greater than or equal to_ the total value of requested outputs. The name of the algorithm is taken from the idea that the **largest** UTxO entry is always selected **first**. Specifically: > A given UTxO entry **_u_1** with > value **_v_1** can be selected if and only if there is no other > unselected entry **_u_2** with value **_v_2** where > **_v_2** > **_v_1**. ##### State At all stages of processing, the algorithm maintains the following pieces of state: 1. **Available UTxO List** This is initially equal to the [initial UTxO set](#initial-utxo-set), sorted into _descending order of coin value_. The _head_ of the list is always the remaining UTxO entry with the _largest coin value_. Entries are incrementally removed from the _head_ of the list as the algorithm proceeds, until enough value has been selected. 2. **Selected UTxO Set** This is initially equal to the empty set. ##### Computation The algorithm proceeds according to the following sequence of steps: * **Step 1** If the [available UTxO list](#available-utxo-list) is _empty_: * Terminate with a [UTxO Balance Insufficient](#utxo-balance-insufficient) error. If the [available UTxO list](#available-utxo-list) is _not empty_: * Remove an UTxO entry from the head of the [available UTxO list](#available-utxo-list) and add it to the [selected UTxO set](#selected-utxo-set). * **Step 2** Compare the total size **_n_**selected of the [selected UTxO set](#selected-utxo-set) with the [maximum input count](#maximum-input-count) **_n_**max. * If **_n_**selected > **_n_**max then: * Terminate with a [Maximum Input Count Exceeded](#maximum-input-count-exceeded) error. * If **_n_**selected ≤ **_n_**max then: * Go to step 3. * **Step 3** Compare the total value **_v_**selected of the [selected UTxO set](#selected-utxo-set) to the total value **_v_**requested of the [requested output set](#requested-output-set): * If **_v_**selected < **_v_**requested then go to step 1. * If **_v_**selected ≥ **_v_**requested then go to step 4. * **Step 4** Return a [coin selection](#coin-selection) result where: * The _inputs_ set is equal to the [selected UTxO set](#selected-utxo-set). * The _outputs_ set is equal to the [requested output set](#requested-output-set). * If **_v_**selected > **_v_**requested then: * The _change_ set contains just a single [coin](#coin-value) of value (**_v_**selected − **_v_**requested). * If **_v_**selected = **_v_**requested then: * The _change_ set is empty. #### Random-Improve The **Random-Improve** coin selection algorithm works in _two phases_: * In the **first phase**, the algorithm iterates through each of the [requested outputs](#requested-output-set) in _descending order of coin value_, from _largest_ to _smallest_. For each output, the algorithm repeatedly selects entries _at random_ from the [initial UTxO set](#initial-utxo-set), until each requested output has been associated with a set of UTxO entries whose _total value_ is enough to pay for that ouput. * In the **second phase**, the algorithm attempts to _expand_ each existing UTxO selection with _additional_ values taken at random from the [initial UTxO set](#initial-utxo-set), to the point where the total value of each selection is as close as possible to _twice_ the value of its associated output. After the above phases are complete, for each output of value **_v_**output and accompanying UTxO selection of value **_v_**selection, the algorithm generates a _single_ change output of value **_v_**change, where: > **_v_**change > = **_v_**selection > − **_v_**output Since the goal of the second phase was to expand each selection to the point where its total value is _approximately twice_ the value of its associated output, this corresponds to a change output whose target value is _approximately equal_ to the value of the output itself: > **_v_**change > = **_v_**selection > − **_v_**output > > **_v_**change > ≈ 2**_v_**output > − **_v_**output > > **_v_**change > ≈ **_v_**output ##### Cardinality The Random-Improve algorithm imposes the following cardinality restriction: * Each entry from the [initial UTxO set](#initial-utxo-set) is used to pay for _at most one_ output from the [requested output set](#requested-output-set). As a result of this restriction, the algorithm will fail with a [UTxO Not Fragmented Enough](#utxo-not-fragmented-enough) error if the number of entries in the [initial UTxO set](#initial-utxo-set) is _smaller than_ the number of entries in the [requested output set](#requested-output-set). ##### State At all stages of processing, the algorithm maintains the following pieces of state: 1. **Available UTxO Set** This is initially equal to the [initial UTxO set](#initial-utxo-set). 2. **Accumulated Coin Selection** The accumulated coin selection is a [coin selection](#coin-selection) where all fields are initially equal to the _empty set_. ##### Computation The algorithm proceeds in two phases. - **Phase 1: Random Selection** In this phase, the algorithm iterates through each of the [requested outputs](#requested-output-set) in descending order of coin value, from largest to smallest. For each output of value **_v_**, the algorithm repeatedly selects entries at **random** from the [available UTxO set](#available-utxo-set), until the _total value_ of selected entries is greater than or equal to **_v_**. The selected entries are then _associated with_ that output, and _removed_ from the [available UTxO set](#available-utxo-set). This phase ends when _every_ output has been associated with a selection of UTxO entries. - **Phase 2: Improvement** In this phase, the algorithm attempts to improve upon each of the UTxO selections made in the previous phase, by conservatively expanding the selection made for each output in order to generate improved change values. During this phase, the algorithm: * processes outputs in _ascending order of coin value_. * continues to select values from the [available UTxO set](#available-utxo-set). * incrementally populates the [accumulated coin selection](#accumulated-coin-selection-1). For each output of value **_v_**, the algorithm: 1. **Calculates a _target range_** for the total value of inputs used to pay for that output, defined by the triplet: (_minimum_, _ideal_, _maximum_) = (**_v_**, 2**_v_**, 3**_v_**) 2. **Attempts to improve upon the existing UTxO selection** for that output, by repeatedly selecting additional entries at random from the [available UTxO set](#available-utxo-set), stopping when the selection can be improved upon no further. A selection with value **_v_1** is considered to be an _improvement_ over a selection with value **_v_0** if **all** of the following conditions are satisfied: * **Condition 1**: we have moved closer to the _ideal_ value: abs (_ideal_ − **_v_1**) < abs (_ideal_ − **_v_0**) * **Condition 2**: we have not exceeded the _maximum_ value: **_v_1** ≤ _maximum_ * **Condition 3**: when counting cumulatively across all outputs considered so far, we have not selected more than the _maximum_ number of UTxO entries specified by [Maximum Input Count](#maximum-input-count). 3. **Creates a _change value_** for the output, equal to the total value of the _improved UTxO selection_ for that output minus the value **_v_** of that output. 4. **Updates the [accumulated coin selection](#accumulated-coin-selection-1)**: * Adds the _output_ to the _outputs_ field; * Adds the _improved UTxO selection_ to the _inputs_ field; * Adds the _change value_ to the _change values_ field. This phase ends when every output has been processed, **or** when the [available UTxO set](#available-utxo-set) has been exhausted, whichever occurs sooner. ##### Termination When both phases are complete, the algorithm terminates. The [accumulated coin selection](#accumulated-coin-selection-1) is returned to the caller as the [coin selection](#coin-selection) result. The [available UTxO set](#available-utxo-set) is returned to the caller as the [remaining UTxO set](#remaining-utxo-set) result. ## Rationale ### Largest-First \- ### Random-Improve There are several motivating principles behind the design of the algorithm. #### Principle 1: Dust Management The probability that random selection will choose dust entries from a UTxO set _increases_ with the proportion of dust in the set. Therefore, for a UTxO set with a large amount of dust, there's a high probability that a random subset will include a large amount of dust. Over time, selecting entries randomly in this way will tend to _limit_ the amount of dust that accumulates in the UTxO set. #### Principle 2: Change Management As mentioned in the [Goals](#goals-of-coin-selection-algorithms) section, it is desirable that coin selection algorithms, over time, are able to create UTxO sets that have _useful_ outputs: outputs that will allow us to process future payments with a _reasonably small_ number of inputs. If for each payment request of value **_v_** we create a change output of _roughly_ the same value **_v_**, then we will end up with a distribution of change values that matches the typical value distribution of payment requests. > :bulb: **Example** > > Alice often buys bread and other similar items that cost around €1.00 each. > > When she instructs her wallet software to make a payment for around > €1.00, the software attempts to select a set of unspent transaction outputs > with a total value of around €2.00. > > As she frequently makes payments for similar amounts, transactions created by > her wallet will also frequently produce change coins of around €1.00 in value. > > Over time, her wallet will self-organize to contain multiple coins of around > €1.00, which are useful for the kinds of payments that Alice frequently makes. #### Principle 3: Performance Management Searching the UTxO set for additional entries to _improve_ our change outputs is _only_ useful if the UTxO set contains entries that are sufficiently small enough. But it is precisely when the UTxO set contains many small entries that it is less likely for a randomly-chosen UTxO entry to push the total above the upper bound. ### External Resources #### Self Organisation in Coin Selection > | **Title** | Self Organisation in Coin Selection | > |:--|:--| > | **Author** | [Edsko de Vries](http://www.edsko.net/) | > | **Year** | 2018 | > | **Location** | https://iohk.io/en/blog/posts/2018/07/03/self-organisation-in-coin-selection/ | > > This article introduces the [Random-Improve](#random-improve) coin selection > algorithm, invented by [Edsko de Vries](http://www.edsko.net/). > > It describes the three principles of self-organisation that inform the > algorithm's design, and provides experimental evidence to demonstrate the > algorithm's effectiveness at maintaining healthy UTxO sets over time. ## Path to Active ### Acceptance Criteria - [x] There exists one or more reference implementations with appropriate testing illustrating the various properties of coin-selection stated in this document. ### Implementation Plan #### Reference Implementations ##### Largest-First Reference implementations of the [Largest-First](#largest-first) algorithm are available in the following languages: | _Language_ | _Documentation_ | _Source_ | | -- | -- | -- | | **Haskell** | [Documentation](https://hackage.haskell.org/package/cardano-coin-selection/docs/Cardano-CoinSelection-Algorithm-LargestFirst.html) | [Source](https://hackage.haskell.org/package/cardano-coin-selection/docs/src/Cardano.CoinSelection.Algorithm.LargestFirst.html) | ##### Random-Improve Reference implementations of the [Random-Improve](#random-improve) algorithm are available in the following languages: | _Language_ | _Documentation_ | _Source_ | | -- | -- | -- | | **Haskell** | [Documentation](https://hackage.haskell.org/package/cardano-coin-selection/docs/Cardano-CoinSelection-Algorithm-RandomImprove.html) | [Source](https://hackage.haskell.org/package/cardano-coin-selection/docs/src/Cardano.CoinSelection.Algorithm.RandomImprove.html) | ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0003/Byron.md ================================================ # Byron key format - **Deprecated**: yes - **Summary**: used by old versions of Daedalus to generate addresses starting with `Ddz`. ## Code ```js function generateMasterKey(seed) { return hashRepeatedly(seed, 1); } function hashRepeatedly(key, i) { (iL, iR) = HMAC ( hash=SHA512 , key=key , message="Root Seed Chain " + UTF8NFKD(i) ); let prv = tweakBits(SHA512(iL)); if (prv[31] & 0b0010_0000) { return hashRepeatedly(key, i+1); } return (prv + iR); } function tweakBits(data) { // * clear the lowest 3 bits // * clear the highest bit // * set the highest 2nd bit data[0] &= 0b1111_1000; data[31] &= 0b0111_1111; data[31] |= 0b0100_0000; return data; } ``` ## Test vectors
Requires no iteration recovery phrase ``` roast crime bounce convince core happy pitch safe brush exit basic among ``` master key ``` 60f6e2b12f4c51ed2a42163935fd95a6c39126e88571fe5ffd0332a4924e5e5e9ceda72e3e526a625ea86d16151957d45747fff0f8fcd00e394b132155dfdfc2918019cda35f1df96dd5a798da4c40a2f382358496e6468e4e276db5ec35235f ```
---
Requires 4 iterations recovery phrase ``` legend dismiss verify kit faint hurdle orange wine panther question knife lion ``` master key ``` c89fe21ec722ee174be77d7f91683dcfd307055b04613f064835bf37c58f6a5f362a4ce30a325527ff66b6fbaa43e57c1bf14edac749be3d75819e7759e9e6c82b264afa7c1fd5b3cd51be3053ccbdb0224f82f7d1c7023a96ce97cb4efca945 ```
================================================ FILE: CIP-0003/CIP-0003.md ================================================ Moved to [CIP-0003/README.md](./README.md). ================================================ FILE: CIP-0003/Icarus.md ================================================ # Icarus key format - **Deprecated**: no - **Summary**: Used by Yoroi during the Byron-era (with Byron-style addresses starting with Ae2). Currently used for all Shelley-era wallets. *Note*: Also supports setting an extra passphrase as an arbitrary byte array of any size (sometimes called a *mnemonic password*). This passphrase acts as a second factor applied to cryptographic key retrieval. When the seed comes from an encoded recovery phrase, the password can therefore be used to add extra protection in case where the recovery phrase were to be exposed. ## Code ```js function generateMasterKey(seed, password) { let data = PBKDF2 ( kdf=HMAC-SHA512 , iter=4096 , salt=seed , password=password , outputLen=96 ); return tweakBits(data); } function tweakBits(data) { // on the ed25519 scalar leftmost 32 bytes: // * clear the lowest 3 bits // * clear the highest bit // * clear the 3rd highest bit // * set the highest 2nd bit data[0] &= 0b1111_1000; data[31] &= 0b0001_1111; data[31] |= 0b0100_0000; return data; } ``` ## Test vectors
No passphrase recovery phrase ``` eight country switch draw meat scout mystery blade tip drift useless good keep usage title ``` master key ``` c065afd2832cd8b087c4d9ab7011f481ee1e0721e78ea5dd609f3ab3f156d245d176bd8fd4ec60b4731c3918a2a72a0226c0cd119ec35b47e4d55884667f552a23f7fdcd4a10c6cd2c7393ac61d877873e248f417634aa3d812af327ffe9d620 ```
---
With passphrase recovery phrase ``` eight country switch draw meat scout mystery blade tip drift useless good keep usage title ``` passphrase ``` foo (as utf8 bytes) ``` master key ``` 70531039904019351e1afb361cd1b312a4d0565d4ff9f8062d38acf4b15cce41d7b5738d9c893feea55512a3004acb0d222c35d3e3d5cde943a15a9824cbac59443cf67e589614076ba01e354b1a432e0e6db3b59e37fc56b5fb0222970a010e ```
## Trezor When used < 24 words, the algorithm is the same as **Icarus** When using 24 words, due to incorrect removal of the [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic) entropy checksum bits (via integer division by 8, incorrectly assuming the entropy checksum is always less than 8 bits), the entropy bytes are passed into the `generateMasterKey()` function together with the checksum which for 24-word mnemonics happens to be 8 bits = 1 byte. This bug has been identified and documented in the following Trezor firmware pull request: https://github.com/trezor/trezor-firmware/pull/1388 *Note*: Trezor also allows users to set an additional [passphrase](https://wiki.trezor.io/Passphrase) that works exactly the same as Icarus passphrase ================================================ FILE: CIP-0003/Ledger_BitBox02.md ================================================ # Ledger/BitBox02 key format - **Deprecated**: no - **Summary**: Used by Ledger hardware wallets Reference implementation by Ledger: [HDEd25519.py](https://github.com/LedgerHQ/orakolo/blob/0b2d5e669ec61df9a824df9fa1a363060116b490/src/python/orakolo/HDEd25519.py) Implementation by BitBox02: [keystore.c](https://github.com/digitalbitbox/bitbox02-firmware/blob/1e36dbfb3c71c3a9d8ea81fe6fad13b18dd735a4/src/keystore.c#L676-L709) *Note*: Ledger and BitBox02 also allow users to set an additional [passphrase](https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security) ## Code ```js function generateMasterKey(seed, password) { let data = PBKDF2 ( kdf=HMAC-SHA512 , iter=2048 , salt="mnemonic" + UTF8NFKD(password) , password=UTF8NFKD(spaceSeparated(toMnemonic(seed))) , outputLen=64 ); let cc = HMAC ( hash=SHA256 , key="ed25519 seed" , message=UTF8NFKD(1) + data ); let (iL, iR) = hashRepeatedly(data); return (tweakBits(iL) + iR + cc); } function hashRepeatedly(message) { let (iL, iR) = HMAC ( hash=SHA512 , key="ed25519 seed" , message=message ); if (iL[31] & 0b0010_0000) { return hashRepeatedly(iL + iR); } return (iL, iR); } function tweakBits(data) { // * clear the lowest 3 bits // * clear the highest bit // * set the highest 2nd bit data[0] &= 0b1111_1000; data[31] &= 0b0111_1111; data[31] |= 0b0100_0000; return data; } ``` ## Test vectors
No passphrase no iterations recovery phrase ``` recall grace sport punch exhibit mad harbor stand obey short width stem awkward used stairs wool ugly trap season stove worth toward congress jaguar ``` master key ``` a08cf85b564ecf3b947d8d4321fb96d70ee7bb760877e371899b14e2ccf88658104b884682b57efd97decbb318a45c05a527b9cc5c2f64f7352935a049ceea60680d52308194ccef2a18e6812b452a5815fbd7f5babc083856919aaf668fe7e4 ```
---
No passphrase with iterations recovery phrase ``` correct cherry mammal bubble want mandate polar hazard crater better craft exotic choice fun tourist census gap lottery neglect address glow carry old business ``` master key ``` 587c6774357ecbf840d4db6404ff7af016dace0400769751ad2abfc77b9a3844cc71702520ef1a4d1b68b91187787a9b8faab0a9bb6b160de541b6ee62469901fc0beda0975fe4763beabd83b7051a5fd5cbce5b88e82c4bbaca265014e524bd ```
---
With passphrase recovery phrase ``` abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon art ``` passphrase ``` foo (as utf8 bytes) ``` master key ``` f053a1e752de5c26197b60f032a4809f08bb3e5d90484fe42024be31efcba7578d914d3ff992e21652fee6a4d99f6091006938fac2c0c0f9d2de0ba64b754e92a4f3723f23472077aa4cd4dd8a8a175dba07ea1852dad1cf268c61a2679c3890 ```
================================================ FILE: CIP-0003/README.md ================================================ --- CIP: 3 Title: Wallet Key Generation Status: Active Category: Wallets Authors: - Matthias Benkort - Sebastien Guillemot Implementors: - Matthias Benkort - Sebastien Guillemot Discussions: - https://github.com/input-output-hk/implementation-decisions/pull/18 - https://github.com/cardano-foundation/cips/pull/33 - https://github.com/cardano-foundation/cips/pull/76 - https://github.com/cardano-foundation/cips/pull/132 Created: 2020-05-07 License: CC-BY-4.0 --- ## Abstract Many wallets utilize some way of mapping a sentence of words (easy to read and write for humans) uniquely back and forth to a sized binary data (harder to remember). This document outlines the various mapping algorithms used in the Cardano ecosystem. ## Motivation: why is this CIP necessary? The philosophy of cryptocurrencies is that you are in charge of your own finances. Therefore, it is very anti-thematic for wallet software to lock in a user by explicitly describing the algorithm used to derive keys for a wallet (both the master key and key derivation) To this end, this document outlines all the relevant key generation algorithms used in the Cardano ecosystem. ## Specification ### Recovery Phrase (mnemonic) Generation Conversion from a recovery phrase to entropy is the same as described in [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md). ### Hierarchical Deterministic Wallets In Cardano, hierarchical deterministic (abbrev. HD) wallets are similar to those described in [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). Notably, we use a variation called [ED25519-BIP32](https://github.com/input-output-hk/adrestia/raw/bdf00e4e7791d610d273d227be877bc6dd0dbcfb/user-guide/static/Ed25519_BIP.pdf). A reference implementation can be found [here](https://docs.rs/ed25519-bip32/). ### Master Key Generation The master key generation is the mean by which on turns an initial entropy into a secure cryptographic key. More specifically, the generation is a function from an initial seed to an extended private key (abbrev. XPrv) composed of: - 64 bytes: an extended Ed25519 secret key composed of: - 32 bytes: Ed25519 curve scalar from which few bits have been tweaked according to ED25519-BIP32 - 32 bytes: Ed25519 binary blob used as IV for signing - 32 bytes: chain code for allowing secure child key derivation #### History Throughout the years, Cardano has used different styles of master key generation: | Name | Used by | Address prefix in Byron | Is deprecated? | Is Recommended? | |-----------------------------------------|-----------------|-------------------------|----------------|-----------------| | [Byron](./Byron.md) | Daedalus | Ddz | Yes | No | | [Icarus](./Icarus.md) | Yoroi, Daedalus | Ae2 | No | Yes | | [Icarus-Trezor](./Icarus.md) | Trezor | Ae2 | No | No | | [Ledger/BitBox02](./Ledger_BitBox02.md) | Ledger/BitBox02 | Ae2 | No | No | ## Rationale: how does this CIP achieve its goals? This CIP is merely to document the existing standards and not to provide rationales for the various methods used. However, you can learn more at the following links: - [Adrestia documentation](https://cardano-foundation.github.io/cardano-wallet/concepts/master-key-generation) - [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) - [SLIP-0023](https://github.com/satoshilabs/slips/blob/master/slip-0023.md) ## Path to Active ### Acceptance Criteria - [x] Each generation method is documented and provides test vectors in a language-agnostic way. - [x] There exists reference implementations in various languages for each method. - [x] At least 2 Cardano wallets (e.g. Yoroi & Daedalus) implement these methods. ### Implementation Plan - [x] Implementation of each algorithm will be carried out in Yoroi and Daedalus (via cardano-wallet) by Emurgo and Input Output respectively. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0004/CIP-0004.md ================================================ Moved to [CIP-0004/README.md](./README.md). ================================================ FILE: CIP-0004/README.md ================================================ --- CIP: 4 Title: Wallet Checksums Status: Proposed Category: Wallets Authors: - Ruslan Dudin - Sebastien Guillemot Implementors: - Ruslan Dudin - Sebastien Guillemot Discussions: - https://forum.cardano.org/t/cip4-wallet-checksum/32819 - https://github.com/cardano-foundation/CIPs/pull/4 Created: 2019-05-01 License: Apache-2.0 --- ## Abstract We introduce a checksum algorithm to help users verify they are restoring the right wallet before the restoration actually takes place. ## Motivation: why is this CIP necessary? Users occasionally enter the wrong [mnemonic](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) for their wallet. In this case, they simply see a 0 ADA wallet after syncing is over. This not only wastes the user's time, in the worst case it makes them think they either lost all their ADA or think there is a bug in the wallet implementation. To solve this, we introduce a checksum that can be computed without having to perform wallet restoration. ## Specification First, it's important to note that the method for generating a checksum is heavily dependent on the type of wallet (ex: BIP44, etc.). We outline an algorithm that works with most, but not all, types of wallet. ### Requirements for checksum 1) Easily recomputed without access to mnemonic, private key or other similarly sensitive data 2) Does not reveal anything about the wallet (irreversible -- cannot tell addresses, private key, etc. from just seeing the checksum) 3) Negligible chance of collision 4) Easy to memorize for the user 5) Can be easily saved both digitally or on paper ### Implementation Outline To satisfy (1), the checksum SHOULD be seeded from the public key for the wallet. Notably, in the [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) case, it should come from the bip44 account derivation level's public key. **Note**: For HD wallets, the public key used SHOULD contain the chaincode also because we need to make sure that not just the public key, but all its child keys also, are properly generated. To satisfy (2) and (3), the a hash of the public key is used To satisfy (4) and (5), we generate for an *ImagePart* and a *TextPart*. The brain can roughly remember images allowing you to quickly dismiss checksums that look totally different. However, since images can sometimes be similar, a *TextPart* is also provided for double-checking. Additionally, if the user does not have access to a printer, the text part can be easily written down by hand on a piece of paper to satisfy (5). ## Rationale: how does this CIP achieve its goals? We first provide a template for the code, explain the template and then provide the parameterization we use for Cardano ```js function calculateChecksum(publicKeyHash: string /* note: lowercase hex representation */) { const hash = hash1(publicKeyHash); const [a, b, c, d] = hash_to_32(hash); // get a 4 byte value from the hash const alpha = `ABCDEJHKLNOPSTXZ`; // take 16 letters from the alphabet that are easy to distinguish // construct the TextPart from a group of letters and a group of numbers const letters = x => `${alpha[Math.floor(x / 16)]}${alpha[x % 16]}`; const numbers = `${((c << 8) + d) % 10000}`.padStart(4, '0'); const id = `${letters(a)}${letters(b)}-${numbers}`; return { hash, // used to generate the ImagePart id, // used as the TextPart }; } ``` ### TextPart rationale For ease of perception it seems that short alphanumeric sequences are the best for humans to remember, especially when letters and numbers are separated and not mixed together. #### Letter part For letters, we render the bytes in hex, but replace the alphanumeric used in hex with this letter-only alphabet: `A B C D E J H K L N O P S T X Z` This alphabet satisfies the following requirements: 1) Has exactly 16 letters (one-to-one mapping with 2 bytes in HEX) 1) Does not contain characters that look too much like each other 1) Minimizes occurrences of undesirable words in [this list](https://www.noswearing.com/fourletterwords.php). #### Number part The last two bytes are compressed to a 4-digit number. For this we will simply take the last 4 digits of the 16-bit integer number constructed from 2 bytes as `((A << 8) + B) % 10000` (zero-padded). This above produces 10000 unique values across all possible values of A and B and giving maximum of 7 potential collisions per value and 6.5 average collisions per value, which is the minimum, given the fact that we reduce maximum potential number 65536 to 4 digits. **Note**: resulting number is zero-padded to 4 digits. ### ImagePart rationale For the image, we take the result of `hash1` and use it as the seed for the [blockies](https://github.com/ethereum/blockies) library. This library in particular has the following benefits: - Has been audited - Used by other blockchains and therefore has common libraries for implementation **Note**: This library internally re-hashes its input to a 128-bit entropy string ### Hash algorithms used in Byron + ITN For `hash1`, we use `blake2b512`. [Blake2b](https://tools.ietf.org/html/rfc7693) is a standardized hash function that is used in Cardano for other purposes like key derivations. Reusing blake2b means one less dependency. We use `512` bytes of output to try and future-proof this algorithm (better to spread the entropy across more bits than needed than end up not capturing the full entropy in the future). For `hash_to_32` we use CRC32. We hash a second time for the following: 1) The *TextPart* is constructed from 4 bytes (2 for letters, 2 for numbers) and so we need to project the result of `hash1` down to 4 bytes. 2) We don't want to simply take the last 4 bytes of `hash1` because that would reveal part of the input used to generate the *ImagePart*. Although strictly speaking this should not be of a concern (since the result of `hash1` doesn't reveal any information about the original key), we take this as a precaution. 3) `CRC32` is used in the Byron implementation of Cardano as a checksum for addresses, meaning no additional dependency has to be added. Although there is no specification for CRC32 and many variations exist, in Cardano we use the CRC-32-IEEE variation. You can find a C implementation [here](https://github.com/cardano-foundation/ledger-app-cardano/blob/3f784d23c1b87df73cda552ef01428d3e2733237/src/crc32.c#L6) ### Hash algorithms used in Shelley mainnet 1) For `hash1`, we still use `blake2b512` but we now set the blake2b `personalization` to the the utf-8 byte equivalent of `wallets checksum` (exactly 16 utf-8 bytes in length) to avoid collision with any other standard that decides to hash a public key. 2) For `hash_to_32`, we no longer use `crc32` for the following reasons: - It has multiple competing implementations all called `crc32` (easily to get the wrong implementation library) - It requires building a lookup table, making it slower than other hashing algorithms for similar safety - Cardano no longer uses `crc32` in the Shelley mainnet as addresses now use [BIP173 - bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) which has its own checksum algorithm. Instead, we replace it with [FNV-1a](https://tools.ietf.org/html/draft-eastlake-fnv-10) in 32-bit mode. FNV-1a is fast, easy to implement inline and gives good empirical distribution. ### When no public key is present Note that a different construction is needed for wallet types which do not have a public key (such as a balance tracking application which simply manages a set of addresses). In the balanace tracking case, simply hashing the set of addresses used is possible, but it means that adding & removing an address would change the checksum (possibly unintuitive). Since the checksum is meant to represent the wallet itself, we also cannot run a checksum on the name of the wallet or any other user-inputted data. ## Path to Active ### Acceptance Criteria - [x] There exists a reference implementation with test vectors. - [ ] Checksums are adopted by two or more wallets. - [x] Yoroi ### Implementation Plan - [x] Reference implementations: - [Javascript](https://github.com/Emurgo/CIP4) ## Copyright This CIP is licensed under Apache-2.0 ================================================ FILE: CIP-0005/CIP-0005.md ================================================ Moved to [CIP-0005/README.md](./README.md). ================================================ FILE: CIP-0005/README.md ================================================ --- CIP: 5 Title: Common Bech32 Prefixes Category: Tools Status: Active Authors: - Matthias Benkort Implementors: N/A Discussions: - https://forum.cardano.org/t/cip5-common-bech32-prefixes/35189 - https://github.com/cardano-foundation/CIPs/pull/427 - https://github.com/cardano-foundation/CIPs/pull/342 - https://github.com/cardano-foundation/CIPs/pull/251 - https://github.com/cardano-foundation/CIPs/pull/177 - https://github.com/cardano-foundation/CIPs/pull/31 Created: 2020-05-28 License: Apache-2.0 --- ## Abstract This CIP defines a set of common prefixes (or so-called human-readable part in the [bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)) encoding format) for various bech32-encoded binary data across the Cardano eco-system. ## Motivation: why is this CIP necessary? Many tools used within the Cardano eco-system are manipulating binary data. Binary data are typically encoded as hexadecimal text strings when shown in a user interface (might it be a console, a url or a structured document from a server). From the user perspective, it can be difficult to distinguish between various encoded data. From the tools developer perspective, it can also be difficult to validate inputs based only on raw bytes (in particular when encoded data often have the same length). Therefore, we can leverage bech32 for binary data encoding, with a set of common prefixes that can be used across tools and software to disambiguate payloads. ## Specification We define the following set of common prefixes with their corresponding semantic. Any software willing to represent binary data in a human-friendly way should abide by these guidelines. Should a data-type be missing, we encourage developers to update this CIP and register a new prefix. ### Keys | Prefix | Meaning | Contents | | --- | --- | --- | | `acct_sk` | CIP-1852's account private key | Ed25519 private key | | `acct_vk` | CIP-1852's account public key | Ed25519 public key | | `acct_xsk` | CIP-1852's extended account private key | Ed25519-bip32 extended private key | | `acct_xvk` | CIP-1852's extended account public key | Ed25519 public key with chain code | | `acct_shared_sk` | CIP-1854's account private key | Ed25519 private key | | `acct_shared_vk` | CIP-1854's account public key | Ed25519 public key | | `acct_shared_xsk` | CIP-1854's extended account private key | Ed25519-bip32 extended private key | | `acct_shared_xvk` | CIP-1854's extended account public key | Ed25519 public key with chain code | | `addr_sk` | CIP-1852's address signing key | Ed25519 private key | | `addr_vk` | CIP-1852's address verification key | Ed25519 public key | | `addr_xsk` | CIP-1852's address extended signing key | Ed25519-bip32 extended private key | | `addr_xvk` | CIP-1852's address extended verification key | Ed25519 public key with chain code | | `addr_shared_sk` | CIP-1854's address signing key | Ed25519 private key | | `addr_shared_vk` | CIP-1854's address verification key | Ed25519 public key | | `addr_shared_xsk` | CIP-1854's address extended signing key | Ed25519-bip32 extended private key | | `addr_shared_xvk` | CIP-1854's address extended verification key | Ed25519 public key with chain code | | `cc_cold_sk` | CIP-1852’s constitutional committee cold signing key | Ed25519 private key | | `cc_cold_vk` | CIP-1852’s constitutional committee verification signing key | Ed25519 private key | | `cc_cold_xsk` | CIP-1852’s constitutional committee cold extended signing key | Ed25519-bip32 extended private key | | `cc_cold_xvk` | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code | | `cc_hot_sk` | CIP-1852’s constitutional committee hot signing key | Ed25519 private key | | `cc_hot_vk` | CIP-1852’s constitutional committee verification signing key | Ed25519 private key | | `cc_hot_xsk` | CIP-1852’s constitutional committee hot extended signing key | Ed25519-bip32 extended private key | | `cc_hot_xvk` | CIP-1852’s constitutional committee extended verification signing key | Ed25519 public key with chain code | | `cvote_sk` | CIP-36's vote signing key | Ed25519 private key | | `cvote_vk` | CIP-36's vote verification key | Ed25519 public key | | `drep_sk` | CIP-1852’s DRep signing key | Ed25519 private key | | `drep_vk` | CIP-1852’s DRep verification key | Ed25519 public key | | `drep_xsk` | CIP-1852’s DRep extended signing key | Ed25519-bip32 extended private key | | `drep_xvk` | CIP-1852’s DRep extended verification key | Ed25519 public key with chain code | | `gen_sk` | Genesis signing key | Ed25519 private key | | `gen_vk` | Genesis verification key | Ed25519 public key | | `gen_deleg_sk` | Genesis delegate private key | Ed25519 private key | | `gen_deleg_vk` | Genesis delegate public key | Ed25519 public key | | `gen_utxo_sk` | Genesis UTXO private key | Ed25519 private key | | `gen_utxo_vk` | Genesis UTXO public key | Ed25519 public key | | `kes_sk` | KES signing key | KES signing key | | `kes_vk` | KES verification key | KES verification key | | `policy_sk` | CIP-1855's policy private key | Ed25519 private key | | `policy_vk` | CIP-1855's policy public key | Ed25519 public key | | `pool_sk` | Pool operator signing key | Ed25519 private key | | `pool_vk` | Pool operator verification key | Ed25519 public key | | `pool_xsk` | Pool operator extended signing key | Ed25519-bip32 extended private key | | `pool_xvk` | Pool operator extended verification key | Ed25519 public key with chain code | | `root_sk` | CIP-1852's root private key | Ed25519 private key | | `root_vk` | CIP-1852's root public key | Ed25519 public key | | `root_xsk` | CIP-1852's extended root private key | Ed25519-bip32 extended private key | | `root_xvk` | CIP-1852's extended root public key | Ed25519 public key with chain code | | `root_shared_sk` | CIP-1854's root private key | Ed25519 private key | | `root_shared_vk` | CIP-1854's root public key | Ed25519 public key | | `root_shared_xsk` | CIP-1854's extended root private key | Ed25519-bip32 extended private key | | `root_shared_xvk` | CIP-1854's extended root public key | Ed25519 public key with chain code | | `stake_sk` | CIP-1852's stake address signing key | Ed25519 private key | | `stake_vk` | CIP-1852's stake address verification key | Ed25519 public key | | `stake_xsk` | CIP-1852's extended stake address signing key | Ed25519-bip32 extended private key | | `stake_xvk` | CIP-1852's extended stake address verification key | Ed25519 public key with chain code | | `stake_shared_sk` | CIP-1854's stake address signing key | Ed25519 private key | | `stake_shared_vk` | CIP-1854's stake address verification key | Ed25519 public key | | `stake_shared_xsk` | CIP-1854's extended stake address signing key | Ed25519-bip32 extended private key | | `stake_shared_xvk` | CIP-1854's extended stake address verification key | Ed25519 public key with chain code | | `vrf_sk` | VRF signing key | VRF signing key | | `vrf_vk` | VRF verification key | VRF verification key | ### Hashes | Prefix | Meaning | Contents | | --- | --- | --- | | `asset` | Fingerprint of a native asset for human comparison | See [CIP-0014] | | `pool` | Pool operator verification key hash (pool ID) | blake2b\_224 digest of an operator verification key | | `script` | Script hash | blake2b\_224 digest of a serialized transaction script | | `addr_vkh` | Address verification key hash | blake2b\_224 digest of a payment verification key | | `addr_shared_vkh` | Shared address verification key hash | blake2b\_224 digest of a payment verification key | | `policy_vkh` | Policy verification key hash | blake2b\_224 digest of a policy verification key | | `stake_vkh` | Stake address verification key hash | blake2b\_224 digest of a delegation verification key | | `stake_shared_vkh` | Shared stake address verification key hash | blake2b\_224 digest of a delegation verification key | | `req_signer_vkh` | Required signer verification key hash | blake2b\_224 digest of a required signer verification key | | `vrf_vkh` | VRF verification key hash | blake2b\_256 digest of a VRF verification key | | `datum` | Output datum hash | blake2b\_256 digest of output datum | | `script_data` | Script data hash | blake2b\_256 digest of script data | | `drep_vkh` | Delegate representative verification key hash | blake2b\_224 digest of a delegate representative verification key | | `cc_cold_vkh` | Constitutional committee cold verification key hash | blake2b\_224 digest of a constitutional committee cold verification key | | `cc_hot_vkh` | Constitutional committee hot verification key hash | blake2b\_224 digest of a constitutional committee hot verification key | ### Miscellaneous | Prefix | Meaning | Contents | | --- | --- | --- | | `addr` | Mainnet address | Network tag, payment credential and optional stake credential | | `addr_test` | Testnet address | Network tag, payment credential and optional stake credential | | `stake` | Mainnet stake address | Network tag and stake credential | | `stake_test` | Testnet stake address | Network tag and stake credential | | `drep` | DRep identifier | DRep credential, see [CIP-0129] | | `cc_cold` | Constitutional committee cold identifier | Constitutional committee cold credential, see [CIP-0129] | | `cc_hot` | Constitutional committee hot identifier | Constitutional committee hot credential, see [CIP-0129] | | `gov_action` | Governance action identifier | Governance action ID, see [CIP-0129] | ### Deprecated Governance Prefixes The some governance prefixes contained within the tables above were originally defined via [CIP-0105]. With the authoring of and acceptance of [CIP-0129], the community decide to replace some governance prefix definitions whilst depreciating others. Further details on the depreciation and replacement of definitions can be seen via [CIP-105 Deprecated Governance ID Definition](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0105#deprecated-governance-id-definition). Below is a table of entries of prefix definitions which were defined via [CIP-0105], but have now been marked as depreciated as [CIP-0129] defined replacements.\ The [CIP-0129] definitions are included within the tables above. | Prefix | Meaning | Contents | | --- | --- | --- | | `drep` | Delegate representative verification key hash (DRep ID) | blake2b\_224 digest of a delegate representative verification key | | `drep_script` | Delegate representative script hash (DRep ID) | blake2b\_224 digest of a serialized delegate representative script | | `cc_cold` | Constitutional committee cold verification key hash (cold credential) | blake2b\_224 digest of a constitutional committee cold verification key | | `cc_cold_script` | Constitutional committee cold script hash (cold credential) | blake2b\_224 digest of a serialized constitutional committee cold script | | `cc_hot` | Constitutional committee hot verification key hash (hot credential) | blake2b\_224 digest of a constitutional committee hot verification key | | `cc_hot_script` | Constitutional committee hot script hash (hot credential) | blake2b\_224 digest of a serialized constitutional committee hot script | ## Rationale: how does this CIP achieve its goals? ### About the `_test` suffix Address already contains a discriminant tag, yet it requires one to peek at the internal binary payload. With Base58-encoded addresses, people have been used to look at first few characters and distinguish address this way. Not only this is cumbersome, but it is also made harder with both Shelley and Bech32-encoded addresses. On the one hand, the "common" part of the internal payload is much less than in Byron addresses and thus, the first bytes of the payload are varying much more. Plus, the bech32 prefix which can now be fixed makes it even more error-prone. Therefore, having a clear human-readable indicator regarding the network discrimination is useful. ### About `addr` Addresses probably are the most user-facing object in the current Cardano eco-system. Being able to clearly identify them > :bulb: Open question: with side-chains and multi-currencies coming soon, would it make sense to include the currency in the bech32 prefix? e.g. `ada1...` or `ada_addr1.` ### About `stake` Stake _addresses_ are references to reward account. They are used in many manipulation involving rewards (registering stake key, delegating, fetching reward balance etc..). We therefore make it a "first-class" object and assign it a dedicated prefix. ### About `sk` & `vk` Both are rather transparent abbreviations for **s**igning **k**ey and **v**erification **k**ey. ### About `xsk` & `xvk` The prefix `x` is typically used in cryptography to refer to e**x**tended keys (e.g. `xpub`, `xprv` ...). Following this convention, we prefix `sk` and `vk` as such when they refer to extended keys. ### About `vkh` An abbreviation for **v**erification **k**ey **h**ash. Verification key hashes are commonly utilized throughout the Cardano eco-system. For example, they're used in stake pool registration and retirement certificates, stake key registration, delegation, and deregistration certificates, etc. As a result, it seems useful to have a human-readable prefix by which one can discern the different kinds of verification key hashes. ### Backwards compatibility The only prior work done towards that direction has been [jcli](https://input-output-hk.github.io/jormungandr/jcli/introduction.html). Historically, prefixes evolved very organically and without any agreed-upon standard. jcli is however only compatible with Jörmungandr and is not intended to be compatible with the cardano-node. Therefore, there's little concern regarding compatibility here. ## Path to Active ### Acceptance Criteria - [x] There is a variety of tools and services utilizing this standard: - [x] Trezor, Ledger - [x] cardano-cli - [x] cardano-wallet - [x] Blockfrost - [x] cardanoscan, cexplorer - [x] cardano-signer - ... and more ### Implementation Plan - Available JavaScript library: [cip5-js](https://www.npmjs.com/package/@dcspark/cip5-js) ## Changelog In order to make it easy to keep up with updates to this CIP, we include the following table as a log of the changes sorted in decreasing order of date. Changes to the CIP should include an entry at the top of the table that includes a unique sequential identifier of the change, the date of the changes (in the format YYYY-MM-DD), a summary of the changes, and a link to the pull request that introduces the changes. | ID | Date | Summary of changes | Pull Request | | --- | --- | --- | --- | | 2 | 2025-05-13 | Defined bech32 prefixes for extended pool operator keys | [#1036](https://github.com/cardano-foundation/CIPs/pull/1036) | | 1 | 2025-04-22 | Defined bech32 prefixes for genesis keys and created changelog. | [#1027](https://github.com/cardano-foundation/CIPs/pull/1027) | ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). [CIP-0014]: https://github.com/cardano-foundation/CIPs/blob/645243e30b5aae109a70ec2b47af70dcc808bc56/CIP-0014 [CIP-0105]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0105/README.md [CIP-0129]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0129/README.md ================================================ FILE: CIP-0006/CIP-0006.md ================================================ Moved to [CIP-0006/README.md](./README.md). ================================================ FILE: CIP-0006/README.md ================================================ --- CIP: 6 Title: Stake Pool Extended Metadata Status: Active Category: Tools Authors: - Markus Gufler - Mike Fullman Implementors: - pooltool.io - cexplorer.io Discussions: - https://github.com/cardano-foundation/CIPs/pull/15 Created: 2020-07-20 License: CC-BY-4.0 --- ## Abstract This CIP defines the concept of extended metadata for pools that is referenced from the pool registration data stored on chain. ## Motivation: why is this CIP necessary? As the ecosystem around Cardano stake pools proliferate so will the desire to slice, organize and search pool information dynamically. Currently the metadata referenced on chain provides 512 bytes that can be allocated across the four information categories ([delegation-design-specification Section 4.2)](https://github.com/IntersectMBO/cardano-ledger/releases/latest/download/shelley-delegation.pdf): | key | Value | Rules | | --- | --- | --- | | `ticker` | Pool ticker. uppercase | 5 Characters Maximum, Uppercase letters and numbers | | `description` | Pool Description. Text that describes the pool | 50 Characters Maximum | | `homepage` | A website URL for the pool | 64 Characters Maximum, must be a valid URL | | `name` | A name for the pool | 50 Characters Maximum | Many additional attributes can be envisioned for future wallets, pool explorers, and information aggregators. The proposal below outlines an initial strategy for capturing this extended metadata. ## Specification > **Note** Updated: 2020-11-24 2nd key-pair for validation 2021-02-08 json schema ### On Chain referenced (main) metadata file We define two more fields for the on chain referenced metadata file that references another JSON file on a URL with the extended metadata. The proposed metadata is as follows: | key | Value | Rules | | --- | --- | --- | | `ticker` | Pool ticker. uppercase | 5 Characters Maximum, Uppercase letters and numbers | | `description` | Pool Description. Text that describes the pool | 50 Characters Maximum | | `homepage` | A website URL for the pool| 64 Characters Maximum, must be a valid URL | | `name` | A name for the pool | 50 Characters Maximum | | `extDataUrl` | A URL for extended metadata | optional, 128 Characters Maximum, must be a valid URL | | `extSigUrl` | A URL with the extended metadata signature | optional, 128 Characters Maximum, must be a valid URL | | `extVkey` | the public Key for verification | optional, 68 Characters | In order to include the additional ext Field data, we suggest increasing the maximum size of the main metadata file from currently 512 to 1024 bytes. ### Extended Metadata - flexible but validable In difference to the main metadata, the extended metadata should be updateable without having to use the cold key of the pool and without having to perform an on-chain transaction. The consumer of these data should still have the possibility to verify the authenticity of the data. The operator notes all his additional pool information in the extended metadata (`extData.json`). We propose the pool operator generate a new public-secret key-pair (`extData.skey` and `extData.vkey`) ```shell cardano-cli node key-gen --cold-verification-key-file extData.vkey --cold-signing-key-file extData.skey --operational-certificate-issue-counter-file extData.counter ``` Then a new (not available yet) `cardano-cli` command generate the signature (`extData.sign`) . ```shell cardano-cli stake-pool rawdata-sign --raw-metadata-file extData.json --signing-key-file extData.skey --out-file extData.sign ``` The operator now: - has the `extData.json` and `extData.sign` files - will publish them at some https:// URL (probably same host as the main metadata) - set the published `extData.json` URL in the main metadata `extDataUrl` field - set the published `extData.sign` URL in then main metadata `extSigUrl` field - set the `extData.vkey` string in the main metadata `extVkey` field - re-register the extended main metadata file on chain This re-registration of the main metadata file with the `extData.vkey` and the two URLs is only necessary once. Afterwards, the operator can update his extended metadata at any time, compute the new signature with the `cardano-cli stake-pool rawdata-sign` command, and publish both files at the existing `extDataUrl` and `extSigUrl`. ## Rationale: how does this CIP achieve its goals? In the following we describe a first minimal version of the extended JSON file format. Since this extended metadata file can be updated at any time by the pool operator, a **serial number** is useful for consuming applications and services to identify updates. There are main thematic sections with respective subordinate data fields: - the **itn** section is about the verifiable linking of an ITN pool ticker with its counterpart in Mainnet to identify fraudulent duplicates. (already used as not standardized extension) - the **pool** section contains additional information about the pool instance - the pool.**contact** section contains information for additional information and contact data - the pool.**media_assets** section contains additional information about the pools media files and colors - the pool.**itn** section is an optional section for ITN pool operators The full schema is given in annexe as [schema.json][]
See JSON example ```json { "serial": 870, "pool": { "id": "69579373ec20f2f82d2dc2360410350b308112f2939f92a", "country": "JPN", "status": "active", "contact": { "primary": "email", "email": "info@demopool.org", "facebook": "demopool12", "github": "demopooldev", "feed": "https://www.demopool.org/feed.xml", "telegram": "demopool", "twitter": "demopoolbird" }, "media_assets": { "icon_png_64x64": "https://www.demopool.org/media/icon64.png", "logo_png": "https://www.demopool.org/media/logo.png", "logo_svg": "https://www.demopool.org/media/logo.svg", "color_fg": "#AABBCC", "color_bg": "#C0C0C0" }, "itn": { "owner": "ed25519_pk1...", "witness": "ed25519_sig1..." } } } ```
### Backwards compatibility No fields are removed or changed in the current on chain metadata. The new `ext...` fields are optional and not necessary to parse for any entities that do not need additional information about a pool ## Path to Active ### Acceptance Criteria - [x] There exist at least two explorers which make use of this extended metadata structure or very close equivalent: - [x] pooltool.io - [x] cexplorer.io ### Implementation Plan - [x] Provide direct support for this specification in stake pool explorers and other tools. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [schema.json]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0006/schema.json ================================================ FILE: CIP-0006/schema.json ================================================ { "$id": "https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0006/schema.json", "$schema": "http://json-schema.org/draft-07/schema", "default": {}, "description": "Additional information for Cardano Stake Pools", "examples": [ { "serial": 2020072001, "pool": { "id": "0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f", "country": "DE", "status": "act", "contact": { "primary": "email", "email": "help@pooldomain.org", "facebook": "demopool", "github": "demopool", "feed": "https://demopool.com/xml/poolrss.xml", "telegram": "demopool", "twitter": "demopool" }, "media_assets": { "icon_png_64x64": "https://mydemopool.com/icon.png", "logo_png": "https://mydemopool.com/logo.png", "logo_svg": "https://mydemopool.com/logo.svg", "color_fg": "#RRGGBB", "color_bg": "#RRGGBB" }, "itn": { "owner": "ed25519_pk1...", "witness": "ed25519_sig1..." } } } ], "maxLength": 4096, "required": [ "serial", "pool" ], "title": "Extended stake pool metadata", "type": "object", "properties": { "serial": { "$id": "#/properties/serial", "default": 0, "description": "Integer number incremented on every update, by using YYYYMMDDxx (xx each day start by 01 and is incremented on each update", "examples": [ 2021012001 ], "maxLength": 10, "minLength": 10, "required": [], "title": "serial number", "type": "integer" }, "pool": { "$id": "#/properties/pool", "default": {}, "description": "pool related metadata", "required": [ "id" ], "title": "stake pool", "type": "object", "properties": { "id": { "$id": "#/properties/pool/properties/id", "type": "string", "title": "Pool ID", "description": "the pools unique id in hex format", "maxLength": 48, "minLength": 48, "examples": [ "69579373ec20f2f82d2dc2360410350b308112f2939f92a" ] }, "country": { "$id": "#/properties/pool/properties/country", "default": "", "description": "3 letter country code as defined in https://www.iso.org/iso-3166-country-codes.html (alpha-3)", "maxLength": 3, "minLength": 3, "examples": [ "JPN" ], "title": "declared pool location", "type": "string" }, "status": { "$id": "#/properties/pool/properties/status", "default": "", "maxLength": 3, "minLength": 3, "description": "the current operative status (see examples).", "examples": [ "active", "retired", "offline", "experimental", "private" ], "title": "pool status", "type": "string" }, "contact": { "$id": "#/properties/pool/properties/contact", "default": {}, "description": "Optional contact information.", "examples": [ { "primary": "email", "email": "help@demopool.org", "facebook": "demopool", "github": "demopool", "feed": "https://mydemopool.com/xml/poolrss.xml", "telegram": "demopool", "telegram_channel": "https://t.me/coolchannel", "twitter": "demopool" } ], "required": [ "primary" ], "title": "Pool contact data", "type": "object", "properties": { "primary": { "$id": "#/properties/pool/properties/contact/properties/primary", "default": "email", "description": "the pools prefered communication channel", "title": "primary contact preference", "type": "string" }, "email": { "$id": "#/properties/pool/properties/contact/properties/email", "description": "valid email contact address", "title": "email address", "type": "string" }, "facebook": { "$id": "#/properties/pool/properties/contact/properties/facebook", "description": "a user or page name", "title": "facebook account", "examples": [ "demopool" ], "type": "string" }, "github": { "$id": "#/properties/pool/properties/contact/properties/github", "description": "a github username", "examples": [ "demopool" ], "title": "github account", "type": "string" }, "feed": { "$id": "#/properties/pool/properties/contact/properties/feed", "default": "", "description": "RSS feed URL", "examples": [ "https://mydemopool.com/xml/poolrss.xml" ], "title": "RSS feed", "type": "string" }, "telegram": { "$id": "#/properties/pool/properties/contact/properties/telegram", "description": "a telegram username", "examples": [ "demopool" ], "title": "telegram account", "type": "string" }, "twitter": { "$id": "#/properties/pool/properties/contact/properties/twitter", "description": "a twitter username", "examples": [ "demopool" ], "title": "twitter account", "type": "string" } } }, "media_assets": { "$id": "#/properties/pool/properties/media_assets", "type": "object", "title": "The pools media assets", "description": "Media file URLs and colors", "required": [ "icon_png_64x64" ], "properties": { "icon_png_64x64": { "$id": "#/properties/pool/properties/media_assets/properties/icon_png_64x64", "type": "string", "title": "Pool Icon in PNG file format 64x64 px", "description": "PNG image with exact 64x64 pixel size", "examples": [ "https://mydemopool.com/media/icon64.png" ] }, "logo_png": { "$id": "#/properties/pool/properties/media_assets/properties/logo_png", "type": "string", "title": "Pool Logo in PNG file format", "description": "PNG image (should have less than 250 kByte of file size)", "examples": [ "https://mydemopool.com/media/logo.png" ] }, "logo_svg": { "$id": "#/properties/pool/properties/media_assets/properties/logo_svg", "type": "string", "title": "Pool Logo in SVG file format", "description": "(shoud have less tha 250 kByte of file size)", "examples": [ "https://mydemopool.com/media/logo.svg" ] }, "color_fg": { "$id": "#/properties/pool/properties/media_assets/properties/color_fg", "type": "string", "title": "Pool primary color", "description": "RGB color code.", "examples": [ "#AABBCC" ] }, "color_bg": { "$id": "#/properties/pool/properties/media_assets/properties/color_bg", "type": "string", "title": "Pool secondary color", "description": "RGB color code.", "default": "", "examples": [ "#C0C0C0" ] } } }, "itn": { "$id": "#/properties/pool/properties/itn", "type": "object", "title": "ITN verification", "description": "A proof of ownership for an established ITN pool brand.", "required": [ "owner", "witness" ], "properties": { "owner": { "$id": "#/properties/pool/properties/itn/properties/owner", "type": "string", "title": "the ITN pool owner public key", "examples": [ "ed25519_pk1..." ] }, "witness": { "$id": "#/properties/pool/properties/itn/properties/witness", "type": "string", "title": "the secret key generated witness", "examples": [ "ed25519_sig1..." ] } } } } } } } ================================================ FILE: CIP-0007/CIP-0007.md ================================================ Moved to [CIP-0007/README.md](./README.md). ================================================ FILE: CIP-0007/README.md ================================================ --- CIP: 7 Title: Curve Pledge Benefit Authors: - Shawn McMurdo Category: Ledger Status: Proposed Created: 2020-08-11 Discussions: - https://github.com/cardano-foundation/CIPs/pull/12 - https://forum.cardano.org/t/protocol-parameters-pledge-and-sybil-resistance/35100 - https://github.com/input-output-hk/cardano-node/issues/1518 Implementors: [] License: Apache 2.0 --- ## Abstract Modifying the current rewards calculation equation by substituting a n-root curved relationship between pledge and pledge benefit rewards for the current linear relationship will better achieve the original design goal of incentivizing pledge to help prevent Sybil attacks. This also reduces the unfortunate side effect in the current equation that over rewards private pools which provide no additional security benefit. ## Motivation: why is this CIP necessary? There are two main reasons for changing the current linear a0 pledge benefit factor in the rewards equation. 1. Pools pledging less than 1 million ADA see very little reward benefit. This is not a strong incentive for pool operators as at current prices that is approximately $150,000 USD. 2. Private pools get massive reward benefit without providing any additional protection against Sybil attacks. Why should a private pool make 29% more rewards than a pool with 5m ADA pledge while doing the same work? ## Specification This is a modification of the maxPool function defined in section 11.8 Rewards Distribution Calculation of “A Formal Specification of the Cardano Ledger”. maxPool = (R / (1 + a0)) * (o + (s * a0 * ((o - (s * ((z0 - o) / z0))) / z0))) where: R = ((reserve * rho) + fees) * (1 - tau) o = min(pool_stake / total_stake, z0) = z0 for fully saturated pool s = pledge / total_stake z0 = 1 / k and the following are current protocol parameters: k = 150 rho = 0.0022 a0 = 0.3 tau = .05 The idea is to replace s in the above equation with an n-root curve expression of pledge rather than the linear pledge value. We use an expression called crossover to represent the point where the curve crosses the line and the benefit in the new and original equations is identical. Because the a0 pledge benefit is spread over the pledge range from 0 to saturation there is a dependence on k and total_stake. Since k and total_stake will likely change over time it is best to express crossover in terms of k and total_stake as follows: crossover = total_stake / (k * crossover_factor) where crossover_factor is any real number greater than or equal to 1. So crossover_factor is essentially a divisor of the pool saturation amount. For example, setting crossover_factor to 20 with k = 150 and total_stake = 31 billion gives a crossover of approximately 10.3 million. Also, we can parameterize the n-root curve exponent. This gives us: s = pow(pledge, (1 / curve_root)) * pow(crossover, ((curve_root - 1) / curve_root)) / total_stake The curve_root could be set to any integer greater than 0 and when set to 1 produces the current rewards equation. The curve_root is n in n-root. For example, 1 = linear, 2 = square root, 3 = cube root, 4 = fourth root, etc. By making this modification to the rewards equation we introduce two new protocol parameters, crossover_factor and curve_root, that need to be set thoughtfully. ### Test Cases See rewards.php for some simple PHP code that allows you to try different values for crossover_factor and curve_root and compare the resulting rewards to the current equation. For usage, run "php -f rewards.php help". An interesting set of parameters as an example is: curve_root = 3 crossover_factor = 8 Running "php -f rewards.php 3 8" produces: Assumptions Reserve: 14b Total stake: 31.7b Tx fees: 0 Fully Saturated Pool Rewards available in epoch: 29.3m Pool saturation: 211.3m Curve root: 3 Crossover factor: 8 Crossover: 26.4m Pledge Rewards Benefit Alt Rwd Alt Bnft 0k 150051 0% 150051 0% 10k 150053 0% 150458 0.27% 50k 150062 0.01% 150747 0.46% 100k 150073 0.01% 150928 0.58% 200k 150094 0.03% 151156 0.74% 500k 150158 0.07% 151551 1% 1m 150264 0.14% 151941 1.26% 2m 150477 0.28% 152432 1.59% 5m 151116 0.71% 153282 2.15% 10m 152181 1.42% 154122 2.71% 20m 154311 2.84% 155180 3.42% 50m 160702 7.1% 157012 4.64% 100m 171352 14.2% 158821 5.84% 211.3m 195067 30% 161305 7.5% As you can see this gives meaningful pledge benefit rewards to pools pledging less than 1m ADA. ## Rationale: how does this CIP achieve its goals? Using the n-root curve pledge benefit shows a much more reasonable distribution of pledge related rewards which will encourage meaningful pledges from more pool operators thus making the network more secure against Sybil attacks. It also provides higher rewards for higher pledge without disproportionately rewarding a very few private pool operators who provide no additional security value to the network. This modification maintains the general principles of the current rewards equation and does not introduce any hard limits. It improves the incentives that were originally designed to make them more meaningful for the majority of pool operators. ### Backward Compatibility This proposal is backwards compatible with the current reward function by setting the curve_root parameter to 1. ## Path to Active ### Acceptance Criteria - [ ] The new equation is implemented in the ledger and enacted through a hard-fork. ### Implementation Plan - [ ] Agreement by the Ledger team as defined in [CIP-0084](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) under _Expectations for ledger CIPs_ including "expert opinion" on changes to rewards & incentives. - [ ] Author has offered to produce an implementation of this change as a pull request if shown where the current maxPool reward equation is implemented in the code. ## Copyright 2020 Shawn McMurdo. This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). ================================================ FILE: CIP-0007/rewards.php ================================================ " . PHP_EOL; echo " curve_root: The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube root, etc." . PHP_EOL; echo " An integer greater than 0." . PHP_EOL; echo " crossover_factor: Divisor of saturation that calculates the pledge where the curve crosses the line." . PHP_EOL; echo " A real number greater than or equal to 1." . PHP_EOL; exit; } // Assumptions $reserve = 14000000000; $total_stake = 31700000000; $fees = 0; echo "Assumptions" . PHP_EOL; echo "Reserve: " . round($reserve / 1000000000, 1) . "b" . PHP_EOL; echo "Total stake: " . round($total_stake / 1000000000, 1) . "b" . PHP_EOL; echo "Tx fees: " . $fees . PHP_EOL; echo "Fully Saturated Pool" . PHP_EOL; // Protocol parameters $k = 150; $rho = 0.0022; $a0 = 0.3; $tau = .05; // Calculated values $R = (($reserve * $rho) + $fees) * (1 - $tau); $z0 = 1 / $k; $o = $z0; // for fully saturated pool $saturation = round($total_stake / $k); echo "Rewards available in epoch: " . round($R / 1000000, 1) . "m" . PHP_EOL; echo "Pool saturation: " . round($saturation / 1000000, 1) . "m" . PHP_EOL; echo PHP_EOL; // Pool pledge $pledges = array(0, 10000, 50000, 100000, 200000, 500000, 1000000, 2000000, 5000000, 10000000, 20000000, 50000000, 100000000, $saturation); // Compare to zero pledge $comparison_pledge = 0; $comparison_s = $comparison_pledge / $total_stake; $comparison_rewards = round(($R / (1 + $a0)) * ($o + ($comparison_s * $a0 * (($o - ($comparison_s * (($z0 - $o) / $z0))) / $z0)))); foreach ($curve_roots as $curve_root) { foreach ($crossover_factors as $crossover_factor) { $crossover = $total_stake / ($k * $crossover_factor); echo "Curve root: " . $curve_root . PHP_EOL; echo "Crossover factor: " . $crossover_factor . PHP_EOL; echo "Crossover: " . round($crossover / 1000000, 1) . "m" . PHP_EOL; echo PHP_EOL; echo "Pledge\tRewards\tBenefit\tAlt Rwd\tAlt Bnft" . PHP_EOL; foreach ($pledges as $pledge) { if ($pledge < 1000000) { $pledge_str = round($pledge / 1000, 1) . "k"; } else { $pledge_str = round($pledge / 1000000, 1) . "m"; } // Current Formula (same as alternate formula with curve_root = 1) $s = $pledge / $total_stake; $rewards = round(($R / (1 + $a0)) * ($o + ($s * $a0 * (($o - ($s * (($z0 - $o) / $z0))) / $z0)))); $benefit = round(((($rewards / $comparison_rewards) - 1) * 100), 2); $alt_numerator = pow($pledge, (1 / $curve_root)) * pow($crossover, (($curve_root - 1) / $curve_root)); $alt_s = $alt_numerator / $total_stake; $alt_rewards = round(($R / (1 + $a0)) * ($o + ($alt_s * $a0 * (($o - ($alt_s * (($z0 - $o) / $z0))) / $z0)))); $alt_benefit = round(((($alt_rewards / $comparison_rewards) - 1) * 100), 2); echo $pledge_str . "\t" . $rewards . "\t" . $benefit . "%\t" . $alt_rewards . "\t" . $alt_benefit . "%" . PHP_EOL; } echo PHP_EOL; } } ================================================ FILE: CIP-0008/CIP-0008.md ================================================ Moved to [CIP-0008/README.md](./README.md). ================================================ FILE: CIP-0008/README.md ================================================ --- CIP: 8 Title: Message Signing Status: Active Category: Tools Authors: - Sebastien Guillemot Implementors: - Mesh - Cardano Ballot - SundaeSwap governance - Emurgo Discussions: - https://github.com/Emurgo/EmIPs/pull/5 - https://forum.cardano.org/t/message-signing-specification/41032 - https://cardano.ideascale.com/a/dtd/Create-message-signing-standard/323158-48088 Created: 2020-09-28 License: CC-BY-4.0 --- ## Abstract Private keys can be used to sign arbitrary data. If you have the public key, you can verify the data was signed by the owner of the private key. This is how transaction signing works internally but its utility is not limited to transactions. This document tries to set a standard for how to represent and verify signed messages for Cardano. ## Motivation: why is this CIP necessary? Most common use cases: 1) Proving ownership of a set addresses (possibly to prove ownership of more then X Ada) 1) Proving ownership of addresses used in a transaction 1) Proving ownership of an identity or other off-chain data with a public key attached to it ## Specification ### Versions | version | description | |---------|-----------------| | 1 | initial version | ### Signing and Verification #### Overview First we will show a very basic example of the structure to help the reader understand the definitions that comes after ``` [ bstr, ; protected header { * label => any }, ; unprotected header bstr / nil, ; message to sign [ ; signature array [ ; first signature bstr ; protected { * label => any }, ; unprotected bstr ; signature ] ] ] ``` You can see the structure has two layers -- both containing a `protected` and an `unprotected` section. Items inside `protected` are part of the data signed while `unprotected` is meant to annotate the COSE structure (for example add annotations as you pass a message across a stack). Items MUST NOT be duplicated. You can find more complete definitions of `protected` and `unprotected` in [RFC 8152 section-3](https://tools.ietf.org/html/rfc8152#section-3) and you can see some the reserved entries (called `Generic_Headers`) in the maps in [RFC 8152 section-3.1](https://tools.ietf.org/html/rfc8152#section-3.1). Note: `payload` can be `nil`. This means that the payload is known by both the signer and the verifier and therefore doesn't need to be encoded. For your convenience, the structure is provided here: ``` empty_or_serialized_map = bstr .cbor header_map / bstr .size 0 header_map = { Generic_Headers, ; reserved headers (see COSE section 3.1) * label => values ; any number of int/string labels for application-specific purpose. } Headers = ( protected : empty_or_serialized_map, unprotected : header_map ) ; signature layer COSE_Signature = [ Headers, signature : bstr ] ; if signing with just ONE key COSE_Sign1 = [ Headers, payload : bstr / nil, signature : bstr ] # if signing with >1 key COSE_Sign = [ Headers, payload : bstr / nil, signatures : [+ COSE_Signature] ] signed_message = COSE_SIGN / COSE_Sign1 ``` #### Signing and Verification target format Instead of signing the full structure, we instead sign the following type which is derived from the structure ``` Sig_structure = [ context : "Signature" / "Signature1" / "CounterSignature", ; explained below body_protected : empty_or_serialized_map, ; protected from layer 1 ? sign_protected : empty_or_serialized_map, ; not present in Sign1 case external_aad : bstr, ; explanation below payload : bstr ] ``` The `external_aad` allows an application to ask the user to sign some extra data but NOT put it inside the COSE structure (only as part of the data to sign). Defaults to `h''`. You can read more about this at [RFC 8152 section-4.3](https://tools.ietf.org/html/rfc8152#section-4.3). The `context` is meant to encode what structure was used for the COSE request. `CounterSignature` is explained in a later section of this specification. #### Signing and Verification process To be able to effectively verify we need two things: 1) P1 - (optional) knowledge of the relation of a public key and a Cardano address 1) P2 - Knowledge of which algorithm was used to sign For `P1`, the mapping of public keys to addresses has two main cases: 1) for Shelley addresses, one payment key maps to many addresses (base, pointer, enterprise) 2) for Byron addresses, chaincode and address attributes need to be combined with the public key to generate an address To resolve this, one SHOULD add the full address to the protected header when using a v2 address. The v2 addresses contain the chaincode + attributes and we can verify the address matches combining it with the verification public key. ``` ? address: bstr, ``` For `P2`, we use the `alg` header and to specify which public key was used to sign, use the [cwt](https://tools.ietf.org/html/rfc8392) protected header. ### Encryption Although COSE defines multiple ways to encrypt, we simplify our spec to the two following cases: 1) Encrypted with the recipient's public key (called `key transport` in COSE spec) 2) Encrypted with a user-chosen password (called `passwords` in COSE spec) In order to facilitate implementations in wallets, we limit the usage of these to the following ``` ChachaPoly Ed25519PubKey ``` We will explain what this means shortly but you can find the full list of the types of encryption allowed by COSE at [RFC 8152 section 5.1.1](https://tools.ietf.org/html/rfc8152#section-5.1.1) #### Structure The COSE specification is made to be composable -- that is you can have a plaintext that you wrap with a signature, then wrap with an encryption, then wrap with a signature again (and so on). That means that for encryption in particular, it can either 1) Be used to encrypt plaintext directly 2) Be used to encrypt another COSE message In this spec, we care about the case where you encrypt a `signed_message` Here is the overall CBOR structure ``` ; holds encrypted content itself COSE_Encrypt = [ Headers, ciphertext : bstr / nil, ; contains encrypted signed_message recipients : [+COSE_recipient] ] ; holds encrypted keys the receiver can use to decrypt the content COSE_recipient = [ Headers, ciphertext : bstr / nil, ; contains encrypted key to decrypt the COSE_Encrypt ciphertext ? recipients : [+COSE_recipient] ; in case you need multiple rounds to get decryption key ] ``` To encrypt the structure as a whole, we call our encryption method once for each level (root, recipient, etc.) recursively. For example, we encrypt the `signed_message` and put it in the `COSE_Encrypt` ciphertext, then we encrypt the decryption key and put it in the `COSE_recipient` ciphertext. For the `Headers`, - The `protected` fields MUST be empty. These are meant to be used with AEAD which we don't need in this specification (you can read more about it at [RFC 8152 section 5.3](https://tools.ietf.org/html/rfc8152#section-5.3)). We define two ways to encrypt content: ##### Password-based encryption For password-based encryption we don't need a receiver field (anybody who knows the password can decrypt) so we instead use the following (simplified) structure ``` COSE_Encrypt0 = [ Headers, ciphertext : bstr / nil, ] PasswordEncryption = 16 (COSE_Encrypt0) ``` The COSE spec uses the following parameters for ChaCha20/Poly1305 as specified in [10.3](https://tools.ietf.org/html/rfc8152#section-10.3): - 256-bit key - 128-bit tag - 96-bit nonce We RECOMMEND using `19162` iterations as this matches the existing password encryption in the [Yoroi encryption spec](https://github.com/Emurgo/yoroi-frontend/blob/737595fec5a89409aacef827d356c9a1605515c0/docs/specs/code/ENCRYPT.md)`. ##### Public key based encryption We only allow encrypting based on `ED25519` public keys (the ones used for Cardano). To encrypt based on these public keys, you must 1) Compute a password consisting of 22 case-sensitive alphanumeric (a–z, A–Z, 0–9) characters (this gives you ~128 bits of entropy) Now, for each receiver, you must 2) Compute an ephemeral key pair using `ED25519 extended` 1) Compute the shared DH secret between the private key from step (1) and the public key received (using the `exchange` functionality) 1) Use this as the password to encrypt the password in (1) using [the Yoroi encryption spec](https://github.com/Emurgo/yoroi-frontend/blob/737595fec5a89409aacef827d356c9a1605515c0/docs/specs/code/ENCRYPT.md) The structure will look like the following: ``` COSE_Encrypt = [ Headers, ciphertext : bstr / nil, ; contained signed_message encrypted with random password recipients : [+COSE_recipient] ] COSE_recipient = [ Headers, ciphertext : bstr / nil, ; contains random password encrypted with shared secret ] PubKeyEncryption = 96 (COSE_Encrypt) ``` The `Headers` for the recipient MUST have a `epk` label containing the public key of the ephemeral keypair as described in the [CBOR Encoded Message Syntax](http://www.watersprings.org/pub/id/draft-schaad-cose-02.html). #### Version The `Headers` for the body MUST have `version: uint` in the `unprotected` field. See [Versions table](#versions) for possible version numbers. #### Payload encoding To solve `E3`, `signed_message` body header MUST contain `hashed: bool` as an `unprotected` header which defines whether or not we signed the `payload` OR the `Blake2b224` hash of the `payload`. The hash MUST be used in the following two cases 1) The size of the raw `payload` would otherwise be too big to fit in hardware wallet memory (see E1). Note that the exact size for which this is the case depends on the device. 1) The payload characters (ex: non-ASCII) that cannot be displayed on the hardware wallet device (see E3) We RECOMMEND showing the user the full payload on the device if possible because it lowers the attack surface (otherwise the user has to trust that the hash of the payload was calculated correctly). `Blake2b224` was chosen specifically because `224` bits is already a long string for hardware wallets. ### User-Facing Encoding Once we have our top-level `encrypted_message` or `signed_message` we need to encode them in way that can be displayed to users (doesn't need to be stored and can be inferred just from the data) We define the encoding in three parts `prefix || data || checksum` (where || means append) ### Prefix We need a human-readable prefix. We use "CM" for "Cardano Message" followed by the message type: - `encrypted_message`: `cme_` - `signed_message`: `cms_` - `mac_message`: `cmm_` (unused in this spec) #### Data Data is simply the `base64url` encoding of the message #### Checksum We use fnv32a on the data for the checksum and store it as the `base64url` encoding of its network byte order representation. ### Other remarks We recommend usage of unprotected headers vs protected headers when possible. This is because we have to limit the amount of data passed to a hardware wallet to satisfy E1. If the only effect of an adversary changing an unprotected header only leads to the signature not matching, then it's best to leave it unprotected. The public key SHOULD NOT contain any chaincode information, as it could compromise child non-hardened keys. It is both a privacy and a security risk (see [here](https://bitcoin.org/en/wallets-guide#hierarchical-deterministic-key-creation) for more detail). ## Rationale: how does this CIP achieve its goals? ### Requirements On top being usable for all cases mentioned in [Motivation](#motivation-why-is-this-cip-necessary), we also desire the following to ensure it works well with hardware wallets: - E1 - Low runtime memory environment - E2 - Low app size environment (cannot implement every cryptographic algorithm on the device or app size would be too big) - E3 - Works well with limited display (some hardware wallets cannot display long text and cannot display UTF8) ### Related specifications #### Requirement Levels [[RFC 2119](https://tools.ietf.org/html/rfc2119)] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). #### Concise Binary Object Representation (CBOR) [[RFC 7049](https://tools.ietf.org/html/rfc7049)] CBOR is a way to serialize structured data in a more compact way than what is allowed by JSON. It is widely used across the Cardano ecosystem and so we use it to encode the data for this specification. #### *Concise Data Definition Language (CDDL)* [[RFC 8610](https://tools.ietf.org/html/rfc8610)] CDDL is a human-readable CBOR notation format. CBOR schemas defined in this document are defined uinsg CDDL. We use `label = int / tstr` in several places. #### *CBOR Object Signing and Encryption (COSE)* [[RFC 8152](https://tools.ietf.org/html/rfc8152)] This is a standard for how to use CBOR for message signing. It is based on the JSON equivalent *JSON Object Signing and Encryption* [RFC 7520](https://tools.ietf.org/html/rfc7520). We base our construction on COSE because all Cardano libraries already depend on CBOR due to its use in the base protocol (which means we don't need to introduce a new library). It is also more compact, which is useful in case data generated by this standard ever needs to be stored on-chain. #### *CBOR Web Token (CWT)* [[RFC 8392](https://tools.ietf.org/html/rfc8392)] This is a standard for pre-defined header elements for message signing based on the equivalent standard for JSON (*JWT* [[RFC 7519](https://tools.ietf.org/html/rfc7519)]). This allows us to standardize notions of concepts like expiration time of a signed message. #### *Address Formats* BECH32 ([BIP-173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)) is a standard for encoding addresses such that they - Are human readable (both in length and contain a common prefix) - Can easily be displayed in a QR code - Contain error detection through a BCH checksum Cardano has several address types based on the era they were created in: * `v1` - Legacy Daedalus (starts with Dd) * `v2` - Legacy Icarus (starts with Ae2) * `v3` - Shelley (bech32) Although `v3` is relevant to us for encoding public keys into addresses, we do not use `bech32`'s scheme for encoding in this specification. This is because - The payload may be too big to reasonably encode in a QR code so the benefits of using base32 are limited. - BCH checksums are not made for large payloads and additionally the polynomial used has to be fine-tuned for the expected length (but the length of our payload varies too much in this spec) #### fnv32a Although Cardano Byron addresses use CRC32 (IEEE variation), due to `E1` and `E2` we use fnv32a for checksums. This is because CRC32: 1) Has fairly few collisions compared to other hashes 2) Is moderately slower than other hashes 3) Requires more memory than alternatives (need to build a lookup table) 4) Is somewhat complex implementation (many alternatives exist) while fnv32a: 1) Still has fairly few collisions 2) Is faster than CRC32 in general 3) Needs only O(1) memory requirement 4) Is simple to implement In particular, using fnv32a over CRC32 frees up 1024 bytes of memory due to not having a lookup table which is significant on hardware wallets. #### Blake2b [[RFC 7693](https://tools.ietf.org/html/rfc7693)] Blake2b is a hash algorithm used commonly in Cardano. Notably, Blake2b-224, Blake2b-256 and Blake2b512 are used depending on the context. #### base64url [[RFC 4648 section 5](https://tools.ietf.org/html/rfc4648#section-5)] `base64url` allows encoding bytes in a human-readable format that is also safe to pass in URLs. #### Other blockchain standards Other blockchains have existing specifications for message signing, but they mostly revolve around scripts trying to validate messages. We don't leverage any of their work in particular but it may be of interest. - [BIP-137](https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki) - simply scheme for message signing that works with P2PKH, P2PSH and bech32 - [BIP-322](https://github.com/kallewoof/bips/blob/master/bip-0322.mediawiki) - reuses Bitcoin script to process a generic signed message format - [EIP-191](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-191.md) - encode data for Ethereum contracts - [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) - encode structs for Ethereum contracts ### Existing Code #### Cryptography Cardano already allows message signing within the WASM bindings. Notably, 1) [sign](https://github.com/Emurgo/cardano-serialization-lib/blob/4792b1b121e728a51686d5fcbffd33489d65c903/rust/src/crypto.rs#L279) 2) [verify](https://github.com/Emurgo/cardano-serialization-lib/blob/4792b1b121e728a51686d5fcbffd33489d65c903/rust/src/crypto.rs#L322) You can see an example of these two functions [here](https://repl.it/repls/FlusteredSimpleFunction) Even if you use cryptographically secure `sign` and `verify` functions, you still have the following problems: 1) No human-recognizable prefix 0) No error detection 0) User could accidentally sign a transaction or a block thinking it's harmless data We also have a risk of a few different kinds of replay attacks 4) A dapp asks person A to sign "BOB" and then another dapp asks user B to sign "BOB". B can just use the signature from A 0) A dapp asks person A to sign "BOB" on a testnet chain. Person B then sends this signed message to the same dapp running on mainnet (same argument applies to sidechains) ### Reference implementations - [COSE-JS](https://github.com/erdtman/cose-js) - [Rust message signing](https://github.com/Emurgo/message-signing) ### Unresolved This specification provides no means of Revocation. ## Path to Active ### Acceptance Criteria - [x] There are wallets supporting creation of signed messages as per this protocol (enumerated 2023-12-19 as per [CardanoBallot list of wallets](https://voting.summit.cardano.org/user-guide) supporting CIP-8 signed messages): - [x] Flint - [x] Eternl - [x] Nami - [x] Typhon - [x] Yoroi - [x] Nufi - [x] Gerowallet - [x] Lace - [x] There exist one or more implementations in commonly used development libraries: - [x] [Mesh](https://meshjs.dev/) - [x] `@emurgo/cardano-message-signing-asmjs` - [x] There exist CLI Tools supporting creation and verification of signed messages: - [x] [cardano-signer](https://github.com/gitmachtl/cardano-signer) - [x] There exist one or more implementations in web sites and other tools: - [x] SundaeSwap Governance voting ### Implementation Plan - [x] Make this standard available as well-supported means of message signing across Cardano wallets, dApps, and CLI tools. - [x] Support this standard in a usable reference implementation ([`@emurgo/cardano-message-signing-asmjs`](https://www.npmjs.com/package/@emurgo/cardano-message-signing-asmjs)). ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0009/CIP-0009.md ================================================ Moved to [CIP-0009/README.md](./README.md). ================================================ FILE: CIP-0009/README.md ================================================ --- CIP: 9 Title: Protocol Parameters (Shelley Era) Status: Active Category: Ledger Authors: - Kevin Hammond Implementors: - IOG Discussions: - https://github.com/cardano-foundation/CIPs/pull/45 Created: 2021-01-29 License: Apache-2.0 --- ## Abstract This CIP is an informational CIP that describes the initial protocol parameter settings for the Shelley era of the Cardano blockchain, plus the changes that have been made. It is intended to serve as a historic record, allowing protocol parameter changes to be tracked back to the original settings. ## Motivation: why is this CIP necessary? We need to provide a concise description of the initial protocol parameter choices, that can be used by the community as the base for future proposed protocol changes, and that document the chain of changes to the parameters. ## Specification ### Proposing Protocol Parameter Changes This CIP records only the changes to the protocol parameters that have actually been made. Suggested changes to protocol parameters should be proposed by preparing and submitting a new CIP, rather than editing this CIP. The following information should be included. | Name of the Parameter | New Parameter (Y/N) | Deleted Parameter (Y/N) | Proposed Value | Summary Rationale for Change | |----------------------- |-------------------- |------------------------ |--------------- | ---------------------------- | Where necessary, the summary rationale should be supported by a few paragraphs of text giving the full rationale, plus references to any external documents that are needed to understand the proposal. Protocol parameters are used to affect the operation of the Cardano Protocol. They may be either **updatable** or **non-updatable**. Updatable parameters can be tuned to vary the operation of the block producing protocol, impacting the proportion of pools that are federated/non-federated, how much influence the "pledge" has etc. Non-updatable parameters affect the fundamentals of the blockchain protocol, including defining the genesis block, basic security properties etc. Some non-updatable parameters may be embedded within the source code or implemented as software. Each major protocol version defines its own sets of updatable/non-updatable parameters. ### Updatable Protocol Parameters The initial **updatable** protocol parameter values are given below (in JSON format). Any of these parameters may be changed by submitting a parameter update proposal. A change to the major protocol parameter version triggers a "hard fork" event. This will require stake pool operators to upgrade to a new software version that complies with the new chain production protocol as well as being able to verify the construction of the chain. ``` { "protocolVersion": { "major": 2, "minor": 0 }, "nOpt": 150, "a0": 0.3, "minPoolCost": 340000000, "decentralisationParam": 1.0, "maxBlockBodySize": 65536, "maxBlockHeaderSize": 1100, "maxTxSize": 16384, "tau": 0.2, "rho": 3.0e-3, "poolDeposit": 500000000, "keyDeposit": 2000000, "minFeeB": 155381, "minFeeA": 44, "minUTxOValue": 1000000, "extraEntropy": { "tag": "NeutralNonce" }, "eMax": 18 } ``` The meaning of the fields is: | Field | Initial Value | Description | |----------------------- |------------------------------------------------------------------------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | protocolVersion | ```protocolVersion": { "major": 2, "minor": 2 }``` | Protocol version. Minor versions indicate software updates (will generally be 0). Major version 1 = Byron, 2 = Shelley | | nOpt | 150 | "Target number of pools" ("k"). Impacts saturation threshold, encouraging growth in number of stake pools. | | a0 | 0.3 | "Influence Factor". Governs how much impact the pledge has on rewards. v | | minPoolCost | 340000000 | Minimum Pool Cost per epoch (in lovelace). Enables pledge effect. | | decentralisationParam | 1.0 | Level of decentralisation. Starts at 1. Block production is fully decentralised when this reaches 0. | | | | | maxBlockBodySize | 65536 | Maximum size of a block body. Limits blockchain storage size, and communication costs. | | maxBlockHeaderSize | 1100 | Maximum size of the block header. Should be significantly less than the maximum block size. | | maxTxSize | 16384 | Maximum size of a transaction. Several transactions may be included in a block. Must be strictly less than the max. block body size. | | | | | tau | 0.2 | Treasury rate (0.2 = 20%). Proportion of total rewards allocated to treasury each epoch before remaining rewards are distributed to pools. | | | rho | 3.0e-3 | Monetary expansion rate per epoch. Governs the rewards that are returned from reserves to the ecosystem (treasury, stake pools and delegators). | | | | | poolDeposit | 500000000 | Pool deposit (in lovelace) | | keyDeposit | 2000000 | Deposit charged for stake keys (in Lovelace). Ensures that unused keys are returned, so freeing resources. | | | | | minFeeB | 155381 | Base transaction fee (in lovelace). | | minFeeA | 44 | Additional transaction fee per byte of data (in lovelace). | | | | | minUTxOValue | 1000000 | Minimum allowed value in a UTxO. Security-related parameter used to prevent the creation of many small UTxOs that could use excessive resource to process. | | | | | extraEntropy | ```{ "tag": "NeutralNonce" }``` | Should additional entropy be included in the initial phases. This provides additional certainty that the blockchain has not been compromised by the seed key holders. Redundant once the system is sufficiently decentralised. | | eMax | 18 | Maximum number of epochs within which a pool can be announced to retire, starting from the next epoch. | ### Non-Updatable Parameters The initial non-updatable protocol parameters are given below (in JSON format): ``` "activeSlotsCoeff": 0.05, ... "genDelegs": { "ad5463153dc3d24b9ff133e46136028bdc1edbb897f5a7cf1b37950c": { "delegate": "d9e5c76ad5ee778960804094a389f0b546b5c2b140a62f8ec43ea54d", "vrf": "64fa87e8b29a5b7bfbd6795677e3e878c505bc4a3649485d366b50abadec92d7" }, ... } }, "updateQuorum": 5, "networkId": "Mainnet", "initialFunds": {}, "maxLovelaceSupply": 45000000000000000e, "networkMagic": 764824073, "epochLength": 432000, "systemStart": "2017-09-23T21:44:51Z", "slotsPerKESPeriod": 129600, "slotLength": 1, "maxKESEvolutions": 62, "securityParam": 2160 } ``` The meaning of the fields is: | Field | Initial Value | Description |----------------------- |------------------------------------------------------------------------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | activeSlotsCoeff | 0.05 | The fraction of the total number of slots that will, on average, be selected to include a block in the chain. Smaller numbers increase security, but reduce efficiency. | | genDelegs | ... | Details of the public keys that have been selected by each of the genesis keys to act as a delegate for signing protocol updates etc. | | updateQuorum | 5 | How many of the genesis delegate keys must endorse an update proposal. | | networkId | "Mainnet" | Is this a testnet or mainnet | | initialFunds | {} | initial distribution of funds to addresses. | | maxLovelaceSupply | 45000000000000000 | The limit on the maximum number of lovelace that can be in circulation. | | networkMagic | 764824073 | A magic number used to distinguish different networks. | | epochLength | 432000 | The number of slots in an epoch. | | SystemStart | "2017-09-23T21:44:51Z" | When did the system originally start operation. | | slotsPerKESPeriod | 129600 | After how many slots will a pool's operational key pair evolve (Key Evolving Signatures). | | slotLength | 1 | The length of each slot (in seconds). | | maxKESEvolutions | 62 | What is the maximum number of times a KES key pair can evolve before a new KES key pair must be generated from the master keys. | | securityParam | 2160 | After how many blocks is the blockchain considered to be final, and thus can no longer be rolled back (i.e. what is the maximum allowable length of any chain fork). | ### Pre-Shelley Protocol Parameters The original protocol parameters are given in the Byron genesis file. These parameters need to be included in any operational stake pool so that the Byron portion of the chain can be verified, but they can no longer be altered. ``` { "avvmDistr": { ... }, "blockVersionData": { ... }, "ftsSeed": "76617361206f7061736120736b6f766f726f64612047677572646120626f726f64612070726f766f6461", "protocolConsts": { ... }, "startTime": 1506203091, "bootStakeholders": { ... }, "heavyDelegation": { ... } }, "nonAvvmBalances": {}, "vssCerts": { ... } ``` ### Process for Making Changes to Protocol Parameters #### Governance Changes will affect many stakeholders and must therefore be subject to open community debate and discussion. Ultimately, the Voltaire protocol voting mechanism will be used to achieve fully automated, decentralised and transparent governance. In the interim, the CIP process will be used. #### Signalling Protocol Parameter Changes Changes to the parameters need to be signalled to the community well in advance, so that they can take appropriate action. For the most significant parameters, a minimum of 4-6 weeks elapsed time between announcement and enactment is appropriate. This period must be included in the CIP. Announcements will be made as soon as practical after the conclusion of the vote. #### Applying Protocol Parameter Changes Protocol parameter changes must be submitted and endorsed within the first 24 hours of the epoch before they are required to come into effect. For example, a change that is intended for epoch 300 must be submitted and endorsed in the first 24 hours of epoch 299. Once a change has been submitted and endorsed by a sufficient quorum of keyholders (currently 5 of the 7 genesis keys), it cannot be revoked. #### Voiding Proposed Protocol Parameter Changes Once a protocol parameter change has been announced, it can only be overridden through the voting process (CIP, Voltaire etc.). Any vote must be completed before the start of the epoch in which the change is to be submitted. ### Change Log #### Changes to the Updatable Parameters since the Shelley Hard Fork Event Following the Shelley hard fork event, the ``decentralisationParam`` parameter has been gradually decreased from ``1.0`` to ``0.3``, with the goal of ultimately decreasing it to ``0`` (at which point it can be removed entirely as an updatable parameter). This has gradually reduced the impact of the federated block producing nodes, so ensuring that the network moves to become a distributed collection of increasingly decentralised stake pools. The parameter was frozen at ``0.32`` between epochs 234 and 240. The ``nOpt`` parameter was changed from ``150`` to ``500`` in epoch 234. | Epoch | Date | Decentralisation | nOpt| | ----- | ---------- | ---------------- | ---- | | 208 | 2020-07-29 | 1 | 150| | 209 | 2020-08-03 | 1 | 150| | 210 | 2020-08-08 | 1 | 150| | 211 | 2020-08-13 | 0.9 | 150| | 212 | 2020-08-18 | 0.8 | 150| | 213 | 2020-08-23 | 0.78 | 150| | ... | ... | ... | ...| | 227 | 2020-11-01 | 0.5 | 150| | ... | ... | ... | ...| | 233 | 2020-12-01 | 0.38 | 150| | 234 | 2020-12-06 | 0.32 | 500| | 235 | 2020-12-11 | 0.32 | 500| | ... | ... | ... | ...| | 239 | 2020-12-31 | 0.32 | 500| | 240 | 2021-01-05 | 0.32 | 500| | 241 | 2021-01-10 | 0.3 | 500| | ... | ... | ... | ...| #### The Allegra Hard Fork Event The Allegra Hard Fork Event on 2020-12-16 (epoch 236) introduced token locking capabilities plus some other small changes to the protocol. No parameters were added or removed. ``` { "poolDeposit": 500000000, "protocolVersion": { "minor": 0, "major": 3 }, "minUTxOValue": 1000000, "decentralisationParam": 0.32, "maxTxSize": 16384, "minPoolCost": 340000000, "minFeeA": 44, "maxBlockBodySize": 65536, "minFeeB": 155381, "eMax": 18, "extraEntropy": { "tag": "NeutralNonce" }, "maxBlockHeaderSize": 1100, "keyDeposit": 2000000, "nOpt": 500, "rho": 3.0e-3, "tau": 0.2, "a0": 0.3 } ``` #### The Mary Hard Fork Event The Mary Hard Fork Event will introduce multi-asset token capability. It is not expected that any parameter will be added or removed. ``` { "poolDeposit": 500000000, "protocolVersion": { "minor": 0, "major": 4 }, "minUTxOValue": 1000000, "decentralisationParam": 0.32, "maxTxSize": 16384, "minPoolCost": 340000000, "minFeeA": 44, "maxBlockBodySize": 65536, "minFeeB": 155381, "eMax": 18, "extraEntropy": { "tag": "NeutralNonce" }, "maxBlockHeaderSize": 1100, "keyDeposit": 2000000, "nOpt": 500, "rho": 3.0e-3, "tau": 0.2, "a0": 0.3 } ``` #### The Alonzo Hard Fork Event See [CIP-0028: Protocol Parameters (Alonzo Era)](../CIP-0028). ## Rationale: how does this CIP achieve its goals? The initial parameter settings were chosen based on information from the Incentivised Testnet, the Haskell Testnet, Stake Pool Operators plus benchmarking and security concerns. This parameter choice was deliberately conservative, in order to avoid throttling rewards in the initial stages of the Cardano mainnet, and to support a wide range of possible stake pool operator (professional, amateur, self, etc.). Some parameter choices (``systemStart``, ``securityParam``) were required to be backwards compatible with the Byron chain. ### Key Behavioural Parameters The key parameters that govern the behaviour of the system are ``nOpt``, ``a0``, ``decentralisationParam`` and ``minPoolCost``. Changes to these parameters need to be considered as a package -- there can be unintended consequences when changing a single parameter in isolation. It is expected that the following changes to these parameters are likely in the near to medium term: * increasing ``nOpt`` to align more closely with the number of active pools * increasing ``a0`` to increase the pledge effect * decreasing ``minPoolCost`` (e.g. in line with growth with the Ada value) * decreasing ``decentralisationParam`` to 0 (to enable full decentralisation of block production) Further adjustments are likely to be required to tune the system as it evolves. ### Economic Parameters Four parameters govern the economics of the system: ``tau``, ``rho``, ``minFeeA`` and ``minFeeB``. The first two concern the rate of rewards that are provided to stake pools, delegators and the treasury. The others concern transaction costs. ### Transaction and Block Sizes Three parameters govern block and transaction sizes: ``maxBlockBodySize``, ``maxBlockHeaderSize``, ``maxTxSize``. Their settings have been chosen to ensure the required levels of functionality, within constrained resource restrictions (including long-term blockchain size and real-time worldwide exchange of blocks). Changes to these parameters may impact functionality, network reliability and performance. ### Backward Compatibility This CIP describes the initial set of protocol parameters and the changes to date, so backwards compatibility is not an issue. Future proposals may change any or all of these parameters. A change to the major protocol version indicates a major change in the node software. Such a change may involve adding/removing parameters or changing their semantics/formats. In contrast, minor protocol changes are used to ensure key software updates without changing the meaning of any protocol parameters. ## Path to Active ### Acceptance Criteria - [x] The Shelley ledger era is activated. - [x] Documented parameters are in operational use by Cardano Node and Ledger. ### Implementation Plan - [x] Original (Shelley) and subsequent ledger era parameters are deemed correct by working groups at IOG. ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). ================================================ FILE: CIP-0010/CIP-0010.md ================================================ Moved to [CIP-0010/README.md](./README.md). ================================================ FILE: CIP-0010/README.md ================================================ --- CIP: 10 Title: Transaction Metadata Label Registry Status: Active Category: Metadata Authors: - Sebastien Guillemot Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/34 - https://forum.cardano.org/t/cip10-transaction-metadata-label-registry/41746 Created: 2020-10-31 License: CC-BY-4.0 --- ## Abstract Cardano transaction metadata forces metadata entries to namespace their content using an unsigned integer key. This specification is a registry of which use cases has allocated which number to avoid collisions. ## Motivation: why is this CIP necessary? The top level of the transaction metadata CBOR object is a mapping of `transaction_metadatum_label` to the actual metadata where the `transaction_metadatum_label` represents an (ideally unique) key for a metadata use case. This allows enables the following: 1) Fast lookup for nodes to query all transactions containing metadata that uses a specific key 2) Allows a single transaction to include multiple metadata entries for different standards ## Specification ### Terminology Transaction metadata refers to an optional CBOR object in every transaction since the start of the Shelley era. It is defined as the follow CDDL data structure ``` transaction_metadatum = { * transaction_metadatum => transaction_metadatum } / [ * transaction_metadatum ] / int / bytes .size (0..64) / text .size (0..64) transaction_metadatum_label = uint transaction_metadata = { * transaction_metadatum_label => transaction_metadatum } ``` ### Structure These are the reserved `transaction_metadatum_label` values: `transaction_metadatum_label` | description ---------------------------- | ----------------------- 0 - 15 | reserved 65536 - 131071 | reserved - private use For the registry itself, please see [registry.json](./registry.json). To add or modify a label definition, please open a pull request against this file. For new label numbers, include background information about your project and/or documentation of the label if available (and state your intended usage if not). You can check if a label number is already in use with an API query. For instance: to check if label `8414` is in use via Koios (no API key needed for `curl`): ``` curl -s "https://api.koios.rest/api/v1/tx_by_metalabel?_label=8414" -H "accept: application/json" ``` ## Rationale: how does this CIP achieve its goals? Creating a registry for `transaction_metadatum_label` values has the following benefit: 1) It makes it easy for developers to know which `transaction_metadatum_label` to use to query their node if looking for transactions that use a standard 2) It makes it easy to avoid collisions with other standards that use transaction metadata ## Path to Active ### Acceptance Criteria - [x] Consistent, long-term use by Cardano implementors of the metadata label registry by all applications requiring a universally acknowledged metadata label. - [x] Consistent, long-term use in the CIP editing process: tagging, verifying, and merging new label requirements. ### Implementation Plan - [x] Confirmed interest and cooperation in this metadata labelling standard and its `registry.json` convention by Cardano implementors: including NFT creators, data aggregators, and sidechains. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0010/registry.json ================================================ [ { "transaction_metadatum_label": 22, "description": "Clarity - DAO creation metadata" }, { "transaction_metadatum_label": 87, "description": "milkomeda.com - The protocol magic for the milkomeda protocol" }, { "transaction_metadatum_label": 88, "description": "milkomeda.com - the destination address in the sidechain" }, { "transaction_metadatum_label": 94, "description": "CIP-0094 - On-chain governance polls" }, { "transaction_metadatum_label": 123, "description": "shareslake.com - Bridge routing information" }, { "transaction_metadatum_label": 170, "description": "CIP-0170 - KERI-backed metadata attestations" }, { "transaction_metadatum_label": 309, "description": "Proof of Existence record" }, { "transaction_metadatum_label": 544, "description": "TapDano - Proof Platform" }, { "transaction_metadatum_label": 620, "description": "seedtrace.org - supply chain & fair payment tracing" }, { "transaction_metadatum_label": 674, "description": "CIP-0020 - Transaction message/comment metadata" }, { "transaction_metadatum_label": 721, "description": "CIP-0025 - NFT Token Standard" }, { "transaction_metadatum_label": 777, "description": "CIP-0027 - Royalties Standard" }, { "transaction_metadatum_label": 839, "description": "Agora - Proposal creation metadata" }, { "transaction_metadatum_label": 867, "description": "CIP-0088 - Token Policy Registration Standard" }, { "transaction_metadatum_label": 888, "description": "finitum.io token bridge transactions metadata" }, { "transaction_metadatum_label": 1226, "description": "Oracle related transaction metadata" }, { "transaction_metadatum_label": 1304, "description": "on-chain certification metadata" }, { "transaction_metadatum_label": 1447, "description": "Reeve - transparent and verifiable financial records on-chain" }, { "transaction_metadatum_label": 1517, "description": "Reeve - obsolete - pre-launch metadata" }, { "transaction_metadatum_label": 1564, "description": "Marlowe - a DSL for writing and executing financial contracts" }, { "transaction_metadatum_label": 1667, "description": "CIP-72: dApp registration & Discovery" }, { "transaction_metadatum_label": 1668, "description": "Begin Wallet: dApp rating record from dApp Store" }, { "transaction_metadatum_label": 1694, "description": "Voltaire - additional metadata for governance, provided in a separate transaction" }, { "transaction_metadatum_label": 1854, "description": "CIP-146 Multi-signatures wallet registration" }, { "transaction_metadatum_label": 1870, "description": "Open Badges v2.0 compliant metadata" }, { "transaction_metadatum_label": 1888, "description": "amphitheatre by the ape society" }, { "transaction_metadatum_label": 1904, "description": "Proof of origin and quality related verification data in supply chain" }, { "transaction_metadatum_label": 1967, "description": "nut.link metadata oracles registry" }, { "transaction_metadatum_label": 1968, "description": "nut.link metadata oracles data points" }, { "transaction_metadatum_label": 1983, "description": "cardanohosts.com hosting metadata" }, { "transaction_metadatum_label": 1984, "description": "CIP-0171 - On-chain Smart Contract Bytecode Verification" }, { "transaction_metadatum_label": 1988, "description": "cardahub.io marketplace metadata" }, { "transaction_metadatum_label": 1989, "description": "cardahub.io services metadata" }, { "transaction_metadatum_label": 3165, "description": "CPE - Cardano Proposal Examiner" }, { "transaction_metadatum_label": 3692, "description": "CIP-0149 - Optional DRep compensation" }, { "transaction_metadatum_label": 6676, "description": "Maya Protocol - Cross-chain swap memo (bifrost observer)" }, { "transaction_metadatum_label": 6770, "description": "fortunes.coconutpool.com fortune teller" }, { "transaction_metadatum_label": 8413, "description": "commitproof.com lets you prove what you knew and when" }, { "transaction_metadatum_label": 8414, "description": "claimpaign.com campaigns" }, { "transaction_metadatum_label": 10297, "description": "fida.finance transaction metadata" }, { "transaction_metadatum_label": 18300, "description": "selfdriven Achievement" }, { "transaction_metadatum_label": 18308, "description": "selfdriven Identity" }, { "transaction_metadatum_label": 21325, "description": "PRISM's Verifiable Data Registry for the PRISM DID method" }, { "transaction_metadatum_label": 61284, "description": "CIP-0015 - Catalyst registration" }, { "transaction_metadatum_label": 61285, "description": "CIP-0015 - Catalyst witness" }, { "transaction_metadatum_label": 61286, "description": "CIP-0015 - Catalyst deregistration" } ] ================================================ FILE: CIP-0010/registry.schema.json ================================================ { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010", "title": "Transaction Metadata Label Registry", "description": "JSON schema for transaction metadata label registry", "type": "array", "items": { "type": "object", "properties": { "transaction_metadatum_label": { "type": "integer", "minimum": 0 }, "description": { "type": "string", "maxLength": 256 } }, "required": [ "transaction_metadatum_label", "description" ], "additionalProperties": false } } ================================================ FILE: CIP-0011/CIP-0011.md ================================================ Moved to [CIP-0011/README.md](./README.md). ================================================ FILE: CIP-0011/README.md ================================================ --- CIP: 11 Title: Staking key chain for HD wallets Status: Active Category: Wallets Authors: - Sebastien Guillemot - Matthias Benkort Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/33 - https://forum.cardano.org/t/staking-key-chain-for-hd-wallets/41857 - https://github.com/cardano-foundation/CIPs/pull/37 Created: 2020-11-04 License: CC-BY-4.0 --- ## Abstract Starting with the Shelley hardfork, Cardano makes use of both the *UTXO model* and the *account model*. To support both transaction models from the same master key, we allocate a new chain for [CIP-1852]. ## Motivation: why is this CIP necessary? Generally it's best to only use a cryptographic key for a single purpose, and so it's best to make the staking key be separate from any key used for UTXO addresses. ## Specification > **Note** The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). Recall that [CIP-1852] specifies the following derivation path: ``` m / purpose' / coin_type' / account' / chain / address_index ``` We set `chain=2` to indicate the *staking key chain*. Keys in this chain MUST follow the accounting model for transactions and SHOULD be used for *reward addresses* ### *address_index* value We RECOMMEND wallets only use `address_index=0` for compatibility with existing software. This also avoids the need for staking key discovery. Wallets that use multiple staking keys are REQUIRED to use sequential indexing with no gaps. This is to make detection of mangle addresses (addresses where the payment key belongs to the user, but the staking key doesn't) easier. *Note*: an observer looking at the blockchain will be able to tell if two staking keys belong to the same user if they are generated from the same wallet with different `address_index` values because the payment keys inside the *base addresses* will be the same. ### Test vectors recovery phrase ``` prevent company field green slot measure chief hero apple task eagle sunset endorse dress seed ``` private key (including chaincode) for `m / 1852' / 1815' / 0' / 2 / 0` ``` b8ab42f1aacbcdb3ae858e3a3df88142b3ed27a2d3f432024e0d943fc1e597442d57545d84c8db2820b11509d944093bc605350e60c533b8886a405bd59eed6dcf356648fe9e9219d83e989c8ff5b5b337e2897b6554c1ab4e636de791fe5427 ``` reward address (with `network_id=1`) ``` stake1uy8ykk8dzmeqxm05znz65nhr80m0k3gxnjvdngf8azh6sjc6hyh36 ``` ## Rationale: how does this CIP achieve its goals? ### Meaning of *account* The term "account" is unfortunately an overloaded term so we clarify all its uses here: #### 1) "Account" as a BIP44 derivation level BIP44 uses the term "account" as one derivation level to mean the following > This level splits the key space into independent user identities, so the wallet never mixes the coins across different accounts. To differentiate this from other usage, we sometimes refer to it as an `account'` (the bip32 notation) or a BIP44 Account. #### 2) "Account" as a transaction model Blockchains like Ethereum does not use the UTXO model and instead uses the [*Account model*](https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos) for transactions. ## Path to Active ### Acceptance Criteria - [x] All notable wallet and tooling providers follow this method of key derivation. ### Implementation Plan - [x] This method of key derivation has been agreed as canonical and has been included in [CIP-1852]. - [x] This method of key derivation has been supported by all wallet and tool providers beginning with the Shelley ledger era. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md ================================================ FILE: CIP-0012/CIP-0012.md ================================================ Moved to [CIP-0012/README.md](./README.md). ================================================ FILE: CIP-0012/README.md ================================================ --- CIP: 12 Title: On-chain stake pool operator to delegates communication Status: Proposed Category: Metadata Authors: - Marek Mahut - Sebastien Guillemot - Ján Hrnko Discussions: - https://forum.cardano.org/t/on-chain-stake-pool-operator-to-delegates-communication/42229 - https://github.com/cardano-foundation/CIPs/pull/44 Created: 2020-11-07 License: CC-BY-4.0 --- ## Abstract Standard format for metadata used in an on-chain communication of stake pool owner towards their delegates. ## Motivation: why is this CIP necessary? Stake pool owners and their delegates lack an on-chain communication standard between them. [CIP-0006](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/README.md) already defines an external feed of a stake pool within the extended metadata. However, there is need for a more verifiable on-chain communication standard that will also provide additional cost associated with such communication to prevent its abuse. ## Specification ### Terminology We define two types of communication metadata, which are distinguished by transaction metadata label as defined in [CIP-0010: Transaction metadata label registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/README.md): * *Message board communication* is a type of metadata that has been included in an on-chain transaction between two base addresses associated with a stake pool operator owner address. Given the onetime fee for this communication, we are considering this as a message board of a stake pool, as it also enables delegates to easier access historical metadata communication. * *Direct delegate communication* is a type of metadata that has been included in an on-chain transaction between a stake pool owner account and a delegate's account. This type of communication is more expensive for the stake pool owner, preventing higher abuse and therefore enables wallets to implement notification granularity. It might be suitable for targeting specific delegates, such as messaging only new joined delegates, loyal delegates, high-amount delegates etc. As per CIP-0010, we assign: * *Message board communication* transaction metadata label `1990`, * *Direct delegate communication* transaction metadata label `1991`. ### Metadata Metadata are written in JSON format and maximum size of metadata around 16KB. The root object property is a 3 bytes UTF-8 encoded string representing the ISO 639-3 language code of the content. | key | Value | Rules | | ---------------------- | -------------------------------------------- | ------------------------------------------ | | `title` *(required)* | Title of the communication | 64 bytes UTF-8 encoded string | | `content` *(required)* | Content of the communication | An array of 64 bytes UTF-8 encoded strings | | | | | `valid` *(optional)* | Slot number the communication becomes valid | Unsigned integer | | `expires` *(optional)* | Slot number until the communication is valid | Unsigned integer | #### Metadata JSON schema The [schema.json](./schema.json) file defines the metadata. #### Metadata example including the transaction metadata label ``` { "1991": [ { "lat": { "title": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do", "content": [ "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do ", "eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e", "nim ad minim veniam, quis nostrud exercitation ullamco laboris n", "isi ut aliquip ex ea commodo consequat. Duis aute irure dolor in", " reprehenderit in voluptate velit esse cillum dolore eu fugiat n", "ulla pariatur. Excepteur sint occaecat cupidatat non proident, s", "unt in culpa qui officia deserunt mollit anim id est laborum." ], "valid": 10661033, "expire": 10669033 } }, { "eng": { "title": "But I must explain to you how all this mistaken idea", "content": [ "But I must explain to you how all this mistaken idea of denounci", "ng of a pleasure and praising pain was born and I will give you ", "a complete account of the system, and expound the actual teachin", "gs of the great explorer of the truth, the master-builder of hum", "an happiness. No one rejects, dislikes, or avoids pleasure itsel", "f, because it is pleasure, but because those who do not know how", " to pursue pleasure rationally encounter consequences." ], "valid": 10661033, "expire": 10669033 } } ] } ``` ## Rationale: how does this CIP achieve its goals? The format of the `content` field is required to be an array of 64 bytes chunks, as this is the maximum size of a JSON field in the Cardano ledger. Tools, such as wallets, are required to recompose the content of the message. The current Cardano protocol parameter for maximum transaction size, that will hold the metadata, is around 16KB. ### Backwards compatibility No backwards compatibility breaking changes are introduced. ## Path to Active ### Acceptance Criteria * [ ] Indications that more than one wallet or backend supports this standard, including: * [ ] Yoroi (in progress from [Implement CIP12 to Yoroi backends](https://www.lidonation.com/en/proposals/implement-cip12-to-yoroi-backends)) ### Implementation Plan * [x] Develop reference implementation ([CIP12 communication tool examples](https://github.com/fivebinaries/cip-metadata-communication-example)) * [x] Offer this standard for implementation in downstream tools and wallets: pending their own decisions about whether and how to display communication messages. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0012/schema.json ================================================ { "$schema": "http://json-schema.org/draft-07/schema", "$id": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0012", "type": "object", "title": "CIP12", "description": "Transaction metadata schema for CIP12", "patternProperties": { "^199{0,1}$": { "type": "array", "items": [ { "type": "object", "patternProperties": { "^[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*$": { "type": "object", "required": [ "title", "content" ], "properties": { "title": { "$id": "#/properties/title", "type": "string", "title": "Title", "description": "Title of the communication.", "maxLength": 64, "examples": [ "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do" ] }, "content": { "$id": "#/properties/content", "type": "array", "title": "Content", "description": "Content of the communication in chunks", "items": [ { "type": "string", "maxLength": 64 } ], "examples": [ [ "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do ", "eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e", "nim ad minim veniam, quis nostrud exercitation ullamco laboris." ] ] }, "valid": { "$id": "#/properties/valid", "type": "integer", "title": "Validity", "description": "Slot number when the communication becomes valid", "examples": [ 10669033 ] }, "expire": { "$id": "#/properties/expire", "type": "integer", "title": "Expiration", "description": "Slot number when the communication expires", "examples": [ 10669033 ] } }, "additionalProperties": false } } } ] } } } ================================================ FILE: CIP-0013/CIP-0013.md ================================================ Moved to [CIP-0013/README.md](./README.md). ================================================ FILE: CIP-0013/README.md ================================================ --- CIP: 13 Title: Cardano URI Scheme Status: Proposed Category: Wallets Authors: - Robert Phair - Sebastien Guillemot - Vicente Almonacid Implementors: N/A Discussions: - https://github.com/Emurgo/EmIPs/pull/2 - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 - https://github.com/cardano-foundation/CIPs/pull/25 - https://github.com/cardano-foundation/CIPs/pull/61 - https://github.com/cardano-foundation/CIPs/pull/86 - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 - https://forum.cardano.org/t/cip-generalized-cardano-urls/57464 - https://github.com/cardano-foundation/CIPs/pull/546 - https://github.com/cardano-foundation/CIPs/pull/559 Created: 2020-09-22 License: CC-BY-4.0 --- ## Abstract This describes a general standard URI scheme with two specific protocols to handle Ada transfers and links to weighted lists of stake pools. ## Motivation: why is this CIP necessary? ### In general: Developers of protocols that use URI schemes should be able to choose unique protocol keywords indicating how these links are handled by applications. Beyond the two earliest defined protocols below, protocols using distinct keywords (e.g. `//stake`) can be defined in other CIPs and implemented without ambiguity by applications which interpret those particular URI protocols. ### For payment URIs: Users who create community content often want donations as a financial incentive. However, forcing users to open their wallet and copy-paste an address lowers the amount of people likely to send tokens (especially if they have to sync their wallet first). If donating was as simple as clicking a link that opens a light wallet with pre-populated fields, users may be more willing to send tokens. URI schemes would enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. ### For stake pool URIs: Centralised sources of information have led a growing amount of stake to be disproportionately assigned to pools pushed near & beyond the saturation point. Stake pool URIs will provide an additional means for small pools to acquire delegation and maintain stability, supporting diversity and possibly fault-tolerance in the Cardano network through a more even distribution of stake. Interfaces that connect delegators with pools beyond the highly contested top choices of the in-wallet ranking algorithms are important to avoid saturation and maintain decentralization. Larger pools and collectives can also use these URIs to link to, and spread delegation between, a family of pools they own to avoid any one of their pools becoming saturated. Pool links allow for interfaces to initiate delegation transactions without requiring any code modifications to the wallets themselves. URIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts. ## Specification The core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`) Examples: ``` Donate Stake with us Split between our 2 related pools Choose our least saturated pool Claim $HOSKY ``` The protocol term (e.g. `//stake`) is called the _authority_ as defined in [Wikipedia > Uniform Resource Identifier > Syntax](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax). ### Choice of URI scheme name `cardano:` is chosen over `ada:` because other projects that implement this standard tend to take the project name over the currency name (this makes sense if we consider this protocol as a generic way for interacting with the blockchain through wallets and dApps - as opposed to a simple payment system). Depending on the protocol registration method (see Rationale), browsers generally enforce a `web+` or `ext+` prefix for non-whitelisted protocols (note: `bitcoin:` was whitelisted; see [registerProtocolHandler > Permitted schemes](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes)). The prefix `ext+` is recommended for extensions, but not mandatory (see [protocol_handlers](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)). ### Grammar & interpretation This top-level definition is mainly to allow switching to a particular protocol for each separately defined `authority`, with a payment link being the default: * When `authority` is unspecified, it is a payment URI (with an address and an optional amount parameter; * When `authority` is explicit (containing `//` followed by the authority keyword), it is defined in the `//stake` case below or in a separate CIP for that protocol. ``` cardanouri = "web+cardano:" (paymentref | authorityref) authorityref = (stakepoolref | otherref) otherref = "//" authority query ``` For grammar reference, see: - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) - [RFC 2234: Augmented BNF for Syntax Specifications: ABNF](https://datatracker.ietf.org/doc/html/rfc2234) - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) #### Payment URI queries ``` paymentref = cardanoaddress [ "?" amountparam ] cardanoaddress = *(base58 | bech32) amountparam = "amount=" *digit [ "." *digit ] ``` The amount parameter must follow the [same rules](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#transfer-amountsize) described in BIP-21, namely, it must be specified in decimal ADA, without commas and using the period (.) decimal separator. #### Stake pool URI queries ``` stakepoolref = "//stake" query query = ( "?" stakepoolpair) *( "&" stakepoolpair) stakepoolpair = stakepool [ "=" proportion] stakepool = poolhexid | poolticker poolhexid = 56HEXDIG poolticker = 3*5UNICODE proportion = *digit [ "." *digit ] ``` For brevity, essential in many Internet contexts, `poolticker` must be supported here in addition to the unambiguous `poolhexid`. ##### Interpretation of `proportion` * If only one stake pool is specified, any proportion is meaningless and ignored. * If all stake pools have a numerical proportion, each component of the resulting stake distribution will have the same ratio as the provided `proportion` to the sum of all the propotions. * Any missing `proportion` is assigned a precise value of `1`. * If a stake pool is listed multiple times, the URI is rejected as invalid. ##### Handling stake pool links When there is more than one pool registered with any of the specified `poolticker` parameters (whether for pool groups which have the same ticker for all pools, or for separate pools using the same ticker), the choice to which pool(s) to finally delegate is left to the user through the wallet UI. The wallet UI should always confirm the exact delegation choice even when it is unambiguous from the URI. When the user has multiple wallets, the wallet UI must select which wallet(s) the user will be delegating from. If, during a wallet or other application's development process, it is still only able to support single pool links, these parameters in the URI query string should (by preference of the wallet UI designers) *either* be ignored *or* generate a warning message, to avoid leading the user to believe they are implementing a currently unsupported but perhaps popularly referenced multi-pool delegation list: * any value for the first URI query argument; * any URI query argument beyond the first. #### Other URI queries An ABNF grammar should be specified and explained similarly for each CIP that defines a new Cardano URI authority by explicitly defining the terms `authority` and `query` as for the "Stake pool" case above. ### Security Considerations 1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. 2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. 3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). ## Rationale: how does this CIP achieve its goals? ### Rationale for general URI scheme #### Why not use Universal links, deep links or other non-protocol-based Solution? An alternative solution to the original problem described above is to use standard URL links in combination with a routing backend system. The routing system is used to redirect to the app's URI. The advantage of this scheme is that it allows to provide a fallback mechanism to handle the case when no application implementing the protocol is installed (for instance, by redirecting to the App Store or Google Play). This is the approach behind iOS Universal Links and Android App Links. In general, it provides a better user experience but requires a centralized system which makes it unsuitable for as a multi-app standard. For background, see - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) - [React Native > Linking](https://reactnative.dev/docs/linking.html) ### Rationale for payment links #### Why confine payment links to address and amount like BIP-21? BIP-21 is limited to only features Bitcoin supports. A similar feature for Ethereum would, for example, also support gas as an extra parameter. BIP-21 is easily extensible but we have to take precaution to avoid different wallets having different implementations of these features as they become available on Cardano. To get an idea of some extra features that could be added, consider this (still under discussion) proposal for Ethereum: [EIP-681](https://eips.ethereum.org/EIPS/eip-681) ### Rationale for stake pool links #### How do URI delegation portfolio links supplement use of JSON files for the same purpose? URIs facilitate the "social element" of delegated staking and pool promotion through a socially familiar, easily accessible, and less centralised convention for sharing stake pool references and potential delegation portfolios without having to construct or host a JSON file. The processing of a JSON file delivered by a web server will depend highly on a user's platform and might not even be seen by the wallet application at all. With a properly associated `web+cardano:` protocol, developers and users have another option available in case JSON files are not delivered properly to the wallet application. For a CIP based on this principle, see [CIP-0017](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0017/README.md). ## Path to Active ### Acceptance Criteria - [x] There exist one or more wallets supporting Payment URIs. - [x] Yoroi - [x] Begin Wallet - [x] There exist one or more wallets supporting Stake Pool URIs. - [ ] TBD - [x] There exist other CIPs or drafts defining additional URI protocols. - [x] [CIP-0099](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0099/README.md) - [x] There exist one or more wallets supporting additional URI protocols. - [x] Yoroi (CIP-0099) - [x] Begin Wallet (CIP-0099) - [x] VESPR (CIP-0099) ### Implementation Plan Encourage wallet and dApp developers to support all currently defined URI protocols, keeping in mind these are each likely to be considered separately: - Payment URIs - Stake Pool URIs - all other URI schemes defined in separate CIPs Education and advocacy about these standards should be done by: - Developers of applications and standards requiring new URI schemes - Cardano sponsoring companies - Community advocates - CIP editors ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0014/CIP-0014.md ================================================ Moved to [CIP-0014/README.md](./README.md). ================================================ FILE: CIP-0014/README.md ================================================ --- CIP: 14 Title: User-Facing Asset Fingerprint Status: Active Category: Tokens Authors: - Matthias Benkort - Rodney Lorrimar Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/64 Created: 2020-02-01 License: CC-BY-4.0 --- ## Abstract This specification defines a user-facing asset fingerprint as a bech32-encoded blake2b-160 digest of the concatenation of the policy id and the asset name. ## Motivation: why is this CIP necessary? The Mary era of Cardano introduces the support for native assets. On the blockchain, native assets are uniquely identified by both their so-called policy id and asset name. Neither the policy id nor the asset name are intended to be human-readable data. On the one hand, the policy id is a hash digest of either a monetary script or a Plutus script. On the other hand, the asset name is an arbitrary bytestring of up to 32 bytes (which does not necessarily decode to a valid UTF-8 sequence). In addition, it is possible for an asset to have an empty asset name, or, for assets to have identical asset names under different policies. Because assets are manipulated in several user-facing features on desktop and via hardware applications, it is useful to come up with a short(er) and human-readable identifier for assets that user can recognize and refer to when talking about assets. We call such an identifier an _asset fingerprint_. ## Specification We define the asset fingerprint in pseudo-code as: ``` assetFingerprint := encodeBech32 ( datapart = hash ( algorithm = 'blake2b' , digest-length = 20 , message = policyId | assetName ) , humanReadablePart = 'asset' ) ``` where `|` designates the concatenation of two byte strings. The `digest-length` is given in _bytes_ (so, 160 bits). ### Reference Implementation #### Javascript [cip14-js](https://www.npmjs.com/package/@emurgo/cip14-js) #### Haskell (GHC >= 8.6.5)
Language Extensions ```hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TypeApplications #-} ```
Imports ```hs -- package: base >= 4.0.0 import Prelude import Data.Function ( (&) ) -- package: bech32 >= 1.0.2 import qualified Codec.Binary.Bech32 as Bech32 -- package: bech32-th >= 1.0.2 import Codec.Binary.Bech32.TH ( humanReadablePart ) -- package: bytestring >= 0.10.0.0 import Data.ByteString ( ByteString ) -- package: cryptonite >= 0.22 import Crypto.Hash ( hash ) import Crypto.Hash.Algorithms ( Blake2b_160 ) -- package: memory >= 0.14 import Data.ByteArray ( convert ) -- package: text >= 1.0.0.0 import Data.Text ( Text ) ```
```hs newtype PolicyId = PolicyId ByteString newtype AssetName = AssetName ByteString newtype AssetFingerprint = AssetFingerprint Text mkAssetFingerprint :: PolicyId -> AssetName -> AssetFingerprint mkAssetFingerprint (PolicyId policyId) (AssetName assetName) = (policyId <> assetName) & convert . hash @_ @Blake2b_160 & Bech32.encodeLenient hrp . Bech32.dataPartFromBytes & AssetFingerprint where hrp = [humanReadablePart|asset|] ``` ### Test Vectors > :information_source: `policy_id` and `asset_name` are hereby base16-encoded; their raw, decoded, versions should be used when computing the fingerprint. ```yaml - policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373 asset_name: "" asset_fingerprint: asset1rjklcrnsdzqp65wjgrg55sy9723kw09mlgvlc3 - policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc37e asset_name: "" asset_fingerprint: asset1nl0puwxmhas8fawxp8nx4e2q3wekg969n2auw3 - policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209 asset_name: "" asset_fingerprint: asset1uyuxku60yqe57nusqzjx38aan3f2wq6s93f6ea - policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373 asset_name: 504154415445 asset_fingerprint: asset13n25uv0yaf5kus35fm2k86cqy60z58d9xmde92 - policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209 asset_name: 504154415445 asset_fingerprint: asset1hv4p5tv2a837mzqrst04d0dcptdjmluqvdx9k3 - policy_id: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209 asset_name: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373 asset_fingerprint: asset1aqrdypg669jgazruv5ah07nuyqe0wxjhe2el6f - policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373 asset_name: 1e349c9bdea19fd6c147626a5260bc44b71635f398b67c59881df209 asset_fingerprint: asset17jd78wukhtrnmjh3fngzasxm8rck0l2r4hhyyt - policy_id: 7eae28af2208be856f7a119668ae52a49b73725e326dc16579dcc373 asset_name: 0000000000000000000000000000000000000000000000000000000000000000 asset_fingerprint: asset1pkpwyknlvul7az0xx8czhl60pyel45rpje4z8w ``` ## Rationale: how does this CIP achieve its goals? ### Design choices - The asset fingerprint needs to be _somewhat unique_ (although collisions are plausible, see next section) and refer to a particular asset. It must therefore include both the policy id and the asset name. - Using a hash gives us asset id of a same deterministic length which is short enough to display reasonably well on small screens. - We use bech32 as a user-facing encoding since it is both user-friendly and quite common within the Cardano eco-system (e.g. addresses, pool ids, keys). ### Security Considerations - With a 160-bit digest, an attacker needs at least 2^80 operations to find a collision. Although 2^80 operations is relatively low (it remains expansive but doable for an attacker), it is considered safe within the context of an asset fingerprint as a mean of _user verification_ within a particular wallet. An attacker may obtain advantage if users can be persuaded that a certain asset is in reality another (which implies to find a collision, and make both assets at the reach of the user). - We recommend however that in addition to the asset fingerprint, applications also show whenever possible a visual checksum calculated from the policy id and the asset name as specified in [CIP-YET-TO-COME](). Such generated images, which are designed to be unique and easy to distinguish, in combination with a readable asset fingerprint gives strong verification means to end users. ## Path to Active ### Acceptance Criteria - [x] Asset fingerprints as described have been universally adopted in: wallets, blockchain explorers, query layers, token minting utilities, NFT specifications, and CLI tools. ### Implementation Plan - [x] Reference implementations available in both Javascript and Haskell. - [x] Public presentation with confirmed interest in adopting this standard in advance of Mary ledger era. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0015/CIP-0015.md ================================================ Moved to [CIP-0015/README.md](./README.md). ================================================ FILE: CIP-0015/README.md ================================================ --- CIP: 15 Title: Registration Transaction Metadata Format Category: Metadata Status: Active Authors: - Sebastien Guillemot , - Rinor Hoxha , - Mikhail Zabaluev Implementors: - Daedalus , - DcSpark , - Eternl , - Flint , - Project Catalyst , - Typhon , - Yoroi Discussions: - https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038 - https://github.com/cardano-foundation/cips/pulls/58 Created: 2020-01-05 License: CC-BY-4.0 --- ## Abstract This CIP details a transaction metadata format, used by Cardano's [Project Catalyst](https://projectcatalyst.io) for voter registrations. ## Motivation: why is this CIP necessary? Project Catalyst uses a sidechain for it's voting system. One of the desirable properties of this sidechain is that even if its' safety is compromised, it doesn't cause a loss of funds on Cardano mainnet. To achieve this, instead of using Cardano wallets' recovery phrase on the sidechain, we introduce the "voting key". However, since Catalyst uses stake-based voting, a user needs to associate their mainnet Ada to their voting key. This can be achieved through a voter registration transaction. We therefore need a voter registration transaction that serves three purposes: 1. Registers a voting key to be included in the sidechain 2. Associates Mainnet ada to this voting key 3. Declare an address to receive Catalyst voting rewards ## Specification ### Voting key format A voting key is simply an ED25519 key. How this key is created is up to the wallet, although it is not recommended that the wallet derives this key deterministicly from a mnemonic used on Cardano. ### Registration metadata format A Catalyst registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it. Notably, there should be four entries inside the metadata map: Voting registration example: ```cddl 61284: { // voting_key - CBOR byte array 1: "0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663", // stake_pub - CBOR byte array 2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee", // reward_address - CBOR byte array 3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4", // nonce 4: 5479467 } ``` The entries under keys 1, 2, 3, and 4 represent the Catalyst voting key, the staking key on the Cardano network, the address to receive rewards, and a nonce, respectively. A registration with these metadata will be considered valid if the following conditions hold: - The nonce is an unsigned integer (of CBOR major type 0) that should be monotonically rising across all transactions with the same staking key. - The advised way to construct a nonce is to use the current slot number. - This is a simple way to keep the nonce increasing without having to access the previous transaction data. - The reward address is a Shelley address discriminated for the same network this transaction is submitted to. To produce the signature field, the CBOR representation of a map containing a single entry with key `61284` and the registration metadata map in the format above is formed, designated here as `sign_data`. This data is signed with the staking key as follows: first, the blake2b-256 hash of `sign_data` is obtained. This hash is then signed using the Ed25519 signature algorithm. The signature metadata entry is added to the transaction under key 61285 as a CBOR map with a single entry that consists of the integer key 1 and signature as obtained above as the byte array value. Signature example: ```cddl 61285: { // signature - ED25119 signature CBOR byte array 1: "0x8b508822ac89bacb1f9c3a3ef0dc62fd72a0bd3849e2381b17272b68a8f52ea8240dcc855f2264db29a8512bfcd522ab69b982cb011e5f43d0154e72f505f007" } ``` ### Versioning This CIP is not to be versioned using a traditional scheme, rather if any large technical changes require a new proposal to replace this one. Small changes can be made if they are completely backwards compatible. ### Changelog Catalyst Fund 3: - added the `reward_address` inside the `key_registration` field. Catalyst Fund 4: - added the `nonce` field to prevent replay attacks; - changed the signature algorithm from one that signed `sign_data` directly to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices. It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated. This has been deferred to a future revision of the protocol. ## Rationale: how does this CIP achieve its goals? The described metadata format allows for the association of a voting key with a stake credential on a Cardano network. ### Associating stake with a voting key Cardano uses the UTxO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually. Although there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small). Given the above, we choose to only associate staking keys with voting keys. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet. ### Future development A future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period. The voter registration metadata in this method will not need an association with the staking key. Therefore, the `staking_pub_key` map entry and the `registration_signature` payload with key `61285` will no longer be required. ## Path to Active ### Acceptance Criteria - [x] This metadata format is implemented by at least 3 wallets - Deadalus - Eternl , - Flint , - Typhon , - Yoroi - [x] This metadata format is used by Catalyst for at least 3 funds - This format has been used up to and included Catalyst fund 10 ### Implementation Plan - [x] Author(s) to provide a schema cddl file - See the [schema file](./schema.cddl) - [x] Author(s) to provide a test vectors file - See [test vector file](./test-vector.md) - [x] Author(s) to provide a npm package to support the creation of this metadata format - [catalyst-registration-js](https://www.npmjs.com/package/@dcspark/catalyst-registration-js) ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [CIP-0008]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md ================================================ FILE: CIP-0015/schema.cddl ================================================ registration_cbor = { 61284: key_registration, 61285: registration_signature } $voting_pub_key /= bytes .size 32 $staking_pub_key /= bytes .size 32 $ed25519_signature /= bytes .size 64 $reward_address /= bytes $nonce /= uint key_registration = { 1 : $voting_pub_key, 2 : $staking_pub_key, 3 : $reward_address, 4 : $nonce, } registration_signature = { 1 : $ed25519_signature } ================================================ FILE: CIP-0015/test-vector.md ================================================ # Test vector for CIP15 ### Inputs Payment **public** key hex ``` 3273a5316e4de228863bd7cf8dac90d57149e1a595f3dd131073b84e35546676 ``` Staking **private** key hex ``` f5beaeff7932a4164d270afde7716067582412e8977e67986cd9b456fc082e3a ``` Catalyst **private** key hex ``` 4820f7ce221e177c8eae2b2ee5c1f1581a0d88ca5c14329d8f2389e77a465655c27662621bfb99cb9445bf8114cc2a630afd2dd53bc88c08c5f2aed8e9c7cb89 ``` ### Intermediate steps Reward address generated from staking key ``` bech32 stake_test1uzhr5zn6akj2affzua8ylcm8t872spuf5cf6tzjrvnmwemcehgcjm hex-encoded e0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef ``` Data to sign (human readable format) ```javascript 61284: { 1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', 4: 1234, }, ``` Metadata (CBOR encoding) ``` a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2 ``` Blake2b-256 hash of metadata ``` a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f ``` ### Output ```javascript { 61284: { 1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', 2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef', 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', 4: 1234 }, 61285: { 1: '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e' } } ``` ================================================ FILE: CIP-0016/CIP-0016.md ================================================ Moved to [CIP-0016/README.md](./README.md). ================================================ FILE: CIP-0016/README.md ================================================ --- CIP: 16 Title: Cryptographic Key Serialisation Formats Status: Active Category: Tools Authors: - Luke Nadur Implementors: - jcli - cardano-signer - cardano-serialization-lib Discussions: - https://github.com/cardano-foundation/CIPs/pull/57 Type: Standards Created: 2020-12-21 License: Apache-2.0 --- ## Abstract This CIP defines serialisation formats for the following types of cryptographic keys across the Cardano eco-system: - Regular Ed25519 keys - [BIP32-Ed25519](https://ieeexplore.ieee.org/document/7966967) extended keys (Ed25519 extended keys with BIP32-style derivation) ## Motivation Throughout the Cardano eco-system, different projects have used different serialisation formats for cryptographic keys. For example, for BIP32-Ed25519 extended signing keys, the [`cardano-crypto`](https://github.com/input-output-hk/cardano-crypto) implementation supports a 128-byte binary serialization format, while [`jcli`](https://input-output-hk.github.io/jormungandr/jcli/introduction.html) and [`cardano-addresses`](https://github.com/input-output-hk/cardano-addresses) supports a 96-byte binary serialization format. Another example would be [`cardano-cli`](https://github.com/input-output-hk/cardano-node) which supports a custom JSON format, referred to as "text envelope", (which can be used for serialising keys) that isn't supported by other projects in the eco-system. This has introduced compatibility problems for both users and developers: - Users cannot easily utilize their keys across different tools and software in the Cardano eco-system as they may be serialized in different ways. - Developers wanting to support the different serialisation formats may need to write potentially error-prone (de)serialisation and conversion operations. Therefore, this CIP aims to define standard cryptographic key serialisation formats to be used by projects throughout the Cardano eco-system. ## Specification ### Verification Keys For the verification (public) key binary format, we simply use the raw 32-byte Ed25519 public key data. This structure should be Bech32 encoded, using one of the appropriate `*_vk` prefixes defined in CIP-0005. ### Extended Verification Keys For extended verification (public) keys, we define the following 64-byte binary format: ``` +-----------------------+-----------------------+ | Public Key (32 bytes) | Chain Code (32 bytes) | +-----------------------+-----------------------+ ``` That is, a 32-byte Ed25519 public key followed by a 32-byte chain code. This structure should be Bech32 encoded, using one of the appropriate `*_xvk` prefixes defined in CIP-0005. ### Signing Keys For the signing (private) key binary format, we simply use the raw 32-byte Ed25519 private key data. This structure should be Bech32 encoded, using one of the appropriate `*_sk` prefixes defined in CIP-0005. ### Extended Signing Keys For extended signing (private) keys, we define the following 96-byte binary format: ``` +---------------------------------+-----------------------+ | Extended Private Key (64 bytes) | Chain Code (32 bytes) | +---------------------------------+-----------------------+ ``` That is, a 64-byte Ed25519 extended private key followed by a 32-byte chain code. This structure should be Bech32 encoded, using one of the appropriate `*_xsk` prefixes defined in CIP-0005. ## Rationale ### Extended Signing Key Format As mentioned in the [Abstract](#abstract), the original [`cardano-crypto`](https://github.com/input-output-hk/cardano-crypto) implementation defined a 128-byte binary serialization format for BIP32-Ed25519 extended signing keys: ``` +---------------------------------+-----------------------+-----------------------+ | Extended Private Key (64 bytes) | Public Key (32 bytes) | Chain Code (32 bytes) | +---------------------------------+-----------------------+-----------------------+ ``` However, as it turns out, keeping around the 32-byte Ed25519 public key is redundant as it can easily be derived from the Ed25519 private key (the first 32 bytes of the 64-byte extended private key). Therefore, because other projects such as [`jcli`](https://input-output-hk.github.io/jormungandr/jcli/introduction.html) and [`cardano-addresses`](https://github.com/input-output-hk/cardano-addresses) already utilize the more compact 96-byte format, we opt to define that as the standard. ## Path to Active ### Acceptance Criteria - [x] Confirm support by applications and tools from different developers: - [x] [jcli](https://github.com/input-output-hk/catalyst-core/tree/main/src/jormungandr/jcli) - [x] [cardano-signer](https://github.com/gitmachtl/cardano-signer) - [x] [cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib) ### Implementation Plan N/A ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). ================================================ FILE: CIP-0017/CIP-0017.json ================================================ { "title": "CIP-0017 - Cardano Delegation Portfolio" , "$schema": "https://json-schema.org/draft-07/schema" , "type": "object" , "required": [ "name" , "pools" ] , "properties": { "name": { "type": "string" , "minLength": 1 } , "description": { "type": "string" , "minLength": 1 } , "author": { "type": "string" , "minLength": 1 } , "pools": { "type": "array" , "minItems": 1 , "items": { "type": "object" , "required": [ "id" , "weight" ] , "properties": { "id": { "type": "string" , "minLength": 56 , "maxLength": 56 , "contentEncoding": "base16" } , "name": { "type": "string" , "minLength": 1 } , "ticker": { "type": "string" , "minLength": 3 , "maxLength": 5 } , "weight": { "type": "integer" , "minimum": 1 } } } } } } ================================================ FILE: CIP-0017/CIP-0017.md ================================================ Moved to [CIP-0017/README.md](./README.md). ================================================ FILE: CIP-0017/README.md ================================================ --- CIP: 17 Title: Cardano Delegation Portfolio Status: Inactive (abandoned for lack of interest) Category: Tools Authors: - Matthias Benkort Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/82 Created: 2020-04-02 License: CC-BY-4.0 --- ## Abstract This document details a common format for sharing Cardano delegation portfolio across various tools and wallets. ## Motivation: why is this CIP necessary? Stakeholders have indicated the desire to split their stake in various sizes and delegate to n pools from a single wallet/mnemonic. Albeit there are no monetary incentive for users to do this, the desire to drive decentralisation is sufficiently prevalent to justify it. Furthermore, stakeholders want to introduce a certain social element to this activity by sharing their delegation portfolio with other stakeholders. This specification should help to standardize the representation of portfolios across tools for more interoperability. ## Specification ### Overview We'll use JSON as a data format for it is commonly used and supported across many programming languages, and is also relatively readable on itself. Portfolios should abide by the [JSON schema given in appendix](CIP-0017.json). At minima, a portfolio should cover a list of delegation choices (pools and weights) and have a human-readable name for easier identification. ### Weights For each pool, we demand a `weight` which can capture a certain stake proportion within the portfolio. The value is an integer, and relative to other weights in the portfolio. For example, a portfolio with two pools and respective weights of `1` and `2` means that we expect users to assign twice more stake to the second pool than the first. Fundamentally, this means that for every 3 Ada, 1 Ada should go to the first pool, and 2 Ada should go to the second. Note that this is equivalent to having weights of `10`/`20` or `14` / `28`. Weights are ultimately interpreted as fractions. Portfolios which treat all stake pools equally should use the same weight (e.g. `1`) for each pool. ### Example ```json { "name": "Metal 🤘" , "description": "Pools supporting Metal music across the world." , "pools": [ { "id": "d59123f4dce7c62fa74bd37a759c7ba665dbabeb28f08b4e5d4802ca" , "name": "Dark Tranquility" , "ticker": "DARK" , "weight": 42 } , { "id": "5f3833027fe8c8d63bc5e75960d9a22df52e41bdf62af5b689663c50" , "ticker": "NITRO" , "weight": 14 } , { "id": "a16abb03d87b86f30bb743aad2e2504b126286fe744d3d2f6a0b4aec" , "name": "Loudness" , "ticker": "LOUD" , "weight": 37 } , { "id": "9f9bdee3e053e3102815b778db5ef8d55393f7ae83b36f906f4c3a47" , "weight": 25 } ] } ``` ## Rationale: how does this CIP achieve its goals? 1. JSON is widely used, widely supported and quite lightweight. Makes for a reasonable choice of data format. 2. Using JSON schema for validation is quite common when dealing with JSON and it's usually sufficiently precise to enable good interoperability. 3. The portfolio should only capture information that are not subject to radical change. That is, stake pools parameters like pledge or fees are excluded since they can be changed fairly easily using on-chain certificate updates. 4. The JSON schema doesn't enforce any `additionalProperties: false` for neither the top-level object definition nor each stake pool objects. This allows for open extension of the objects with custom fields at the discretion of applications implementing this standard. The semantic of well-known properties specified in this document is however fixed. 5. Since the portfolio format isn't _immediately user-facing_, we favor base16 over bech32 for the pool id's encoding for there's better support and tooling for the former. ### Backwards Compatibility #### Adafolio The format used by [Adafolio](https://adafolio.com) share a lot of similarities with the proposed format in this CIP. In order to power its frontend user interface, Adafolio contains however several fields which we consider _too volatile_ and unnecessary to the definition of a portfolio. This doesn't preclude the format used by Adafolio as a valid portfolio format (see also point (4). in the rationale above). The only point of incompatibility regards the `pool_id` field (in Adafolio) vs the `id` field (in this proposal) which we deem more consistent with regards to other field. ## Path to Active ### Acceptance Criteria - [ ] At least one pair of applications (wallets, explorers or other tools) together support the following: - [ ] generation of the specified portfolio file format - [ ] interpretation and use of the specified portfolio file format ### Implementation Plan - [ ] Provide a reference implementation and/or parsing library to read and/or write files in this schema. # Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0018/CIP-0018.md ================================================ Moved to [CIP-0018/README.md](./README.md). ================================================ FILE: CIP-0018/README.md ================================================ --- CIP: 18 Title: Multi-Stake-Keys Wallets Status: Proposed Category: Wallets Authors: - Matthias Benkort Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/83 Created: 2020-03-18 License: CC-BY-4.0 --- ## Abstract This document describes how to evolve sequential wallets from Cardano to support multiple stake keys. This proposal is an extension of [CIP-1852] and [CIP-0011]. ## Motivation: why is this CIP necessary? Cardano wallets originally approached stake delegation by considering a single stake key per wallet. While this was beneficial in terms of ease of implementation and simplicity of reasoning, this is unsuitable for many users with large stakes. Indeed, the inability to split out the stake into multiple pools often leads to over-saturation of existing pools in case of delegation. The only workaround so far requires users to split their funds into multiple accounts and manage them independently. This can be quite cumbersome for a sufficiently large number of accounts. Even for smaller actors, it can be interesting to delegate to multiple pools to limit risks. Pools may underperform or simply change their parameters from a day to another (for which wallets still do not warn users about). Delegating to more pools can reduce the impact of pool failure (for one or more epochs) or unattended changes in pool fees. It may as well be a matter of choice if users do want to delegate to several independent entities for various other reasons. Another concern regards privacy leaks coming with the existing wallet scheme. Since the same stake key is associated with every single address of the wallet, it creates a kind of watermark that allows for tracing all funds belonging to the same wallet very easily (it suffices to look at the stake part of addresses). By allowing the wallet to hold multiple stake keys, rotating through them when creating changes does make the traceability a bit harder. One could imagine using a hundred stake keys delegated to the same pool. ## Specification ### Overview The restriction from [CIP-0011] regarding the derivation index reserved for stake key is rendered obsolete by this specification. That is, one is allowed to derive indexes beyond the first one (index = 0) to effectively administrate multi-stake keys accounts. The creation of new stake keys is however tightly coupled to the registration of associated stake keys to allow wallet software to automatically discover stake keys on-chain. In this design, stake key indexes form **at all time a contiguous sequence with no gap**. ### Key registration We introduce the concept of _UTxO stake key pointer_ to reliably keep track of stake keys on the blockchain. The gist is to require that every key registration and/or deregistration consume and create a special UTxO which in itself is pointing to the next available stake key of the wallet. Such pointer allows piggybacking on the existing UTxO structure to cope with concurrency issues and rollbacks that are inherent to a distributed system such as Cardano. Plus, this mechanism only demands a low overhead for wallet software and may be recognized as a special spending pattern by hardware devices. In more details, we require that beyond the first stake key (index = 0), all registrations must satisfy the following rules: 1. Stake keys must be derived sequentially, from 0 and onwards. 1. Every stake key registration must be accompanied by a matching delegation certificate. 1. Every registration transaction must create a special output of exactly `minUTxOValue` Ada such that its address is an enterprise address with a single **payment part** using the stake key hash of the next available stake key of the wallet to be registered after processing the registration transaction. 1. Unless no key beyond the first one is registered, every registration transaction must consume the special UTxO stake key pointer corresponding to the previous key registration (resp. de-registration) for that wallet. > **Note** The `minUTxOValue` is fixed by the protocol. It is defined as part of the Shelley genesis and can be updated via on-chain protocol updates. At the moment, this equals 1 Ada on the mainnet. #### Example For example, a wallet that has already registered stake keys 0, 1 and 2 have a UTxO for which the payment part is a hash of the stake key at index=3. If the wallet wants to register two new stake keys at index 3 and 4, it'll do so in a single transaction, by consuming the pointer UTxO and by creating a new one for which the payment part would be a hash of the stake key at index=5. Note that this only requires two signatures from stake keys at indexes 3 and 4. ### Key de-registration Key de-registrations work symmetrically and require that: 1. Stake keys are de-registered sequentially, from the highest and downwards. 1. Unless the first key of the wallet is being de-registered, every de-registration transaction must create a special output of exactly `minUtxOValue` Ada such that its address is an enterprise address with a single **payment part** using the stake key hash of the next stake key of the wallet after processing the de-registration transaction. 1. Every de-registration must consume the special UTxO stake key pointer corresponding to the previous key de-registration (resp. registration) for that wallet. ### Backwards Compatibility As stated in the introduction, this proposal is built on top of [CIP-0011] such that backward compatibility is preserved when a single key is used. In fact, The management of the first stake key at index 0 remains unchanged and does not require any pointer. This preserves backward compatibility with the existing design for a single stake key wallet and offers a design that can be implemented on top, retro-actively. Nevertheless, we do assume that existing wallets following [CIP-0011] are already fully capable of discovering addresses using stake keys not belonging to the wallet. Some may even report them as _mangled_. > **Note** An address is said _mangled_ when it has a stake part, and the stake part isn't recognized as belonging to its associated wallet. That is, the payment part and the stake part appear to come from two different sources. This could be the case if the address has been purposely constructed in such a way (because the stake rights and funds are managed by separate entities), or because the stake part refers to a key hash which is no longer known of the wallet (because the associated key registration was rolled back). As a result, this extension would not incapacitate existing wallets since the payment ownership is left untouched. However, wallets not supporting the extension may display addresses delegated to keys beyond the first one as mangled and may also fail to report rewards correctly across multiple keys. We deem this to be an acceptable and fairly minor consequence but encourage existing software to raise awareness about this behaviour. ## Rationale: how does this CIP achieve its goals? - Carrying an extra UTxO pointer makes it possible to not worry (too much) about concurrency issues and problems coming with either, multiple instances of the wallet (like many users do between a mobile and desktop wallet) or the usual rollbacks which may otherwise create gaps in the indexes. By forcing all registration (resp. deregistration) transactions to be chained together, we also enforce that any rollbacks do maintain consistency of the index state: if any intermediate transaction is rolled back, then transactions they depend on are also rolled back. - The first registration induces an extra cost for the end-user for the wallet needs to create a new UTxO with a minimum value. That UTxO is however passed from registration to registration afterwards without any extra cost. It can also be fully refunded upon de-registering the last stake key. So in practice, it works very much like a key deposit. - We do not allow mixing up key registration and key deregistration as part of the same transaction for it makes the calculation of the pointer trickier for wallet processing transactions. A single transaction either move the pointer up or down. - There's in principle nothing preventing someone from sending money to the special key-registration tracking address. Wallets should however only keep track of UTxOs created as part of transactions that register stake keys (and have therefore been authorized by the wallet itself). Applications are however encouraged to collect any funds sent to them in an ad-hoc manner on such keys. ## Path to Active ### Acceptance Criteria - [ ] There exists one or more reference implementations with appropriate testing illustrating the viability of this approach and specification. ### Implementation Plan - [ ] Update this proposal to account for the Conway Ledger era, which brings new types of certificates for registering stake keys. - [ ] Develop the proposed Reference Implementation as suggested when this CIP was originally published (see Discussion link in header for history). - [ ] Contact wallet and dApp representatives in the community to develop and maintain interest in their support for this specification. # Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852 [CIP-0011]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0011 ================================================ FILE: CIP-0019/CIP-0019-byron-addresses.cddl ================================================ BYRON_ADDRESS = ( #6.24(<>) , uint32 ; crc32 of the CBOR serialized address payload ) BYRON_ADDRESS_PAYLOAD = ( bytes .size 28 ; blake2b_224(sha3_256(BYRON_ADDRESS_ROOT)) digest , BYRON_ADDRESS_ATTRIBUTES , BYRON_ADDRESS_TYPE ) BYRON_ADDRESS_ROOT = ( BYRON_ADDRESS_TYPE , BYRON_ADDRESS_SPENDING_DATA , BYRON_ADDRESS_ATTRIBUTES ) BYRON_ADDRESS_TYPE = 0 ; Public key // 2 ; Redemption BYRON_ADDRESS_SPENDING_DATA = ( 0, bytes .size 64 ) ; Ed25519 Public key | Associated BIP-32 chain code // ( 2, bytes .size 32 ) ; Ed25519 Public key BYRON_ADDRESS_ATTRIBUTES = { 1 : <> ; Double CBOR-encoded ChaCha20/Poly1305 encrypted digest, see CIP for details. , 2 : <> ; CBOR-encoded network discriminant } BYRON_DERIVATION_PATH_CIPHERTEXT = ; Obtained by encrypting a serialized derivation path bytes .size 28 BYRON_DERIVATION_PATH = [ * uint32 ] ================================================ FILE: CIP-0019/CIP-0019-cardano-addresses.abnf ================================================ ADDRESS = %b0000 | NETWORK-TAG | KEY-HASH | KEY-HASH ; type 00, Base Shelley address \ %b0001 | NETWORK-TAG | SCRIPT-HASH | KEY-HASH ; type 01, Base Shelley address \ %b0010 | NETWORK-TAG | KEY-HASH | SCRIPT-HASH ; type 02, Base Shelley address \ %b0011 | NETWORK-TAG | SCRIPT-HASH | SCRIPT-HASH ; type 03, Base Shelley address \ %b0100 | NETWORK-TAG | KEY-HASH | POINTER ; type 04, Pointer Shelley address deprecated in Conway \ %b0101 | NETWORK-TAG | SCRIPT-HASH | POINTER ; type 05, Pointer Shelley address deprecated in Conway \ %b0110 | NETWORK-TAG | KEY-HASH ; type 06, Payment Shelley address \ %b0111 | NETWORK-TAG | SCRIPT-HASH ; type 07, Payment Shelley address \ %b1000 | BYRON-PAYLOAD ; type 08, Byron / Bootstrap address \ %b1110 | NETWORK-TAG | KEY-HASH ; type 14, Stake Shelley address \ %b1111 | NETWORK-TAG | SCRIPT-HASH ; type 15, Stake Shelley address NETWORK-TAG = %b0000 ; Testnet \ %b0001 ; Mainnet POINTER = VARIABLE-LENGTH-UINT ; slot number | VARIABLE-LENGTH-UINT ; transaction index | VARIABLE-LENGTH-UINT ; certificate index VARIABLE-LENGTH-UINT = (%b1 | UINT7 | VARIABLE-LENGTH-UINT) / (%b0 | UINT7) UINT7 = 7BIT KEY-HASH = 28OCTET SCRIPT-HASH= 28OCTET BYRON-PAYLOAD = *OCTET ; see 'Byron Addresses' section or cddl specification. ================================================ FILE: CIP-0019/CIP-0019.md ================================================ Moved to [CIP-0019/README.md](./README.md). ================================================ FILE: CIP-0019/README.md ================================================ --- CIP: 19 Title: Cardano Addresses Status: Active Category: Ledger Authors: - Matthias Benkort Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/78 Created: 2020-03-25 License: CC-BY-4.0 --- ## Abstract This specification describes the structure of addresses in Cardano, covering both addresses introduced in the Shelley era and the legacy format from the Byron era. ## Motivation: why is this CIP necessary? Document design choices for posterity. Most applications interacting with the Cardano blockchain will likely not have any need for this level of details, however, some might. This CIP is meant to capture this knowledge. ## Specification ### Introduction In Cardano, an address is a **sequence of bytes** that conforms to a particular format, which we describe below. However, users will typically come into contact with addresses only after these addresses have been **encoded** into sequences of human-readable characters. In Cardano, the [Bech32][] and [Base58][] encodings are used to encode addresses, as opposed to standard hexadecimal notation (Base16, example `0x8A7B`). These encoded sequence of characters have to be distinguished from the byte sequences that they encode, but lay users will (and should) perceive the encoded form as "the" address. ### User-facing Encoding By convention, **Shelley** and stake addresses are encoded using **[Bech32][]**, with the exception that Cardano does not impose a length limit on the sequence of characters. The human-readable prefixes are defined in [CIP-0005][]; the most common prefix is `addr`, representing an address on mainnet. Bech32 is the preferred encoding, as its built-in error detection may protect users against accidental misspellings or truncations. Again by convention, **Byron** addresses are encoded in **[Base58][]**. Historically, Byron addresses were introduced before the design of Bech32, which solves various issues of the Base58 encoding format (see [Bech32's motivation](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#motivation) for more detail). Byron addresses were however kept as Base58 to easily distinguish them from new addresses introduced in Shelley, massively making use of Bech32 for encoding small binary objects. Cave: In principle, it is possible for a Shelley address to be encoded in Base58 and a Byron address to be encoded in Bech32 (without length limit). However, implementations are encouraged to reject addresses that were encoded against convention, as this helps with the goal that lay users only encounter a single, canonical version of every address. Examples of different addresses encoded in different eras: | Address Type | Encoding | Example | | --- | --- | --- | | Byron | Base58 | `37btjrVyb4KDXBNC4haBVPCrro8AQPHwvCMp3RFhhSVWwfFmZ6wwzSK6JK1hY6wHNmtrpTf1kdbva8TCneM2YsiXT7mrzT21EacHnPpz5YyUdj64na` | | Shelley | bech32 | `addr1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5eg0yu80w` | | stake | bech32 | `stake1vpu5vlrf4xkxv2qpwngf6cjhtw542ayty80v8dyr49rf5egfu2p0u` | ### Binary format In Cardano, the sequence of bytes (after decoding with Bech32 or Base58) that represents an address comprises two parts, a one-byte **header** and a **payload** of several bytes. Depending on the header, the interpretation and length of the payload varies. In the header-byte, bits [7;4] indicate the type of addresses being used; we'll call these four bits the **header type**. The remaining four bits [3;0] are either unused or refer to what we'll call the **network tag**. There are currently 11 types of addresses in Cardano which we'll divide into three categories: [Shelley addresses], [stake addresses], and [Byron addresses]. ``` 1 byte variable length <------> <-------------------> ┌────────┬─────────────────────┐ │ header │ payload │ └────────┴─────────────────────┘ 🔎 ╎ 7 6 5 4 3 2 1 0 ╎ ┌─┬─┬─┬─┬─┬─┬─┬─┐ ╰╌╌╌╌╌╌╌╌ │t│t│t│t│n│n│n│n│ └─┴─┴─┴─┴─┴─┴─┴─┘ ``` See also the more detailed [ABNF grammar in annex]. #### Network Tag Except for [Byron addresses] (type 8 = `1000`), the second half of the header (bits [3;0]) refers to the network tag which can have the following values and semantics. Other values of the network tag are currently reserved for future network types. In the case of [Byron addresses], bits [3;0] have a completely separate definition detailed in the section below. Network Tag (`. . . . n n n n`) | Semantic --- | --- `....0000` | Testnet(s) `....0001` | Mainnet #### Shelley Addresses There are currently 8 types of Shelley addresses summarized in the table below: Header type (`t t t t . . . .`) | Payment Part | Delegation Part --- | --- | --- (0) `0000....` | `PaymentKeyHash` | `StakeKeyHash` (1) `0001....` | `ScriptHash` | `StakeKeyHash` (2) `0010....` | `PaymentKeyHash` | `ScriptHash` (3) `0011....` | `ScriptHash` | `ScriptHash` (4) `0100....` | `PaymentKeyHash` | `Pointer` (5) `0101....` | `ScriptHash` | `Pointer` (6) `0110....` | `PaymentKeyHash` | ø (7) `0111....` | `ScriptHash` | ø - `PaymentKeyHash` and `StakeKeyHash` refer to `blake2b-224` hash digests of Ed25519 verification keys. How keys are obtained is out of the scope of this specification. Interested readers may look at [CIP-1852] for more details. - `ScriptHash` refer to `blake2b-224` hash digests of serialized monetary scripts. How scripts are constructed and serialized is out of the scope of this specification. - `Pointer` is detailed in the section below. ##### Payment part Fundamentally, the first part of a Shelley address indicates the ownership of the funds associated with the address. We call it the **payment part**. Whoever owns the payment parts owns any funds at the address. As a matter of fact, in order to spend from an address, one must provide a witness attesting that the address can be spent. In the case of a `PaymentKeyHash`, it means providing a signature of the transaction body made with the signing key corresponding to the hashed public key (as well as the public key itself for verification). For monetary scripts, it means being able to provide the source script and meet the necessary conditions to validate the script. ##### Delegation part The second part of a Shelley address indicates the owner of the stake rights associated with the address. We call it the **delegation part**. Whoever owns the delegation parts owns the stake rights of any funds associated with the address. In most scenarios, the payment part and the delegation part are owned by the same party. Yet it is possible to construct addresses where both parts are owned and managed by separate entities. We call such addresses **mangled addresses** or **hybrid addresses**. Some addresses (types 6 and 7) carry no delegation part whatsoever. Their associated stake can't be delegated. They can be used by parties who want to prove that they are not delegating funds which is typically the case for custodial businesses managing funds on the behalf of other stakeholders. Delegation parts can also be defined in terms of on-chain [pointers]. ##### Pointers > **Note** > From the Conway ledger era, new pointer addresses cannot be added to Mainnet. In an address, a **chain pointer** refers to a point of the chain containing a stake key registration certificate. A point is identified by 3 coordinates: - An absolute slot number - A transaction index (within that slot) - A (delegation) certificate index (within that transaction) These coordinates form a concise way of referring to a stake key (typically half the size of a stake key hash). They are serialized as three variable-length positive numbers following the ABNF grammar here below: ```abnf POINTER = VARIABLE-LENGTH-UINT ; slot number | VARIABLE-LENGTH-UINT ; transaction index | VARIABLE-LENGTH-UINT ; certificate index VARIABLE-LENGTH-UINT = (%b1 | UINT7 | VARIABLE-LENGTH-UINT) / (%b0 | UINT7) UINT7 = 7BIT ``` #### Stake Addresses Like [Shelley addresses], stake addresses (also known as **reward addresses**) start with a single header byte identifying their type and the network, followed by 28 bytes of payload identifying either a stake key hash or a script hash. Header type (`t t t t . . . .`) | Stake Reference --- | --- (14) `1110....` | `StakeKeyHash` (15) `1111....` | `ScriptHash` - `StakeKeyHash` refers to `blake2b-224` hash digests of Ed25519 verification keys. How keys are obtained is out of the scope of this specification. Interested readers may look at [CIP-1852] for more details. - `ScriptHash` refers to `blake2b-224` hash digests of serialized monetary scripts. How scripts are constructed and serialized is out of the scope of this specification. #### Byron Addresses Before diving in, please acknowledge that a lot of the supported capabilities of Byron addresses have remained largely unused. The initial design showed important trade-offs and rendered it unpractical to sustain the long-term goals of the network. A new format was created when introducing Shelley and Byron addresses were kept only for backward compatibility. Byron addresses are also sometimes called **bootstrap addresses**. Like many other objects on the Cardano blockchain yet unlike Shelley addresses, Byron addresses are [CBOR]-encoded binary objects. Conveniently enough, the first 4 bits of their first byte are always equal to `1000....` which allows us to land back on our feet w.r.t to the address type. Their internal structure is however vastly different and a bit unusual. ``` ┌────────┬──────────────┬────────┐ │ root │ attributes │ type │ └────────┴──────────────┴────────┘ ╎ ╎ ╎ ╎ ╎ ╰╌╌ Standard ╎ ╎ ╰╌╌ Redeem ╎ ╎ ╎ ╰╌╌ Derivation Path ╎ ╰╌╌ Network Tag ╎ ╎ ┌────────┬─────────────────┬──────────────┐ ╰╌╌╌╌ double-hash ( │ type │ spending data │ attributes │ ) └────────┴─────────────────┴──────────────┘ ╎ ╰╌╌ Verification Key ╰╌╌ Redemption Key ``` The address `root` uniquely identifies the address and is a double-hash digest (SHA3-256, and then Blake2b-224) of the address type, spending data, and attributes. Then comes the address attributes which are both optional. The network tag is present only on test networks and contains an identifier that is used for network discrimination. The [derivation path] (detailed below) was used by legacy so-called random wallets in the early days of Cardano and its usage was abandoned with the introduction of Yoroi and so-called **Icarus addresses**. Finally, the address type allows for distinguishing different sub-types of Byron addresses. **Redeem addresses** are used inside the Byron genesis configuration and were given to early investors who helped to fund the project. A full and more detailed [CDDL specification of Byron addresses] is given in the annex to the CIP. ##### Derivation path Historically, Cardano wallets have been storing information about the wallet structure directly within the address. This information comes in the form of two derivation indexes (in the sense of child key derivation as defined in [BIP-0032]) which we call **derivation path**. To protect the wallet's anonymity, the derivation path is stored encrypted using a ChaCha20/Poly1305 authenticated cipher. ### Test Vectors All test vectors below use the following payment key, stake key, script and pointer: - `addr_vk1w0l2sr2zgfm26ztc6nl9xy8ghsk5sh6ldwemlpmp9xylzy4dtf7st80zhd` - `stake_vk1px4j0r2fk7ux5p23shz8f3y5y2qam7s954rgf3lg5merqcj6aetsft99wu` - `script1cda3khwqv60360rp5m7akt50m6ttapacs8rqhn5w342z7r35m37` - `(2498243, 27, 3)` ```yaml mainnet: type-00: addr1qx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgse35a3x type-01: addr1z8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs9yc0hh type-02: addr1yx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs2z78ve type-03: addr1x8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shskhj42g type-04: addr1gx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrzqf96k type-05: addr128phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtupnz75xxcrtw79hu type-06: addr1vx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzers66hrl8 type-07: addr1w8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcyjy7wx type-14: stake1uyehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gh6ffgw type-15: stake178phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcccycj5 testnet: type-00: addr_test1qz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs68faae type-01: addr_test1zrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgsxj90mg type-02: addr_test1yz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shsf5r8qx type-03: addr_test1xrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs4p04xh type-04: addr_test1gz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer5pnz75xxcrdw5vky type-05: addr_test12rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtupnz75xxcryqrvmw type-06: addr_test1vz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerspjrlsz type-07: addr_test1wrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcl6szpr type-14: stake_test1uqehkck0lajq8gr28t9uxnuvgcqrc6070x3k9r8048z8y5gssrtvn type-15: stake_test17rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcljw6kf ``` ## Rationale: how does this CIP achieve its goals? As stated in [Motivation](#motivation-why-is-this-cip-necessary) this CIP is provided for informational purposes regarding a single deliberate design. Further rationale and motivation for this design are available in the [Design Specification for Delegation and Incentives in Cardano - Section 3.2 :: Addresses & Credentials ](https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-delegation.pdf). ### Reference Implementation(s) - [IntersectMBO/cardano-addresses (Byron & Shelley)](https://github.com/IntersectMBO/cardano-addresses) - [IntersectMBO/cardano-ledger-specs (Byron)](https://github.com/IntersectMBO/cardano-ledger-specs/blob/d5eaac6c4b21a8e69dc3a5503a72e3c3bfde648e/byron/ledger/impl/src/Cardano/Chain/Common/Address.hs) - [IntersectMBO/cardano-ledger-specs (Shelley)](https://github.com/IntersectMBO/cardano-ledger-specs/blob/1e7e6e03a46e8118b318ed105214767aec0f3976/shelley/chain-and-ledger/executable-spec/src/Shelley/Spec/Ledger/Address.hs) ## Path to Active ### Acceptance Criteria - [x] Confirmation by consensus, with no reported dispute since publication, that this document fully descibes how Cardano addresses are universally implemented. ### Implementation Plan - [x] Publish this documentation for confirmation that it accurately describes conventionals of universal use. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [ABNF grammar in annex]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0019/CIP-0019-cardano-addresses.abnf [base58]: https://tools.ietf.org/id/draft-msporny-base58-01.html [bech32]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki [BIP-0032]: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [Byron addresses]: #byron-addresses [CBOR]: https://www.rfc-editor.org/rfc/rfc8949 [CDDL specification of Byron addresses]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0019/CIP-0019-byron-addresses.cddl [CIP-0005]: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005 [CIP-1852]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852 [derivation path]: #derivation-path [pointers]: #pointers [Shelley addresses]: #shelley-addresses [Stake addresses]: #stake-addresses ================================================ FILE: CIP-0020/CIP-0020.md ================================================ Moved to [CIP-0020/README.md](./README.md). ================================================ FILE: CIP-0020/README.md ================================================ --- CIP: 20 Title: Transaction message/comment metadata Status: Active Category: Metadata Authors: - Martin Lang - Ola Ahlman - Andrew Westberg Implementors: - CNTools - JorManager - StakePoolOperator Scripts - Cardanoscan.io - AdaStat.net - Eternl Wallet - CardanoWall - Nami Wallet - CNFT - Cardano Explorer - SundaeSwap - Minswap - MuesliSwap - DripDropz.io - Typhon Wallet - Ledger Live Discussions: - https://github.com/cardano-foundation/CIPs/pull/100 - https://github.com/cardano-foundation/CIPs/pull/394 Created: 2021-06-13 License: CC-BY-4.0 --- ## Abstract This describes a basic JSON schema to add messages/comments/memos as transaction metadata by using the metadatum label **674**: allowing informational, commerical, or any other text to be included in a transaction on the Cardano blockchain. ## Motivation: why is this CIP necessary? We have the utilities on the cardano blockchain now since the introduction of the "allegra-era". A simple consens about adding messages, comments or memos to transactions is still missing. So the CIP authors came together to form a first implementation of this. It is straight and simple, additional keys and content can be added later. The IOG main wallet `Daedalus` can now also directly show attached metadata information in the transaction details view. This CIP is the missing link to bring it together. Some of the current Tools/Sites/Explorers that have implemented it already: * [CNTools](https://cardano-community.github.io/guild-operators/#/Scripts/cntools) * [JorManager](https://bitbucket.org/muamw10/jormanager/) * [StakePoolOperator Scripts](https://github.com/gitmachtl/scripts) * [Cardanoscan.io](https://cardanoscan.io) * [AdaStat.net](https://adastat.net) * [Eternl Wallet](https://eternl.io) * [CardanoWall](https://cardanowall.com) * [Nami Wallet](https://namiwallet.io) * [CNFT](https://cnft.io) * [Cardano Explorer](https://cexplorer.io) * [SundaeSwap](https://https://sundaeswap.finance/) * [Minswap](https://minswap.org/) * [MuesliSwap](https://muesliswap.com/) * [DripDropz.io](https://dripdropz.io/) * [Typhon Wallet](https://typhonwallet.io/) * [Ledger Live](https://www.ledger.com/) ## Specification The specification for the individual strings follow the general design specification for JSON metadata, which is already implemented and in operation on the cardano blockchain. The used metadatum label is **`"674":`**, this number was choosen because it is the T9 encoding of the string "msg". The message content has the key **`"msg":`** and consists of an **array** of individual **message-strings**. The number of theses **message-strings** must be at least one for a single message, more for multiple messages/lines. Each of theses individual **message-strings** array entries must be at most 64 bytes when UTF-8 encoded. ### Format: ``` { "674": { "msg": [ "message-string 1" //Optional: ,"message-string 2","message-string 3" ... ] } } ``` ### Example for a single message/comment/memo: ``` json { "674": { "msg": [ "This is a comment for the transaction xyz, thank you very much!" ] } } ``` ### Example for multiple messages/comments/memos: ``` json { "674": { "msg": [ "Invoice-No: 1234567890", "Customer-No: 555-1234", "P.S.: i will shop again at your store :-)" ] } } ```  

### Some Integration examples **Ledger Live** is offering a memo field ![image](https://user-images.githubusercontent.com/47434720/204649383-c34ae733-e136-41b8-8fa8-619dde978621.png) **Daedalus** shows the metadata text (could be improved if CIP is implemented): ![image](https://user-images.githubusercontent.com/47434720/121822100-85b38a80-cc9d-11eb-9d13-1869746a69b2.png) **Cardanoscan.io**, **Adastat.net** and other tools implemented it already, to show messages along transactions: ![image](https://user-images.githubusercontent.com/47434720/204633595-d865c7ee-0c30-4af1-bb55-3c0ad323b58c.png) ![image](https://user-images.githubusercontent.com/47434720/204634111-256c6c18-974a-41f5-a6e4-b9edee8f9d62.png) **eternl.io** has added it with a message field on the sending-page, and shows it also on the transactions-page: ![image](https://user-images.githubusercontent.com/47434720/204632224-5be33098-00f6-41da-a2f0-7c138b28354f.png) ![image](https://user-images.githubusercontent.com/47434720/204632802-33f1afa5-d9b2-494f-84fe-d7f0594a7f1b.png) **StakePool Operator Scripts**: It works on the commandline like any other script of the collection by just adding the "msg: ..." parameter to a transaction. This automatically generates the needed metadata.json structure and attaches it to the transaction itself. ![image](https://user-images.githubusercontent.com/47434720/129110626-6bc5b3c3-102d-4793-b508-7d4190b31cf7.png) **CNTools**:
![image](https://user-images.githubusercontent.com/47434720/130353491-fc0f3a69-1937-4e72-b680-c04cc069b5c4.png) ## Rationale: how does this CIP achieve its goals? This design is simple, so many tools on the cardano blockchain can implement it easily. The array type was choosen to have consistency, no need to switch between a string or an array format, or testing against a string or array format. Updates in the future are possible, like adding a versioning key `"ver":`, adding a key `"utxo":` to provide specific data for every tx-out#idx in the transaction, adding the `"enc":` key like for encrypted messages, making subarrays in the message-strings, etc. But for now, we need a common agreement to provide general messages/comments/memos with this CIP. The starting design war choosen as simple as possible to keep the additional transaction fees as low as possible. ### Wallet Implementation Would be a good idea to hide the message/comment/note behind a "show unmoderated content" button/drop-down. Like the Metadata display on the Cardano Explorer. Also, it should be displayed as plain-text non-clickable. To enhance security further, URLs could be automatically deleted or hidden from such comments, to not welcome bad actors with phishing attempts. Another solution to start with would be to really limit the character space for display in Wallets, like limiting it to `a-zA-z0-9` and a handful of special chars like `+-_#()[]:` without a `.<>"/\` chars, so a domain or html code would not work. Last points are worth for discussions of course, because it would also filter out unicode. ### Handling ill-formed 674 metadata It is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label "674" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the "674" metadata label and the "msg" key underneath it. There should also be a check, that the provided data within that "msg" key is an array. All other implementations like a missing "msg" key, or a single string instead of an array, should be marked by the display-implementor as "invalid". Additional keys within the "674" label should not affect the parsing of the "msg" key. As written above, we will likely see more entries here in the future like a "version" key for example, so additional keys should not harm the parsing of the "msg" key. ### Implementation conclusion A transaction message should be considered valid if the following apply: * Label = 674. * has property "msg". * msg property contains an array of strings, even for a single-line message. * Each line has a maximum length of 64 characters. * If there are additional properties, they don't invalidate the message. They can just be ignored. If any of the above is not met, ignore the metadata as a transaction message. Can still be displayed as general metadata to the transaction. _Optional to consider for the implementer:_ * For message creation both single-line and multi-line input should be considered valid. The wallet/tool isn't required to support multi-line input. * Message display in explorers/wallets should however preferably support multi-line messages even if it only supports single-line on creation. Not a requirement but should at least indicate that there are more data if only the first line is displayed. Maybe a link to explorer etc in the case it's not possible to solve in UI in a good way. ## Path to Active ### Acceptance Criteria - [x] There exist a variety of wallet-based, dApp, and CLI implementations of this standard, developed by a a wide variety of providers, and is in regular use. ### Implementation Plan As per the first two Discussion links: - [x] The format in this CIP has been the ground base for supporting transaction messages / comments / memos. - [x] The format and its interpretation have been considered and implemented by both creator/sender implementations and wallet/receiver/display implementations. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0021/CIP-0021.md ================================================ Moved to [CIP-0021/README.md](./README.md). ================================================ FILE: CIP-0021/README.md ================================================ --- CIP: 21 Title: Transaction requirements for interoperability with hardware wallets Status: Active Category: Wallets Authors: - Gabriel Kerekes - Rafael Korbas - Jan Mazak Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/107 Created: 2021-06-15 License: CC-BY-4.0 --- ## Abstract This CIP describes all the restrictions applicable to Cardano transactions which need to be signed by hardware wallets. ## Motivation: why is this CIP necessary? Due to certain limitations of hardware (abbrev. HW) wallets, especially very small memory and a limited set of data types supported by Ledger, HW wallets are not able to process all valid transactions which are supported by Cardano nodes. The limitations also result in an inability of HW wallets to see the whole transaction at once. Transaction data are streamed into HW wallets in small chunks and they compute a rolling hash of the transaction body which is signed at the end. Consequently, a HW wallet only provides witness signatures, and the transaction body which was signed has to be reconstructed by the client. We thus need a common transaction serialization format which will allow no ambiguity. In addition, the format must define ordering of map keys in such a way that it’s possible to check for duplicate keys by HW wallets. Several of the restrictions also stem from security or UX concerns, e.g. the forbidden combination of pool registration certificates and withdrawals in a single transaction (see reasoning below). To ensure interoperability, SW wallets and other tools working with HW wallets should only use transactions which conform to the following rules. ## Specification Certain transaction elements, described as allowed in this document, might not be supported by some HW wallets. Support also depends on HW wallet firmware or app versions. If transaction signing fails for a transaction which is built according to this specification, make sure to check the documentation of the HW wallet you are using. > **Note:** It might take some time for recent Cardano ledger spec changes to be implemented for HW wallets. Thus it might happen that further restrictions might apply on top of the restrictions mentioned in this CIP until the changes are implemented on HW wallets. ### Canonical CBOR serialization format Transactions must be serialized in line with suggestions from [Section 3.9 of CBOR specification RFC](https://datatracker.ietf.org/doc/html/rfc7049#section-3.9). In particular: - Integers must be as small as possible. - The expression of lengths in major types 2 through 5 must be as short as possible. - The keys in every map must be sorted from lowest value to highest. - Indefinite-length items must be made into definite-length items. See the RFC for details. ### Tags in sets Conway introduced optional 258 tags in certain items that are considered sets semantically but encoded as arrays in CBOR. HW wallets will support this optional encoding, but it must be consistent across the transaction: either there are no tags 258 in sets, or there are such tags everywhere (as described in the CDDL specification). ### Transaction body #### Unsupported entries The following transaction body entries must not be included: * `6 : update` * `20 : proposal procedures` #### Integers HW wallets support at most `int64` for signed integers and `uint64` for unsigned integers i.e. larger integers are not supported overall. Additionally, any integer value must fit in the appropriate type. #### Numbers of transaction elements The number of the following transaction elements individually must not exceed `UINT16_MAX`, i.e. 65535: - inputs in transaction body - outputs in transaction body - asset groups (policy IDs) in an output or in the mint field - tokens (asset names) in an asset group - certificates in transaction body - pool owners in a pool registration certificate - pool relays in a pool registration certificate - withdrawals in transaction body - collateral inputs in transaction body - required signers in transaction body - reference inputs in transaction body - the total number of witnesses For voting procedures, it is only allowed to include a single voter with a single voting procedure. #### Optional empty lists and maps Unless mentioned otherwise in this CIP, optional empty lists and maps must not be included as part of the transaction body or its elements. Since Conway, the [CDDL specification](https://github.com/intersectmbo/cardano-ledger/tree/master/eras/conway/impl/cddl-files) is stricter, so many arrays are now treated as non-empty sets, and some maps are required to be non-empty. HW wallets enforce this in many cases. #### Outputs A new, "post Alonzo", output format has been introduced in the Babbage ledger era which uses a map instead of an array to store the output data. For now, both the "legacy" (array) and "post Alonzo" (map) output formats are supported by HW wallets but we encourage everyone to migrate to the "post Alonzo" format as support for the "legacy" output format might be removed in the future. Both formats can be mixed within a single transaction, both in outputs and in the collateral return output. ##### Legacy outputs Outputs containing no multi-asset tokens must be serialized as a simple tuple, i.e. `[address, coin, ?datum_hash]` instead of `[address, [coin, {}], ?datum_hash]`. ##### Post Alonzo outputs If the `data` of `datum_option` is included in an output, it must not be empty. `script_ref` (reference script) must also not be empty if it is included in an output. #### Multiassets Since multiassets (`policy_id` and `asset_name`) are represented as maps, both need to be sorted in accordance with the specified canonical CBOR format. Also, an output or the mint field must not contain duplicate `policy_id`s and a policy must not contain duplicate `asset_name`s. #### Certificates Certificates of the following types are not supported and must not be included: * `genesis_key_delegation` * `move_instantaneous_rewards_cert` * `stake_vote_deleg_cert` * `stake_reg_deleg_cert` * `vote_reg_deleg_cert` * `stake_vote_reg_deleg_cert` If a transaction contains a pool registration certificate, then it must not contain: - any other certificate; - any withdrawal; - mint entry; - any output containing datum, datum hash or reference script; - script data hash; - any collateral input; - any required signer; - collateral return output; - total collateral; - reference inputs; - voting procedures; - treasury value; - donation value. It is allowed to arbitrarily combine other supported certificate types. #### Withdrawals Since withdrawals are represented as a map of reward accounts, withdrawals also need to be sorted in accordance with the specified canonical CBOR format. A transaction must not contain duplicate withdrawals. #### Auxiliary data HW wallets do not serialize auxiliary data because of their complex structure. They only include the given auxiliary data hash in the transaction body. The only exception is Catalyst voting registration because it requires a signature computed by the HW wallet. In this exceptional case, auxiliary data must be encoded in their "tuple" format: ``` [ transaction_metadata: { * transaction_metadatum_label => transaction_metadatum }, auxiliary_scripts: [ * native_script ]] ``` The `auxiliary_scripts` must be an array of length 0. ## Rationale: how does this CIP achieve its goals? ### Canonical CBOR serialization format As HW wallets don't return the whole serialized transaction, a common CBOR serialization is needed so that software wallets and other tools interacting with HW wallets are be able to deterministically reproduce the transaction body built and signed by the HW wallet. The specified canonical CBOR format is consistent with how certain other data are serialized (e.g. Plutus script data in Alonzo) and allows the use of standard CBOR libraries out of the box. ### Transaction body #### Credentials Generally, HW wallets require that any key hash credential (and withdrawal address too) is given by the derivation path of the key (otherwise the user will not be aware that the key belongs to his wallet). This does not apply to Plutus transactions where HW wallets instead aim for maximum flexibility at the cost of users being potentially misled. (It is very hard to foresee how Plutus script authors would use various transaction elements and any restriction applied by HW wallets might break a use case which is otherwise perfectly sound and safe.) When signing a transaction, Ledger and Trezor use a _transaction signing mode_ that describes upfront what the intent is (the software wallet is responsible for choosing an appropriate mode). The transaction is then validated according to the mode. There are, in principle, four options: * _Stake pool registration transaction_. Stake pool registration certificates are signed on their own, the transaction should contain nothing that is not necessary. * _Ordinary transaction_. Credentials must be given as key paths. * _Multisig transaction_. Credentials must be script hashes; only [multisig keys](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1854/README.md) are allowed. * _Plutus transaction_. The only mode that allows elements related to running Plutus scripts (script data hash etc.). No extra restrictions on transaction elements or their combinations. The drawback is that more is shown to the user (e.g. witnesses are not hidden as in ordinary transactions). Please only use this mode if no other mode is sufficient. This brief description does not aim to capture the full complexity of signing modes; always verify that transactions you aim to construct are supported by other tools you will rely on (hardware wallets, software wallets, command-line tools like [`cardano-hw-cli`](https://github.com/vacuumlabs/cardano-hw-cli) etc.). #### Multiassets Allowing duplicate `policy_id`s (or `asset_name`s) might lead to inconsistencies between what is displayed to the user and how nodes and other tools might interpret the duplicate keys, i.e. all policies (or asset names) would be shown to the user, but nodes and other tools might eventually interpret only a single one of them. #### Certificates Combining withdrawals and pool registration certificates isn't allowed because both are signed by staking keys by pool owners. If it was allowed to have both in a transaction then the witness provided by a pool owner might inadvertently serve as a witness for a withdrawal for the owner's account. #### Withdrawals Similarly to multiassets, allowing duplicate withdrawals might lead to inconsistencies between what is displayed to the user and how nodes and other tools might interpret the duplicate keys. #### Auxiliary data The specified auxiliary data format was chosen in order to be compatible with other Cardano tools, which mostly use this serialization format. ### Stake key signing vs other keys A DRep witness can serve for both certificates and votes at the same time. Unlike with stake keys (where combining pool registration with e.g. withdrawals is forbidden), no restriction is imposed on the combination of certificates and votes. We think that votes and DRep certificates are rare and substantially distinguished parts of a transaction, signed by DRep keys which are likely to only be used by users with deep enough understanding (and, unlike stake keys, are always visible when providing witnesses). A single vote or a DRep certificate is unlikely to have a major effect (esp. not on the loss of funds). If submitting unintended votes turns out to be a problem, it is likely better to solve it on the level of Cardano blockchain ledger by providing a mechanism allowing for replacing or cancelling votes. ## Path to Active ### Acceptance Criteria - [x] Confirmation (by default if no ongoing incompatibilities) since Alonzo ledger era that this interoperability between software and hardware wallets has been generally achieved. ### Implementation Plan - [x] Tools exist which can be used to validate or transform transactions into a HW wallet compatible format if possible: - [x] [`cardano-hw-interop-library`](https://github.com/vacuumlabs/cardano-hw-interop-lib) - [x] [`cardano-hw-cli`](https://github.com/vacuumlabs/cardano-hw-cli) (which uses the interop library) ## Restrictions for specific hardware devices The following list of features with missing support on particular hardware devices is subject to occasional changes. Some features might be added, but some could also be removed (e.g. if they take too much space needed for other features). #### Ledger: Nano S Plus, Nano X, Stax Everything described here as allowed should (eventually) work on these devices. #### Ledger: Nano S Missing features: - signing operational certificates - derivation of native script hashes - stake pool registration and retirement - display of certain details of Byron addresses (though addresses themselves are supported) #### Trezor Missing features: - derivation of stake pool cold keys - signing operational certificates - signing pool registration certificates as operator (only as owner is allowed) - derivation of DRep and constitutional committee keys - DRep certificates (registration, retirement, update) - constitutional committee certificates - voting procedures - treasury and donation elements of transactions ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0022/CIP-0022.md ================================================ Moved to [CIP-0022/README.md](./README.md). ================================================ FILE: CIP-0022/README.md ================================================ --- CIP: 22 Title: Pool operator verification Status: Active Category: Tools Authors: - Andrew Westberg - Martin Lang - Ola Ahlman Implementors: - CNCLI - JorManager - StakePoolOperator Scripts - CNTools Discussions: - https://github.com/cardano-foundation/CIPs/pull/102 Created: 2021-06-21 License: CC-BY-4.0 --- ## Abstract This proposal describes a method allowing a stakepool operator to provide credentials to verify that they are the rightful manager for their stakepool. ## Motivation: why is this CIP necessary? Many websites such pooltool.io, adapools.org, and others need to allow pool operators special access to modify the way their pool appears on the website. SPOCRA and other organizations also have a need to allow voting on proposals and ensure that each vote cast is from a valid pool operator. Today, these sites and organizations all use different techniques for validating pool operators. pooltool.io - Validates operators by receiving 1 ada spent from the pool's registered rewards account adapools.org - Validates operators by requesting that the operator include a special generated value in their extended pool metadata json file. This proposal is to simplify and streamline a single approach that all can reference in order to verify that a pool operator is who they say they are. ## Specification In order to achieve the goals of this CIP, the pool operator needs to provide some credential or credentials to the validating party which cannot be spoofed. The VRF pool keys and VRF signature algorithm implemented in libsodium are chosen to build and provide this credential/signature. This signature can then be validated and the operator verified without ever exposing any of the pool's private key information. This technique is very similar to verifying that a block produced by another pool is valid. The only difference is that instead of validating the slot seed for a given pool, we're validating a pre-determined message hash. ### Verification Steps: 1. Stakepool Operator (SPO) sends their pool_id and public pool.vrf.vkey to the Validating Server (VS) 2. VS validates that the vrf hash in the pool's registration certificate on the blockchain matches the blake2b hash of the sent vkey. Note: The VS should use the latest registration certificate on the chain for matching as the VRF is a "hot" key and can be changed at any time by the pool operator. A single point-in-time verification is sufficient to properly identify the pool operator. 3. The VS sends a challenge request to the SPO which is the domain of the VS and a random 64-byte nonce. 4. The SPO creates a blake2b hash of "cip-0022{domain}{random_nonce}" and then signs this with their private VRF key. 5. The SPO sends this to VS as the challenge response within a 5-minute window to the VS 6. The VS validates the signed challenge response ### Code Example (Validating server): ```kotlin // Server side, create inputs for a challenge. Store this and only allow responses // within 5 minutes to be successful. val random = SecureRandom() val domain = "pooltool.io" val nonce = ByteArray(64) random.nextBytes(nonce) println("domain: $domain, nonce: ${nonce.toHexString()}") ``` ### Code Example (Pool Operator side): ```kotlin // Node operational VRF-Verification-Key: pool.vrf.vkey //{ // "type": "VrfVerificationKey_PraosVRF", // "description": "VRF Verification Key", // "cborHex": "5820e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381" //} // // Node operational VRF-Signing-Key: pool.vrf.skey //{ // "type": "VrfSigningKey_PraosVRF", // "description": "VRF Signing Key", // "cborHex": "5840adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381" //} // We assume the pool operator has access to the pool's vrf secret key val skeyCbor = "5840adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381".hexToByteArray() val vrfSkey = (CborReader.createFromByteArray(skeyCbor).readDataItem() as CborByteString).byteArrayValue() val vkeyCbor = "5820e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381".hexToByteArray() val vrfVkey = (CborReader.createFromByteArray(vkeyCbor).readDataItem() as CborByteString).byteArrayValue() // Client side, construct and sign the challenge val challengeSeed = "cip-0022${domain}".toByteArray() + nonce val challenge = SodiumLibrary.cryptoBlake2bHash(challengeSeed, null) println("challenge: ${challenge.toHexString()}") val signature = SodiumLibrary.cryptoVrfProve(vrfSkey, challenge) println("signature: ${signature.toHexString()}") ``` ### Code Example (Validating server): ```kotlin // Server side, verify the message based on only knowing the pool_id, public vkey, signature, and constructing // the challenge ourselves the same way the client should have. val challengeSeed = "cip-0022${domain}".toByteArray() + nonce val challenge = SodiumLibrary.cryptoBlake2bHash(challengeSeed, null) // Get the vkeyHash for a pool from the "query pool-params" cardano-cli command // This comes from the pool's registration certificate on the chain. val vkeyHash = "f58bf0111f8e9b233c2dcbb72b5ad400330cf260c6fb556eb30cefd387e5364c".hexToByteArray() // Verify that the vkey from the latest minted block on the blockchain (or the client supplied if they // haven't yet minted a block) is the same as the one on-chain in the pool's registration certificate val vkeyHashVerify = SodiumLibrary.cryptoBlake2bHash(vrfVkey, null) assertThat(vkeyHash).isEqualTo(vkeyHashVerify) // Verify that the signature matches val verification = SodiumLibrary.cryptoVrfVerify(vrfVkey, signature, challenge) println("verification: ${verification.toHexString()}") println("Verification SUCCESS!") ``` ### Code Example output: ``` vrfSkey: adb9c97bec60189aa90d01d113e3ef405f03477d82a94f81da926c90cd46a374e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381 vrfVkey: e0ff2371508ac339431b50af7d69cde0f120d952bb876806d3136f9a7fda4381 domain: pooltool.io, nonce: c936ab102a86442c7120f75fa903b41d9f6f984a9373a6fa0b7b8cb020530318bdec84512468681c7d8454edf3a0e0bf21f59c401028030a8fb58117edc8b03c challenge: 6977c480a3acb4c838ba95bb84d1f4db1c2591ea6ebe5805ed0394f706c23b05 signature: a3c9624aa14f6f0fba3d47d3f9a13bb55f0790eacd7bad9a89ce89fecb9e7eb8ca0d19aea8b6a7be39ae3e8b9768211b4d8aa789e82c1e150826fe15a0b0323f08e18635deb94c49d7f4421750d44903 signatureHash: 9ca4c7e63ba976dfbe06c7a0e6ec4aec5a5ef04b721ffc505222606dfc3d01572ddce3b55ac5c9470f061f137dafe31669794ea48118d1682d888efbe0cb4d1a verification: 9ca4c7e63ba976dfbe06c7a0e6ec4aec5a5ef04b721ffc505222606dfc3d01572ddce3b55ac5c9470f061f137dafe31669794ea48118d1682d888efbe0cb4d1a Verification SUCCESS! ``` ## Rationale: how does this CIP achieve its goals? Implementing this simplifies and commonizes the process for verifying that a pool operator is who they say they are in 3rd party systems. Having a common way of verify pool operators also allows simple integration into pool management tools. There is also some overlap with [CIP-0006](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0006/README.md#extended-metadata---flexible-but-validable) and the `rawdata-sign` command although it specifies generating a new key instead of utilizing the pool's existing `vrf.skey` to sign like this proposal. ## Path to Active ### Acceptance Criteria - [x] Tools that have implemented, or are implementing, this proposal: - [x] [CNCLI](https://github.com/AndrewWestberg/cncli) - [x] [JorManager](https://bitbucket.org/muamw10/jormanager/) - [x] [StakePoolOperator Scripts](https://github.com/gitmachtl/scripts) - [x] [CNTools](https://cardano-community.github.io/guild-operators/#/Scripts/cntools) ### Implementation Plan - [x] Consensus between providers of the most popular tools and CLIs for stake pool operators that this approch is viable and desirable. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0023/CIP-0023.md ================================================ Moved to [CIP-0023/README.md](./README.md). ================================================ FILE: CIP-0023/README.md ================================================ --- CIP: 23 Title: Fair Min Fees Authors: - Shawn McMurdo - Ryan Wiley Category: Ledger Status: Proposed Created: 2021-02-04 Discussions: - https://forum.cardano.org/t/fair-min-fees-cip/47534 - https://github.com/cardano-foundation/CIPs/pull/66 Implementors: [] License: CC-BY-4.0 --- ## Abstract This CIP introduces a new protocol parameter, `minPoolMargin`, which specifies a lower bound on the variable fee (margin) a stake pool may set. The parameter is introduced initially set to `0` to avoid disrupting existing pool certificates. This proposal does not change or reduce the existing minimum fixed pool fee (`minPoolCost`). ## Motivation: why is this CIP necessary? The current minimum fixed pool fee places a large and unfair burden on delegators to pools with smaller amounts of stake. This incentivizes people to delegate to pools with higher stake causing centralization and creating an unequal playing field for stake pool operators. Using a minimum variable pool fee reduces the imbalance between stake pools with less or more stake to a more reasonable range that allows for more fair competition between stake pools and more fair rewards for delegators to stake pools with less stake. This creates a more fair marketplace for all stake pool operators and increases decentralization, which is a goal of Cardano. ## Specification This CIP introduces a new protocol parameter, `minPoolMargin`, which represents the minimum variable fee (margin) that a stake pool can set. This parameter is distinct from the existing `minPoolCost`, which represents the minimum fixed fee a pool can set. Both limits are enforced independently by the ledger. - `minPoolMargin` defines the lower bound for the pool margin (variable fee), i.e., the minimum allowable percentage of rewards a pool can take. Pool registration and update certificates MUST have `margin >= minPoolMargin`. - `minPoolCost` retains its current meaning and enforcement as the minimum fixed fee a pool can set. This CIP does not prescribe specific values for either parameter. Concrete values for `minPoolMargin` and `minPoolCost` are to be chosen and enacted through the standard protocol parameter update process. ### Backward Compatibility To maintain compatibility for existing pool certificates whose current margin is below the new `minPoolMargin`, the ledger's rewards calculation should treat the protocol parameter `minPoolMargin` as the effective margin for those pools. In other words, if a pool's margin is less than `minPoolMargin`, the protocol-level `minPoolMargin` overrides the pool's registered `margin` during reward calculation. This minimizes disruption and lets legacy pool certificates remain valid while ensuring the ledger enforces the new minimum fee during reward distribution. It is also recommended to introducce the hard-fork with `minPoolMargin` initially set to `0`. Doing so minimizes migration friction for stake pool operators and gives governance time to raise the parameter to its target value through the normal paramater change governance action process. Should this clamping approach prove infeasible, pool certificates with a margin lower than `minPoolMargin` would need to be re-registered with compliant values, but the goal is to avoid disruption as much as possible. ## Rationale: how does this CIP achieve its goals? The PHP code in minfees.php in the pull request allows exploration of the effects of choosing different values for the minimum fixed and variable fees. Running minfees without any arguments gives the usage message as below. ``` php minfees.php Usage: php minfees.php min_fixed_fee: Minimum fixed fee in ADA. An integer greater than or equal to 0. min_rate_fee: Minimum rate fee in decimal. Example: 1.5% = .015 A real number greater than or equal to 0. pledge: Optional pledge amount in ADA. Defaults to 100000 A real number greater than or equal to 0. ``` Running minfees with the proposed values gives the following comparison of current and proposed pool operator and staker results at various pool stake levels. ``` php minfees.php 50 .015 100000 Reserve: 13b Total stake: 32b Tx fees: 0 Rewards available in epoch: 31.2m Pool saturation: 64m Pledge: 100k Staker Delegation: 100k Current Fixed Fee: 340 Current Rate: 0% New Fixed Fee: 50 New Rate: 1.5% +---------- Current ----------+ +-------- Proposed ---------+ Pool Total Pool Staker Staker Current Pool Staker Staker New Stake Rewards Cur Fee Cur Fee Cur Rew Fee % New Fee New Fee New Rew Fee % 2m 1501 340 17 58.1 22.7% 71.8 3.6 71.5 4.8% 5m 3752 340 6.8 68.2 9.1% 105.5 2.1 72.9 2.8% 10m 7503 340 3.4 71.6 4.5% 161.8 1.6 73.4 2.2% 20m 15007 340 1.7 73.3 2.3% 274.4 1.4 73.7 1.8% 30m 22511 340 1.1 73.9 1.5% 386.9 1.3 73.7 1.7% 64m 48023 340 0.5 74.5 0.7% 769.6 1.2 73.8 1.6% ``` Definitions: Pool Stake - Total stake delegated to pool. Total Rewards - Total rewards generated by the pool in one epoch. Pool Cur Fee - The total amount of fees taken by the pool with current parameters. Staker Cur Fee - The amount of fees paid by a staker who delegates 100k ADA with current parameters. Staker Cur Rew - The amount of rewards received by a staker who delegates 100k ADA with current parameters. Current Fee % - The percentage of rewards taken by the pool as fees with current parameters. Pool New Fee - The total amount of fees taken by the pool with proposed parameters. Staker New Fee - The amount of fees paid by a staker who delegates 100k ADA with proposed parameters. Staker New Rew - The amount of rewards received by a staker who delegates 100k ADA with proposed parameters. New Fee % - The percentage of rewards taken by the pool as fees with proposed parameters. Note: All amounts other than %s are in ADA. The table above shows that currently a delegator staking 100k ADA to a stake pool with 2m ADA total delegation to the pool is paying an exorbitant 22.7% in fees while the same delegator staking with a fully saturated pool would only pay 0.7% in fees. This is a substantial and unfair advantage that large pools have in the stake pool marketplace. This is a strong incentive to centralize stake to fewer larger pools which reduces the resiliency of the network. The proposed minimum fees bring this imbalance into a more reasonable range of 1.6% to 4.8%. It is much more likely that a small stake pool with other advantages or selling points would be able to convince a delegator to accept about 2 less ADA in rewards per epoch for their 100k delegation than about 17 ADA as in the current case. This is particularly true as the price of ADA increases. At current price of $0.90 USD, a delegator staking 100k ADA is giving up over $1000 USD per year by delegating to a small pool! This does not even include the amount lost by comounding rewards being staked over the year. 16.5 ADA/epoch * 73 epochs/year = 1204.5 ADA/year 1204.5 ADA/year * $0.90 USD/ADA = $1084.05 USD/year With proposed parameters the same delegator would only be giving up about $150 USD per year to support a small pool. 2.3 ADA/epoch * 73 epochs/year = 167.9 ADA/year 167.9 ADA/year * $0.90 USD/ADA = $151.11 USD/year The calculations below show that given the price increase in ADA compared to when the protocol parameters were first set, we can maintain viable funding for stake pool operators with the proposed parameter changes. Annual pool operator funding given initial parameters: 340 ADA/epoch * $0.08 USD/ADA = $27.20 USD/epoch $27.20 USD/epoch * 73 epochs/year = $1985.60 USD/year Annual pool operator funding given proposed parameters for stake pool with 2 million ADA delegation: 71.8 ADA/epoch * $0.90 USD/ADA = $64.62 USD/epoch $64.62 USD/epoch * 73 epochs/year = $4717.26 USD/year Annual pool operator funding given proposed parameters for fully saturated stake pool: 769.6 ADA/epoch * $0.90 USD/ADA = $692.64 USD/epoch $692.64 USD/epoch * 73 epochs/year = $50,562.72 USD/year In summary, the proposed parameter changes would create a more fair marketplace for stake pools, provide more fair rewards for delegators to smaller pools and would lower incentives for centralization providing a more resilient network. ### Test Cases See the minfees.php code to test different potential values of the parameters. ## Path to Active ### Acceptance Criteria - Consensus on initial parameter value – An initial value for the new protocol parameter `minPoolMargin` must be agreed upon before hard-fork combinator (HFC) activation. The choice should consider operational viability, empirical analyses, and community feedback. - Endorsement by Technical Bodies – The Cardano Parameter-Change Proposals (PCP) Committee and the Intersect Technical Steering Committee (TSC) should both recommend the proposal as technically sound and aligned with the protocol’s long-term roadmap. - Stakeholder Concurrence – A majority of stake pool operators (SPOs), ecosystem tooling maintainers, dReps, and other infrastructure providers must signal readiness to upgrade. - Governance Ratification – The on-chain Hard-Fork Governance Action must pass the requisite dRep and Constitutional Committee thresholds, establishing legal-constitutional legitimacy and stakeholder support for the change. ### Implementation Plan - Community Deliberation (Preparation Phase) - Publish the finalized CIP revision and present it to the PCP committee, TSC, CIP Editors, and wider community channels (Discord, X, Cardano Forum, etc.). - Collect structured feedback, particularly on candidate values for the new parameter values and iterate until broad technical consensus emerges. - Specification & Code Integration (Development Phase) - Once initial parameter values are determined, integrate the new rewards calculation logic and governance features for the new parameter into cardano-node and related libraries (ledger, CLI, wallet APIs). - Determine the best method to deal with existing pool registration certificates that currently have a variable fee lower than what the new `minPoolMargin` parameter allows. - Submit pull requests to the canonical repositories; obtain code reviews from IOG, CF, and community contributors. - Release a new protocol version that includes the changes made in this CIP. - Use a dedicated pre-production testnet that mirrors main-net parameters but enforces the new changes, allowing SPOs and exchanges to test end-to-end flows. - Readiness Sign-off (Testing Phase) - Require at least two weeks of uninterrupted testnet stability plus green results from regression and property-based tests. - Monitor ecosystem dApps and tooling to confirm that major node implementations, explorers, wallets, and exchange integrations support the new rule set. - On-chain Governance (Ratification Phase) - File the Hard-Fork Governance Action on-chain with the agreed initial parameter value tagged for the next hard fork event. - Modify the existing Cardano Constitution to include definitions and guardrails for the new protocol parameters and have it ratified by the tripartite government of Cardano. - Mobilize dRep outreach to ensure quorum and super-majority passage; concurrently, the Constitutional Committee validates procedural compliance. - Hard-Fork Activation (Deployment Phase) - Upon successful vote, the hard fork event is automatically triggered upon epoch turnover. - Monitor main-net metrics during the changeover epoch; provide real-time support for any late-upgrading SPOs. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0023/minfees.php ================================================ " . PHP_EOL; echo " min_fixed_fee: Minimum fixed fee in ADA." . PHP_EOL; echo " An integer greater than or equal to 0." . PHP_EOL; echo " min_rate_fee: Minimum rate fee in decimal. Example: 1.5% = .015" . PHP_EOL; echo " A real number greater than or equal to 0." . PHP_EOL; echo " pledge: Optional pledge amount in ADA. Defaults to 100000" . PHP_EOL; echo " A real number greater than or equal to 0." . PHP_EOL; exit; } if ($pledge < 1000000) { $pledge_str = round($pledge / 1000, 1) . "k"; } else { $pledge_str = round($pledge / 1000000, 1) . "m"; } // Protocol parameters $k = 500; $rho = 0.003; $a0 = 0.3; $tau = .2; // Assumptions $current_fixed = 170; $current_rate = 0.0; $reserve = 1690000000; $total_stake = 37000000000; $fees = 32000; $staker = 100000; if ($staker < 1000000) { $staker_str = round($staker / 1000, 1) . "k"; } else { $staker_str = round($staker / 1000000, 1) . "m"; } // Calculated values $R = (($reserve * $rho) + $fees) * (1 - $tau); $z0 = 1 / $k; $saturation = $total_stake / $k; $half_saturation = $saturation / 2; $ds = array(2000000, 5000000, 10000000, 20000000, $half_saturation, $saturation); $os = array(); foreach ($ds as $d) { $os[] = $d / $total_stake; } echo "Reserve: " . round($reserve / 1000000000, 1) . "b" . PHP_EOL; echo "Total stake: " . round($total_stake / 1000000000, 1) . "b" . PHP_EOL; echo "Tx fees: " . $fees . PHP_EOL; echo "Rewards available in epoch: " . round($R / 1000000, 1) . "m" . PHP_EOL; echo "Pool saturation: " . round($saturation / 1000000, 1) . "m" . PHP_EOL; echo "Pledge: " . $pledge_str . PHP_EOL; echo "Staker Delegation: " . $staker_str . PHP_EOL; echo "Current Fixed Fee: " . $current_fixed . PHP_EOL; echo "Current Rate: " . round($current_rate * 100, 1) . '%' . PHP_EOL; echo "New Fixed Fee: " . $new_fixed . PHP_EOL; echo "New Rate: " . round($new_rate * 100, 1) . '%' . PHP_EOL; echo PHP_EOL; echo "\t\t/---------- Current ----------\\ /-------- Proposed ---------\\" . PHP_EOL; echo "Pool\tTotal\tPool\tStaker\tStaker\tCurrent\tPool\tStaker\tStaker\tNew" . PHP_EOL; echo "Stake\tRewards\tFee\tFee\tRew\tFee %\tFee\tFee\tRew\tFee %" . PHP_EOL; echo "---------------------------------------------------------------------" . PHP_EOL; $i = 0; foreach ($os as $o) { // Rewards Formula $s = $pledge / $total_stake; $rewards = round(($R / (1 + $a0)) * ($o + ($s * $a0 * (($o - ($s * (($z0 - $o) / $z0))) / $z0)))); $current_rate_basis = $rewards - $current_fixed; $current_rate_fee = $current_rate_basis * $current_rate; $current_fees = $current_fixed + $current_rate_fee; if ($current_fees > $rewards) { $current_fees = $rewards; } $current_fee_per_staker = $current_fees * ($staker / $ds[$i]); $current_reward_per_staker = ($rewards - $current_fees) * ($staker / $ds[$i]); $current_fee_percent = round(($current_fees / $rewards) * 100, 1); $new_rate_basis = $rewards - $new_fixed; $new_rate_fee = $new_rate_basis * $new_rate; $new_fees = $new_fixed + $new_rate_fee; $new_fee_per_staker = $new_fees * ($staker / $ds[$i]); $new_reward_per_staker = ($rewards - $new_fees) * ($staker / $ds[$i]); $new_fee_percent = round(($new_fees / $rewards) * 100, 1); $d_str = round($ds[$i] / 1000000, 1) . 'm'; echo $d_str . "\t" . $rewards . "\t" . round($current_fees, 1) . "\t" . round($current_fee_per_staker, 1) . "\t" . round($current_reward_per_staker, 1) . "\t" . $current_fee_percent . "%\t" . round($new_fees, 1) . "\t" . round($new_fee_per_staker, 1) . "\t" . round($new_reward_per_staker, 1) . "\t" . $new_fee_percent . '%' . PHP_EOL; $i++; } echo PHP_EOL; ================================================ FILE: CIP-0024/CIP-0024.md ================================================ Moved to [CIP-0024/README.md](./README.md). ================================================ FILE: CIP-0024/README.md ================================================ --- CIP: 24 Title: Non-Centralizing Rankings Authors: - Shawn McMurdo Category: Wallets Status: Proposed Discussions: - https://forum.cardano.org/t/how-to-improve-daedalus-rankings/40478 - https://github.com/cardano-foundation/CIPs/pull/21 Implementors: [] Created: 2020-09-15 License: CC-BY-4.0 --- ## Abstract Modify the current Daedalus ranking system by removing the centralizing Nash Equilibrium goal of the ranking methodology in order to give more fair rankings and improve the viability of the stake pool operator community and the network overall. To do this we need to remove the stated goal of having k fully saturated pools and all other pools having no stake other than owner pledge, which goes against the Cardano goal of decentralization. ## Motivation: why is this CIP necessary? There are two main reasons for changing the current ranking methodology: 1. Allow for more than k successful stake pools. 2. Provide better decentralization away from a very few stake pool operators creating many pools. ## Specification This is a modification of the ranking methodology defined in section 5.6 Non-Myopic Utility of “Shelley Ledger: Delegation/Incentives Design Spec. (SL-D1 v.1.20, 2020/07/06)” as follows: 1. Remove the following statement from section 5.6: "The idea is to first rank all pools by “desirability”, to then assume that the k most desirable pools will eventually be saturated, whereas all other pools will lose all their members, then to finally base all reward calculations on these assumptions." 2. Remove the following statement from section 5.6.1: "We predict that pools with rank ≤ k will eventually be saturated, whereas pools with rank > k will lose all members and only consist of the owner(s)." 3. Add the following to section 5.6.1: For all pools with proposed_pool_stake greater than saturation_warning_stake add k to their rank. Where: proposed_pool_stake = pool_live_stake + proposed_user_stake saturation_warning_stake = (total_stake / k) * saturation_warning_level saturation_warning_level is a real number greater than 0 representing the percent of saturation which is undesirable. A proposed value for saturation_warning_level is 0.95 meaning 95% saturated. For example, if a pool has non-myopic desirability rank of 3, pool_live_stake of 207m ADA, proposed_user_stake of 100k ADA with total_stake of 31.7b ADA, k = 150 and saturation_warning_level = 0.95, we would calculate: 207m + 100k > (31.7b / 150) * 0.95 and see that 207.1m > 200.8m is true so we would change the pool rank to 153 (3 + k) and all pools previously ranked 4 through 153 would move up 1 rank. 4. Remove secion 5.6.2. 5. Remove section 5.6.3. 6. Remove section 5.6.4. 7. Add to secion 5.6.5. For example, apparent performance, desirability and ranking can be made non-myopic for ranking purposes as follows: dnm[n] := average(d[1]...d[n],and[n + 1]...and[i]) if n < i average(d[1]...d[n]) if n = i (dnm[n - 1] * h) + (d[n] * (1 - h)) otherwise. where: n = epoch number beginning at n = 1 in the first epoch that the pool is eligible for potential rewards. dnm[n] = the non-myopic desirability of the pool in the nth epoch. d[n] = the desirability in the nth epoch unaware of historical desirability. and[n] = the average desirability of the network as a whole in the nth epoch unaware of historical desirability. h = historical influence factor, which is any real number between 0 and 1 exlusive. i = integer(1 / h) which is the initial number of epochs during which we use the average desirability As an example, setting h to 0.1 would mean that the initial number of epochs for using the averaging functions (i) would be 10. If a pool has been eligible to receive rewards (n) for 3 epochs then we use the average of the pool's desirability for those 3 epochs and the overall network desirability for the prior 7 epochs. After the 10th epoch we would use 90% of the previous epoch's non-myopic historical desirability and 10% of the current epoch's desirability to arrive at the new non-myopic desirability. This gives a more reasonable ranking for newer pools that do not have enough historical data to provide fair rankings. ## Rationale: how does this CIP achieve its goals? Using this non-centralizing ranking methodology gives a more fair ranking of stake pools based on performance, pledge and saturation which will encourage delegators to choose better pools. It will also bring the rankings more in line with the general Cardano principle of increasing decentralization. ## Path to Active ### Acceptance Criteria - [ ] One or more wallet software implements this new ranking approach. ### Implementation Plan - [ ] Author has offered to produce an implementation of this change as a cardano-wallet / Daedalus pull request if shown where the current desirability equation is implemented in the code. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0025/CIP-0025.md ================================================ Moved to [CIP-0025/README.md](./README.md). ================================================ FILE: CIP-0025/README.md ================================================ --- CIP: 25 Title: Media Token Metadata Standard Status: Active Category: Tokens Authors: - Alessandro Konrad - Smaug Implementors: N/A Discussions: - https://forum.cardano.org/t/cip-nft-metadata-standard/45687 - https://www.reddit.com/r/CardanoDevelopers/comments/mkhlv8/nft_metadata_standard/ - https://github.com/cardano-foundation/CIPs/pull/85 - https://github.com/cardano-foundation/CIPs/pull/267 - https://github.com/cardano-foundation/CIPs/pull/341 - https://github.com/cardano-foundation/CIPs/pull/527 - https://github.com/cardano-foundation/CIPs/pull/593 Created: 2021-04-08 License: CC-BY-4.0 --- ## Abstract This proposal defines an Media Token Metadata Standard for Native Tokens. ## Motivation: why is this CIP necessary? Tokens on Cardano are a part of the ledger. Unlike on Ethereum, where metadata can be attached to a token through a smart contract, this isn't possible on Cardano because tokens are native and Cardano uses a UTxO ledger, which makes it hard to directly attach metadata to a token. So the link to the metadata needs to be established differently. Cardano has the ability to send metadata in a transaction, allowing the creation of a link between a token and the metadata. To make the link unique, the metadata should be appended to the same transaction, where the token forge happens: > Given a token in a EUTXOma ledger, we can ask “where did this token come from?” Since tokens > are always created in specific forging operations, we can always trace them back through their > transaction graph to their origin. —Section 4 in the paper [UTXOma:UTXO with Multi-Asset Support](https://iohk.io/en/research/library/papers/utxomautxo-with-multi-asset-support/) That being said, we have unique metadata link to a token and can always prove that with 100% certainty. No one else can manipulate the link except if the policy allows it to ([update mechanism](#update-metadata-link-for-a-specific-token)). ## Specification This is the registered `transaction_metadatum_label` value | transaction_metadatum_label | description | | --------------------------- | ------------ | | 721 | Token Metadata | ### General structure The structure allows for multiple token mints, also with different policies, in a single transaction. ``` { "721": { "": { "": { "name": , "image": , "mediaType": image/, "description": , "files": [{ "name": , "mediaType": , "src": , }], } }, "version": } } ``` ### CDDL [Version 1](./cddl/version_1.cddl)\ [Version 2](./cddl/version_2.cddl) - In version `1` the **`asset_name`** must be `utf-8` encoded and in text format for the key in the metadata map. In version `2` the the raw bytes of the **`asset_name`** are used. - In version `1` the **`policy_id`** must be in text format for the key in the metadata map. In version `2` the the raw bytes of the **`policy_id`** are used. - The **`name`** property is marked as required. - The **`image`** property is required and must be a valid [Uniform Resource Identifier (URI)](https://www.rfc-editor.org/rfc/rfc3986) pointing to a resource with mime type `image/*`. Note that this resource is used as thumbnail or the actual link if the token is an image (ideally <= 1MB). If the string representing the resource location is >64 characters, an array may be used in place of a simple JSON string type, which viewers will automatically concatenate to create a single URI. - Please note that if distributed storage systems like IPFS or Arweave are used it is required to use a URI containing the respective scheme (e.g., `ipfs://` or `ar://`) and not merely the content identifier (CID) as token viewers may not be able to locate the file. - Valid identifiers would include: - `"https://cardano.org/favicon-32x32.png"` - `"ipfs://QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"` - `["ipfs://", "QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"]` - Invalid identifiers would include: - `"cardano.org/favicon-32x32.png"` - `"QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"` - `["Qm", "bQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"]` - If an inline base64-encoded image will be used, the data must be prepended with a valid `data:;base64` prefix as specified by the [data URL scheme standard](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs) to indicate the image is an inline data object - See [the OpenSea "IPFS and Arweave URIs" section in their reference guide](https://docs.opensea.io/docs/metadata-standards#ipfs-and-arweave-uris) for more helpful information on the topic. - The **`description`** property is optional. - The **`mediaType`** and **`files`** properties are optional.
**`mediaType`** is however required inside **`files`**. The **`src`** property inside **`files`** is an URI pointing to a resource of this mime type. If the mime type is `image/*`, **`mediaType`** points to the same image, like the on in the **`image`** property, but in an higher resolution. - The **`version`** property is also optional. If not specified the version is `1`. It will become mandatory in future versions if needed. - This structure really just defines the basis. New properties and standards can be defined later on for varies uses cases. That's why there is an "other properties" tag. - The retrieval of the metadata should be the same for all however. Optional fields allow to save space in the blockchain. Consequently the minimal structure for a single token is: #### Version 1 ``` { "721": { "": { "": { "name": , "image": } } } } ``` #### Version 2 ``` { "721": { "": { "": { "name": , "image": } }, "version": 2 } } ``` ### References - Mime types: [RFC6838: Media Type Specifications and Registration Procedures](https://tools.ietf.org/html/rfc6838) - CIP about reserved labels: [CIP-0010: Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010) - [EIP-721](https://eips.ethereum.org/EIPS/eip-721) - URI/URL standards: [RFC3986](https://tools.ietf.org/html/rfc3986), [RFC2397](https://tools.ietf.org/html/rfc2397) ## Rationale: how does this CIP achieve its goals? ### Retrieve valid metadata for a specific token As mentioned above this metadata structure allows to have either one token or multiple tokens with also different policies in a single mint transaction. A third party tool can then fetch the token metadata seamlessly. It doesn't matter if the metadata includes just one token or multiple. The procedure for the third party is always the same: 1. Find the latest mint transaction with the label 721 in the metadata of the specific token that mints a positive amount of the token 2. Lookup the 721 key 3. Lookup the Policy Id of the token 4. Lookup the Asset name of the token 5. You end up with the correct metadata for the token ### Update metadata link for a specific token Using the latest mint transaction with the label 721 as valid metadata for a token allows to update the metadata link of this token. As soon as a new mint transaction is occurring including metadata with the label 721 and a positive amount of the token, the metadata link is considered updated and the new metadata should be used. This is only possible if the policy allows to mint or burn the same token again. Since modern token policies or ledger rules should generally make burning of tokens permissionless, the metadata update is restricted to minting (as in positive amounts) transaction and excludes burning transactions explicitly. ### Backward Compatibility To keep token metadata compatible with changes coming up in the future, we use the **`version`** property. A future version will introduce [schema.org](https://schema.org). ## Path to Active ### Acceptance Criteria - [x] Support of this NFT definition in a commercially significant number and variety of NFT-related services and wallets. - [x] Evolution of this document and standard beyond its early adoption and use cases (up through the point when alternative NFT standards have emerged). ### Implementation Plan - [x] Promulgation of this standard among NFT creators, minting services, token analytic / query services, and wallets. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0025/cddl/version_1.cddl ================================================ string = text .size (0..64) policy_id = string asset_name = string ; utf-8 files_details = { name : string, mediaType : string, src : string / [* string] } metadata_details = { name : string, image : string / [* string], ? mediaType : string, ? description : string / [* string], ? files : [* files_details] } label_metadata = { * policy_id => { * asset_name => metadata_details } } metadata = { 721 : uint => label_metadata } ================================================ FILE: CIP-0025/cddl/version_2.cddl ================================================ string = text .size (0..64) policy_id = bytes ; no longer in text asset_name = bytes ; no longer in text and utf-8 files_details = { name : string, mediaType : string, src : string / [* string] } metadata_details = { name : string, image : string / [* string], ? mediaType : string, ? description : string / [* string], ? files : [* files_details] } label_metadata = { * policy_id => { * asset_name => metadata_details }, version: 2 } ; version 2 metadata = { 721 : uint => label_metadata } ================================================ FILE: CIP-0026/README.md ================================================ --- CIP: 26 Title: Cardano Off-Chain Metadata Status: Active Category: Metadata Authors: - Matthias Benkort - Michael Peyton Jones - Polina Vinogradova Implementors: - cardano-token-registry Discussions: - https://github.com/cardano-foundation/CIPs/pull/112 Created: 2021-08-10 License: CC-BY-4.0 --- ## Abstract We introduce a standard for off-chain metadata that can map opaque on-chain identifiers to metadata suitable for human consumption. This will support user-interface components, and allow resolving trust issues in a moderately decentralized way. ## Motivation: why is this CIP necessary? On the blockchain, we tend to refer to things by hashes or other opaque identifiers. But these are not very human friendly: * In the case of hashes, we often want to know the preimage of the hash, such as * The script corresponding to an output locked by a script hash * The public key corresponding to a public key hash * We want other metadata as appropriate, such as * A human-friendly name * The name of the creator, their website, an icon, etc. etc. * We would like such metadata to be integrated into the UI of our applications * For example, if I’ve accepted a particular name for a currency, I’d like to see that name everywhere in the UI instead of the hash * We want the security model of such metadata to be sound * For example, we don’t want users to be phished by misleading metadata We think there is a case for a metadata distribution system that would fill these needs in a consistent fashion. This would be very useful for Plutus, multi-asset support, and perhaps even some of the existing Cardano infrastructure. Moreover, since much of the metadata which we want to store is not determined by the blockchain, we propose a system that is independent of the blockchain, and relies on non-blockchain trust mechanisms. The Rationale section provides additional justifications for the design decisions in this document. ### Use Cases #### Hashed Content Many pieces of information on the Cardano blockchain are stored as hashes, and only revealed at later stages when required for validation. This is the case for example of scripts (Plutus or phase-1), datums, and public keys. It is likely that (some) users will want to know the preimages of those hashes in a somewhat reliable way and, before they are revealed on-chain. #### Off-Chain Metadata Unlike some (un)popular opinions suggest, a blockchain is a poor choice for a content database. Blockchains are intrinsically ledgers and they are good at recording events or hashes. Yet, there are several elements for which hashes aren't providing a great user experience and to which we would rather attach some human-readable metadata (like names, websites, contact details etc...). This is the case for stake pool for instance for which [SMASH](https://github.com/input-output-hk/smash/) already provides a solution. This is also the case for monetary policies and scripts. In both cases, having the ability to attach extra metadata to _some_ hash with a way to ensure the authenticity of the data is useful. ## Specification This specification covers some parts of a bigger system likely involving multiple components. What part is being implemented and by who is considered out of the scope of this specification. We however envision a setup in which users have access to a client application (a.k.a the wallet), which itself is able to connect to some remote server. We assume the server to also offer a user-interface (either via a graphical user-interface or a application programming interface) for accepting content. > **Note** The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). ### Hash Function There are several places in this document where we need an arbitrary hash function. We will henceforth refer to this simply as “hash”. The hash function MUST be **Blake2b-256** (unless explicitly said otherwise). The hash of a string is the hash of the bytes of the string according to its encoding. ### Metadata Structure Metadata consists of a mandatory _metadata subject_, and a number of _metadata properties_ which describes that subject. Each property consists of a mapping from _property names_ to _property values_, _sequence numbers_ and _signatures_. Metadata subjects, property names, and property values must all be represented as UTF-8 encoded strings. In addition, property values must parse as valid JSON. There is no particular interpretation attached to a metadata subject: it can be anything (see however the special-case of phase-1 monetary policy below). We anticipate however that the primary use-case for it will be something that appears on the blockchain, like the hash of a script. We will refer to a whole metadata as a _metadata object_ and to a particular property assignment for a particular metadata subject as a _metadata entry_. We will say that a metadata object is _well-formed_ when it validates according to the [JSON-schema specification given in annex][schema.json]. To be valid, a metadata object MUST be (at least) well-formed. ```json { "subject": "a5408d0db0d942fd80374", "contact": { "value": "Cid Kramer", "sequenceNumber": 0, "signatures": [ { "signature": "79a4601", "publicKey": "bc77d04" } ] } } ``` #### Sequence Numbers Metadata entries MUST have a `sequenceNumber` associated with them. This is a monotonically increasing integer which is used to ensure that clients and servers do not revert to “earlier” versions of an entry. Upon receiving new metadata objects, servers SHOULD verify the sequence number for each entry already known for that subject and reject submissions with a lower sequence number. #### Attestation Signatures Metadata entries MAY have attestations `signatures` associated with them, in the form of an array of objects. Attestation signatures are indeed annotated. An annotated signature for a message is an object with of a `publicKey`, and a `signature` of a specified message (see below) by the corresponding private key. > ░ note ░ > > When we say “signature” in the rest of this document we mean “annotated signature”. An attestation signature for an entry is a signature of the entry message: ```js hash( hash(CBOR(subject)) + hash(CBOR(name)) + hash(CBOR(value)) + hash(CBOR(sequenceNumber)) ) ``` where `+` designates the concatenation of two bytestrings and `CBOR` designates a function which encodes its input into binary according to [RFC-8949](https://www.rfc-editor.org/rfc/rfc8949). That is, JSON strings are encoded as major type 3, JSON integers as major types 0 or 1, JSON floats as major type 7, JSON arrays as major type 4, JSON objects as major type 5, JSON booleans as major type 7 and JSON null as major type 7; according to the specification. For example, the attestation message for the example entry above is: ```js hash( hash(0x75613534303864306462306439343266643830333734) + // text "a5408d0db0d942fd80374" hash(0x67636F6E74616374) + // text "contact" hash(0x6A436964204B72616D6572) + // text "Cid Kramer" hash(0x00) // uint 0 ) // cd731afcc904c521e0c6b3cc0b560b8157ee29c3e41cd15f8dc8984edf600029 ``` The `publicKey` and the `signature` MUST be base16-encoded and stored as JSON strings. All signatures must be verifiable through the **Ed25519 digital signature** scheme and public keys must therefore be 32-byte long Ed25519 public keys. ### Well-known Properties The following properties are considered well-known, and the JSON in their values MUST have the given structure and semantic interpretation. New properties can be added to this list by amending this CIP. The role of well-known properties is to facilitate integration between applications implementing this CIP. Nevertheless, registries are encouraged to **not** restrict properties to only this limited set but, registries (or metadata servers) MUST verify the well-formedness of those properties when present in a metadata object.

preimage ```json { "type": "object", "description": "A hashing algorithm identifier and a base16-enocoded bytestring, such that the bytestring is the preimage of the metadata subject under that hash function.", "requiredProperties": [ "alg", "msg" ], "properties": { "alg": { "type": "string", "description": "A hashing algorithm identifier. The length of the digest is given by the subject.", "enum": [ "sha1", "sha", "sha3", "blake2b", "blake2s", "keccak", "md5" ] }, "msg": { "type": "string", "description": "The actual preimage.", "encoding": "base16" } } } ```
name ```json { "type": "string", "description": "A human-readable name for the metadata subject, suitable for use in an interface or in running text.", "maxLength": 50, "minLength": 1 } ```
description ```json { "type": "string", "description": "A longer description of the metadata subject, suitable for use when inspecting the metadata subject itself.", "maxLength": 500 } ```
ticker ```json { "type": "string", "description": "A short identifier for the metadata subject, suitable to show in listings or tiles.", "maxLength": 9, "minLength": 2 } ```
decimals ```json { "type": "integer", "description": "When the metadata subject refers to a monetary policy, refers to the number of decimals of the currency.", "minimum": 0, "maximum": 19 }, ```
url ```json { "type": "string", "description": "A universal resource identifier pointing to additional information about the metadata subject.", "format": "uri", "maxLength": 250 } ```
logo ```json { "type": "string", "description": "An `image/png` object which is 64KB in size at most.", "encoding": "base64", "maxLength": 87400 } ```
### Verifying Metadata #### General Case Applications that want to display token metadata MUST verify signatures of metadata entries against a set of trusted keys for certain subjects. We will call such applications _"clients"_. Conceptually we expect clients to maintain a mapping of many subjects to many verification keys. In case where a metadata entry contains no signatures, when none of the provided signatures was produced by a known key for the corresponding subject or when none of the provided signatures verifies: the metadata entry MUST be considered invalid and not be presented to end-users. Note that: - In this scenario, a single valid signature is sufficient to consider a metadata entry valid but there can be many signatures (invalid or valid). So long as one is valid, the entry is considered verified. - The verification is done per _entry_. That is, a metadata object may contain both verified and unverified entries. Plus, entries under the same subject may be verified by different keys. The way by which the trusted keys are registered into clients is unspecified although we already consider the following, **non-overlapping**, **complementary**, options: 1. Clients MAY explicitly prompt the consumer / end-user about whether to accept a certain entry. While this is unpractical for some cases (e.g. token metadata), it may be relevant for some. 1. Clients MAY come with a set of pre-configured well-known trusted keys chosen at the discretion of the application editor. 2. End-users SHOULD have the ability to add/remove keys from their trusted set. This allows end-users to introduce trusted keys they know before they end up in the pre-configured set (which likely follow the application release cycle). In this context, keys are advertised by the signing authority by some means, for instance, on social media or on another form of public key registry (e.g. [keybase.io](http://keybase.io/)) 3. Mappings of subjects to keys MAY be recorded on-chain, using transaction metadata and an appropriate label registered on [CIP-0010]. In some scenarios, the context within which the transaction is signed may be enough to reliably trust the legitimacy of a mapping. For example, in the case of a monetary policy, one could imagine _registering trusted keys_ in the same transaction minting tokens. Because the transaction is inserted in the ledger, it must have been signed by the token issuer and therefore, the specified keys are without doubt acknowledged by the token issuer. As a result, clients having access to on-chain data can automatically discover new mappings from observing the chain. #### Special Case: Phase-1 Monetary Policies > ░ note ░ > > This approach is now considered superseded by the more general approach. While it has some nice properties, new applications should consider sticking to the general case **even for phase-1 monetary policies**. Servers who seek backward-compatibility should implement both. We consider the case of phase-1 monetary policies introduced during the Allegra era of Cardano. Such policies are identified by a simple (native) script which is validated by the ledger during the so-called phase-1 validations. Such scripts are made of key hashes, combined via a set of basic first-order logic primitives (ALL, ANY-OF, N-OF...) such that, it is possible to statically verify whether a set of signatures would validate the script. These scripts therefore make relatively good verification mechanisms for metadata associated with phase-1 monetary policies. Hence, we introduce the following well-known property:
policy ```json { "type": "string", "description": "A CBOR-serialized phase-1 monetary policy, used as a pre-image to produce a policyId.", "encoding": "base16", "minLength": 56, "maxLength": 120 } ```

Metadata objects that contain an extra top-level property `policy` MUST therefore abide by the following rules: 1. Their subject MUST be an `assetId`, encoded in base16; where the `assetId` is the concatenation of a `policyId` (28 bytes) and an `assetName` (up to 32 bytes). 2. The `policy` MUST therefore re-hash (through blake2b-224) into the first 28 bytes of the metadata's subject (the policy id). 3. Every metadata entry MUST have a set of signatures such that, the monetary script given in policy can be validated using the provided signatures, irrespective of the time constraints. Said differently, the public keys from the annotated signature must re-hash into key hashes present in the policy AND each key must verify its associated signature AND the provided signatures must be sufficient to validate the monetary script according to the semantic given by the cardano ledger without considering the time constraints. For example, consider the following phase-1 monetary policy, represented in JSON: ```json { "type": "all", "scripts": [ { "keyHash": "2B0C33E73D2A70733EDC971D19E2CAFBADA1692DB2D35E7DC9453DF2", "type": "sig" }, { "keyHash": "E2CAFBADA1692DB2D35E7DC9453DF22B0C33E73D2A70733EDC971D19", "type": "sig" } ] } ``` To validate such a policy, each entry would require 2 signatures: - from `2B0C33E73D2A70733EDC971D19E2CAFBADA1692DB2D35E7DC9453DF2` - and from `E2CAFBADA1692DB2D35E7DC9453DF22B0C33E73D2A70733EDC971D19` The policy MAY also contain some additional time constraints (VALID-AFTER, VALID-BEFORE) specifying a certain slot number. For the sake of verifying policies, these should be ignored and consider _valid_. ### Recommendations For Metadata Servers The following section gives some recommendations to application developers willing to implement a metadata server / registry. Following these recommendations will facilitate interoperability between applications and also, provide some good security foundation for the server. In this context, what we refer to as a _metadata server_ is a web server that exposes the functionality of a simple key-value store, where the keys are metadata subjects and property names, and the values are their property values. ##### Querying Metadata The metadata server SHOULD implement the following HTTP methods: ``` GET /metadata/{subject}/property/{property name} ``` This SHOULD return the property values for the given property name (if any) associated with the subject. This is returned as a array of JSON objects whose key is the property name and return the complete JSON entries for that subject+name (including `value`, `sequenceNumber` and `signatures`). The metadata server SHOULD set the Content-Length header to allow clients to decide if they wish to download sizeable metadata. ``` GET /metadata/{subject}/properties ``` This SHOULD return all the property names which are available for that subject (if any). These are returned as a JSON list of strings. ``` GET /metadata/{subject} ``` This SHOULD return a array of the full metadata objects associated with this subject, including the subject and all properties associated with it. ``` POST /metadata/query REQUEST BODY : a JSON object with the keys: “subjects” : A list of subjects, encoded as strings in the same way as the queries above. “properties” : An optional list of property names, encoded as strings in the same way as the query above. ``` This endpoint provides a way to batch queries, making several requests of the server with only one HTTP request. If only `“subjects”` is supplied, this query SHOULD return a list of subjects with all their properties. The response format will be as similar as possible to the `GET /metadata/{subject}` request, but nested inside a list. If `“subjects”` and `“properties”` are supplied, the query will return a list of subjects, with their properties narrowed down to only those specified by `“properties”`. > ░ suggestion ░ > > Metadata servers MAY provide other methods of querying metadata, such as: > > * Searching for all mappings whose “name” property value is a particular string > * Searching for all metadata items which are signed by a particular cryptographic key, or uploaded by a particular user ##### Modifying metadata The metadata server needs some way to add and modify metadata entries. The method for doing so is largely up to the implementor, but recommend to abide by the following rules: 1. The server MUST only accept updates for metadata entries that have a higher sequence number than the previous entry. 1. The server MUST always verify well-formedness of metadata entries before accepting them. 1. The server MUST always cryptographically verify metadata entries' signatures before accepting them. 1. The server MAY reject entries with no signatures. 1. The server MAY support the POST, PUT, and DELETE verbs to modify metadata entries. ##### Authentication If the server supports modifications to metadata entries, it SHOULD provide some form of authentication which controls who can modify them. Servers MUST NOT use the attestation signatures on metadata entries as part of authentication (with the exception of phase-1 monetary policy). Attestation signatures are per-entry, and are orthogonal to determining who controls the metadata for a subject. Simple systems may want to use little more than cryptographic signatures, but more sophisticated systems could have registered user accounts and control access in that way. ##### Audit The metadata server MAY provide a mechanism auditing changes to metadata, for example by storing the update history of an entry and allowing users to query it (via the API or otherwise). #### Hardening Allowing unrestricted updates to non-verifiable metadata would allow malicious users to “squat” or take over another user’s metadata subjects. This is why we recommend that server implementations have some kind of authentication system to mitigate this. One approach is to have a system of “ownership” of metadata subjects. This notion of ownership is vague, although in some cases there are obvious choices (e.g. for a multisig minting policy, the obvious owners are the signatories who can authorize minting). It is up to the server to pick a policy for how to decide on owners, and enforce security; or indeed to take a different approach entirely. See the earlier “Authentication” section for a description of a possible approach to managing ownership. Depending on the authentication mechanism they use, servers may also need to worry about replay attacks, where an attacker submits a (correctly signed) old record to “revert” a legitimate change. However, these can be unconditionally prevented by correctly implementing sequence numbers as described earlier, which prevents old entries from being accepted. ### Recommendations For Metadata Clients Similar to the recommendations for metadata servers, this section gives some recommendations to application developers willing to implement a metadata client. Following these recommendations will facilitate interoperability between applications and also, provide some good security foundation for the clients. A metadata client refers to the component that communicates with a metadata server and maintains the user’s trusted metadata mapping. This may be implemented as part of a larger system, or may be an independent component (which could be shared between multiple other systems, e.g. a wallet frontend and a blockchain explorer). - The metadata client MUST allow the metadata server (or servers) that it references to be configured by the end-user. - The metadata client MUST maintain a local mapping of trusted keys and metadata entries. - The metadata client MUST only accept updates with a higher sequence number than the entry it currently has. - The metadata client MUST always verify well-formedness or metadata entries before accepting them. - The metadata client MUST always verify any signatures on metadata entries before accepting them. - The metadata client SHOULD allow browsing of its trusted keys. - The metadata client SHOULD allow modifications of its trusted keys by the end-user. - The metadata client SHOULD use a Trust On First Use (TOFU) strategy for updating this store. When an update is requested for a metadata entry, the client should query the server, but not trust the resulting metadata entry unless the user agrees to use it (either by explicit consent, or implicitly via the set of trusted keys). If the entry is trusted, it should be copied to the local store. - The metadata client MAY be configurable to limit the amount downloaded. - The metadata client MAY accept user updates for metadata entries. ## Rationale: how does this CIP achieve its goals? ### Interfaces and progressive enhancement The design space for a metadata server is quite large. For example, any of the following examples could work, or other combinations of these features: - A single centralized server maintained by the Cardano Foundation, and updated by emailing the administrator (no user-facing front end website) - An open-source federation of servers with key-based authentication. - A commercial server with an account-based system, a web-frontend, and a payments system for storage. This design aims to be agnostic about the details of the implementation, by specifying only a very simple interface between the client, server, and system-component users (wallet, etc.). This allows: - Progressive enhancement of servers over time. Initially servers may provide a very bare-bones implementation, but this can be improved later. - Competition between multiple implementations, including from third parties. ### Decentralization For much of the metadata we are concerned with there is no “right” answer. The metadata server is thus playing a key trusted role - even if that trust is partial because users can rely on attestation signatures. We therefore believe that it is critical that we allow users to choose which metadata server (or servers) they refer to. An analogy is with DNS nameservers: these are a trusted piece of infrastructure for any particular user, but users have a choice of which nameservers to use, and can use multiple. This also makes it possible for these servers to be a true piece of community infrastructure, rather than something wedded to a major player (although we hope that the Cardano Foundation and IOHK will produce a competitive offering). ### Verifiable vs non-verifiable metadata A key distinction is between metadata that is verifiably correct and that which is non-verifiable. The key example of verifiable metadata is hashe pre-images. Where the metadata subject is a hash, the preimage of that hash is verifiable metadata, since we can simply hash it and check that it matches. This covers several cases that we are interested in: - Mapping script hashes to the script - Mapping public key hashes to the public key However, most metadata is non-verifiable: - Human-readable names for scripts are not verifiable: there is no “right” answer to what the name of a script is. - Many scripts do not have an obvious “owner” (certainly this is true for Plutus scripts), but even for those which do (e.g. phase-1 monetary scripts) this does not mean that the owner is trusted! See the “Security” section below for more discussion on trust. - Any associations with authors, websites, icons, etc are similarly non-verifiable as there is no basis for establishing trust. ### Security Most of the security considerations relate to non-verifiable metadata. Verifiable metadata can generally always be accepted as is (provided that it is verified). Our threat model is that non-verifiable metadata may always have been provided by an attacker. Accepting non-verifiable metadata blindly can lead to attacks. For example, a malicious server or user might attempt to name their currency “Ada”. If we blindly accept this and overwrite the existing mapping for “Ada”, this would lead to easy phishing attacks. The approach we take is heavily inspired by petname systems, GPG keyservers, and local address books. The user always has a local mapping which is trusted, and then adding to or updating that mapping requires explicit user consent, unless we can prove that this is trustworthy (i.e. the metadata is verifiable). How can users decide whether to trust an update? This is where the attestation signatures come into play. If a user trusts the entity which signs the metadata record, that may be sufficient for them to accept it as a legitimate update. Clients could also be tricked into downloading large amounts of metadata that the user does not want. For this reason clients should expose some kind of configurable download limiting, and we suggest that the server set the Content-Length header to support this. However, this problem is no worse than that faced by the average web browser, so we do not think it will be a problem in practice. Clients also need to worry about replay attacks, where they are sent old (correctly signed) records in an attempt to “roll back” a legitimate update. The easiest way to avoid this is to correctly implement sequence numbers, in which case old updates will be rejected. ### Data storage location This design needs to store a fair amount of data in a shared location. We might wonder whether we should use the blockchain for this: we could store metadata updates in transaction metadata. However, storing this information on-chain does not actually help us: - The trust model for metadata is different than that of the ledger and transactions. The only trust we have (and can expect to have) in the metadata is that it is signed by a particular key, regardless of the purpose or nature of the data. E.g. when posting a script, there is no explicit association between the script and the signing key other than the owner of the key choosing to post it - The metadata is precisely that: metadata. While it is about the chain, it does not directly affect ledger state transitions and therefore we should not require it to be associated with a specific transaction. Besides, on-chain storage comes with considerable downsides: - Higher cost to users for modifications and storage - Increases in the UTXO size - Awkwardness of querying the data - Size limits on transaction metadata For this reason, we think that a traditional database is a much better fit. However, it would be perfectly possible for someone to produce an implementation that was backed by the chain if they believed that that could be competitive. ### Storage cost Metadata may potentially be sizable. For example, preimages of hashes can in principle be any size! Servers will want some way to manage this to avoid abuse. However, this is a typical problem faced by web services and can be solved in the usual ways: size limits per account, charging for storage, etc. ### Backwards compatibility See [Special Case: Phase-1 Monetary Policies](#special-case--phase--1-monetary-policies) which covers existing implementations. ## Path to Active ### Acceptance Criteria - [x] Document commercial or community implementations of any of the use cases described above. - [cardano-token-registry](https://github.com/cardano-foundation/cardano-token-registry) ### Implementation Plan - [x] Provide a reference implementation: [Off-chain metadata tools](https://github.com/input-output-hk/offchain-metadata-tools) ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [schema.json]: https://raw.githubusercontent.com/cardano-foundation/CIPs/master/CIP-0026/schema.json [CIP-0010]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010 ================================================ FILE: CIP-0026/schema.json ================================================ { "title": "Cardano Off-Chain Metadata" , "$schema": "https://json-schema.org/draft-07/schema" , "required": [ "subject" ] , "additionalProperties": { "$ref": "#/definitions/entry" } , "properties": { "subject": { "type": "string" , "description": "The subject, a namespace for multiple metadata entries, typically a hash digest." , "minLength": 1 , "maxLength": 255 } , "policy": { "type": "string" , "description": "A CBOR-serialized phase-1 monetary policy, used as a pre-image to produce a policyId." , "encoding": "base16" , "minLength": 56 , "maxLength": 120 } , "preimage": { "type": "object" , "description": "A hashing algorithm identifier and a base16-enocoded bytestring, such that the bytestring is the preimage of the metadata subject under that hash function." , "requiredProperties": [ "alg", "msg" ] , "properties": { "alg": { "type": "string" , "description": "A hashing algorithm identifier. The length of the digest is given by the subject." , "enum": [ "sha1", "sha", "sha3", "blake2b", "blake2s", "keccak", "md5" ] } , "msg": { "type": "string" , "description": "The actual preimage." , "encoding": "base16" } } } , "name": { "type": "string" , "description": "A human-readable name for the metadata subject, suitable for use in an interface or in running text." , "maxLength": 50 , "minLength": 1 } , "description": { "type": "string" , "description": "A longer description of the metadata subject, suitable for use when inspecting the metadata subject itself." , "maxLength": 500 } , "ticker": { "type": "string" , "description": "A short identifier for the metadata subject, suitable to show in listings or tiles." , "maxLength": 9 , "minLength": 2 } , "decimals": { "type": "integer" , "description": "When the metadata subject refers to a monetary policy, refers to the number of decimals of the currency." , "minimum": 1 , "maximum": 19 } , "url": { "type": "string" , "description": "A universal resource identifier pointing to additional information about the metadata subject." , "format": "uri" , "maxLength": 250 } , "logo": { "type": "string" , "description": "A `image/png` object which is 64KB in size at most." , "encoding": "base64" , "maxLength": 87400 } } , "definitions": { "entry": { "type": "object" , "additionalProperties": false , "required": [ "value" , "sequenceNumber" , "signatures" ] , "properties": { "value": {} , "sequenceNumber": { "$ref": "#/definitions/sequenceNumber" } , "signatures": { "$ref": "#/definitions/signatures" } } } , "sequenceNumber": { "type": "integer" , "minimum": 0 } , "signatures": { "type": "array" , "items": { "type": "object" , "additionalProperties": false , "required": [ "publicKey" , "signature" ] , "properties": { "publicKey": { "type": "string" , "description": "An Ed25519 Public key, verifying the companion signature." , "encoding": "base16" , "minLength": 64 , "maxLength": 64 } , "signature": { "type": "string" , "description": "A signed attestation." , "encoding": "base16" , "minLength": 128 , "maxLength": 128 } } } } } } ================================================ FILE: CIP-0027/CIP-0027.md ================================================ Moved to [CIP-0027/README.md](./README.md). ================================================ FILE: CIP-0027/README.md ================================================ --- CIP: 27 Title: CNFT Community Royalties Standard Status: Active Category: Tokens Authors: - Huth S0lo - TheRealAdamDean Implementors: N/A Discussions: - https://forum.cardano.org/t/cip-royalties/68599 - https://github.com/cardano-foundation/CIPs/pull/116 Created: 2021-08-29 License: Apache-2.0 --- ## Abstract This proposed standard will allow for uniform royalties' distributions across the secondary market space. It is easy to implement using metadata only, and does not require a smart contract. However, it is scalable to allow for the usage of a downstream smart contract, as needed by the asset creator. ## Motivation: why is this CIP necessary? There is a significant interest within the Cardano Community for an implementation of royalties distribution when a Cardano Asset is resold on the secondary market. It has become a common theme to see and hear statements that the only thing stopping artists from adopting Cardano, is that they are waiting for an implementation of royalties. At the present time, smart contracts do not create a simple mechanism to implement royalties. By developing a community standard, we can resolve the immediate need for royalties, and create a path forward for a potential future iteration of smart contracts. ## Specification A new tag of 777 is proposed for this implementation. The community guidelines have been agreed as follows: 1) A brand new unused policy for implementation is required. 2) The royalties tags are to be written to an unnamed token, using the policy to be used for the intended Cardano Assets. 3) Only the first minted set of instructions will be honored. Any future updates or rewrites will be ignored. This prevents a Cardano Asset maker from changing the royalties at a future date. 4) Within this created asset will be the metadata for royalties distributions. It will use a tag of 777, and then have two tags to identify the percentage of future sales requested as a royalty, and the payment address to forward those royalties to. Those tags will be "rate" and "addr" respectively. 5) The "rate" key tag can be any floating point value from 0.0 to 1.0, to represent between 0 and 100 percent. For example, a 12.5 percent royalty would be represented with "rate": "0.125". Previous version 1.0 of this proposal used pct instead of rate. Marketplaces to continue to honor legacy pct tag. 6) The "addr" key tag can be a string value, or an array. It is to include a single payment address. By allowing for an array, the payment address can exceed the per line 64 character limitation. This payment address could be part of a smart contract, which should allow for greater flexibility of royalties distributions, controlled by the asset creator. 7) The royalty token must be minted prior to creating any assets off the policy. All markets will be instructed to look only for the first minted asset on a policy, which would need to be the unnamed 777 token. ### Example JSON with string { "777": { "rate": "0.2", "addr": "addr1v9nevxg9wunfck0gt7hpxuy0elnqygglme3u6l3nn5q5gnq5dc9un" } } ### Example JSON with array { "777": { "rate": "0.2", "addr": [ "addr1q8g3dv6ptkgsafh7k5muggrvfde2szzmc2mqkcxpxn7c63l9znc9e3xa82h", "pf39scc37tcu9ggy0l89gy2f9r2lf7husfvu8wh" ] } } ### Process Flow 1) Create policy for planned assets. 2) Mint no name token with community standard royalties metadata. 3) Burn no name token to free up UTxO (recommended, but not required). 4) Mint planned assets using this same policy. ## Rationale: how does this CIP achieve its goals? By creating a new tag for the distinct purpose of royalties distributions, Cardano Asset makers, and Marketplaces can uniformly apply royalties to assets with predictable results. By creating the instructions on a single, no name token, all marketplaces will know the correct location of the royalties asset, without having to further locate it. By enforcing the requirement of honoring only the first mint, cardano asset buyers and owners can predict the future resale value of the assets in their possession. The solution is scalable to any desired royalty percentage. It is easy to work with this new standard, and does not require an in depth understanding of smart contracts. ## Path to Active ### Acceptance Criteria - [x] Support of royalty distribution according to this standard by multiple significant NFT related platforms. - [x] Implementation in libraries supporting NFT minting, including: - [x] Mesh ([Minting Royalty Token](https://meshjs.dev/apis/transaction/minting#mintingRoyaltyToken)) ### Implementation Plan - [x] Incorporate input from many Cardano NFT related entities, including: - [x] Artano - [x] BuffyBot - [x] CNFT.io - [x] Digital Syndicate - [x] Fencemaker - [x] MADinArt - [x] NFT-Maker.io - [x] Hydrun - [x] Tokhun ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0028/README.md ================================================ --- CIP: 28 Title: Protocol Parameters (Alonzo Era) Status: Active Category: Ledger Authors: - Kevin Hammond Implementors: - IOG Discussions: - https://github.com/cardano-foundation/CIPs/pull/140 Created: 2021-10-14 License: Apache-2.0 --- ## Abstract This CIP extends CIP-0009 to include the new protocol parameters that have been introduced for Alonzo, specifically those relating to the costing of Plutus scripts. It describes the initial settings for those parameters. ## Motivation: why is this CIP necessary? We need to document the chain of changes to the protocol parameters. This document describes precisely the changes that have been made from CIP-0009, allowing the differences to be determined. It thus supplements rather than replaces CIP-0009. ## Specification ### New Updatable Protocol Parameters The new **updatable** protocol parameter values for Alonzo are given below (in JSON format). Any of these parameters may be changed by submitting a parameter update proposal to the chain, and without triggering a "hard fork". Note that these parameters are given using the names used in the genesis file. Be aware that some parameters are shown differently using ``cardano-cli query protocol-parameters`` -- this has been raised as an issue with the development team. ``` { "lovelacePerUTxOWord": 34482, "executionPrices": { "prSteps": { "numerator" : 721, "denominator" : 10000000 }, "prMem": { "numerator" : 577, "denominator" : 10000 } }, "maxTxExUnits": { "exUnitsMem": 10000000, "exUnitsSteps": 10000000000 }, "maxBlockExUnits": { "exUnitsMem": 50000000, "exUnitsSteps": 40000000000 }, "maxValueSize": 5000, "collateralPercentage": 150, "maxCollateralInputs": 3, "costModels": { "PlutusV1": { "sha2_256-memory-arguments": 4, "equalsString-cpu-arguments-constant": 1000, "cekDelayCost-exBudgetMemory": 100, "lessThanEqualsByteString-cpu-arguments-intercept": 103599, "divideInteger-memory-arguments-minimum": 1, "appendByteString-cpu-arguments-slope": 621, "blake2b-cpu-arguments-slope": 29175, "iData-cpu-arguments": 150000, "encodeUtf8-cpu-arguments-slope": 1000, "unBData-cpu-arguments": 150000, "multiplyInteger-cpu-arguments-intercept": 61516, "cekConstCost-exBudgetMemory": 100, "nullList-cpu-arguments": 150000, "equalsString-cpu-arguments-intercept": 150000, "trace-cpu-arguments": 150000, "mkNilData-memory-arguments": 32, "lengthOfByteString-cpu-arguments": 150000, "cekBuiltinCost-exBudgetCPU": 29773, "bData-cpu-arguments": 150000, "subtractInteger-cpu-arguments-slope": 0, "unIData-cpu-arguments": 150000, "consByteString-memory-arguments-intercept": 0, "divideInteger-memory-arguments-slope": 1, "divideInteger-cpu-arguments-model-arguments-slope": 118, "listData-cpu-arguments": 150000, "headList-cpu-arguments": 150000, "chooseData-memory-arguments": 32, "equalsInteger-cpu-arguments-intercept": 136542, "sha3_256-cpu-arguments-slope": 82363, "sliceByteString-cpu-arguments-slope": 5000, "unMapData-cpu-arguments": 150000, "lessThanInteger-cpu-arguments-intercept": 179690, "mkCons-cpu-arguments": 150000, "appendString-memory-arguments-intercept": 0, "modInteger-cpu-arguments-model-arguments-slope": 118, "ifThenElse-cpu-arguments": 1, "mkNilPairData-cpu-arguments": 150000, "lessThanEqualsInteger-cpu-arguments-intercept": 145276, "addInteger-memory-arguments-slope": 1, "chooseList-memory-arguments": 32, "constrData-memory-arguments": 32, "decodeUtf8-cpu-arguments-intercept": 150000, "equalsData-memory-arguments": 1, "subtractInteger-memory-arguments-slope": 1, "appendByteString-memory-arguments-intercept": 0, "lengthOfByteString-memory-arguments": 4, "headList-memory-arguments": 32, "listData-memory-arguments": 32, "consByteString-cpu-arguments-intercept": 150000, "unIData-memory-arguments": 32, "remainderInteger-memory-arguments-minimum": 1, "bData-memory-arguments": 32, "lessThanByteString-cpu-arguments-slope": 248, "encodeUtf8-memory-arguments-intercept": 0, "cekStartupCost-exBudgetCPU": 100, "multiplyInteger-memory-arguments-intercept": 0, "unListData-memory-arguments": 32, "remainderInteger-cpu-arguments-model-arguments-slope": 118, "cekVarCost-exBudgetCPU": 29773, "remainderInteger-memory-arguments-slope": 1, "cekForceCost-exBudgetCPU": 29773, "sha2_256-cpu-arguments-slope": 29175, "equalsInteger-memory-arguments": 1, "indexByteString-memory-arguments": 1, "addInteger-memory-arguments-intercept": 1, "chooseUnit-cpu-arguments": 150000, "sndPair-cpu-arguments": 150000, "cekLamCost-exBudgetCPU": 29773, "fstPair-cpu-arguments": 150000, "quotientInteger-memory-arguments-minimum": 1, "decodeUtf8-cpu-arguments-slope": 1000, "lessThanInteger-memory-arguments": 1, "lessThanEqualsInteger-cpu-arguments-slope": 1366, "fstPair-memory-arguments": 32, "modInteger-memory-arguments-intercept": 0, "unConstrData-cpu-arguments": 150000, "lessThanEqualsInteger-memory-arguments": 1, "chooseUnit-memory-arguments": 32, "sndPair-memory-arguments": 32, "addInteger-cpu-arguments-intercept": 197209, "decodeUtf8-memory-arguments-slope": 8, "equalsData-cpu-arguments-intercept": 150000, "mapData-cpu-arguments": 150000, "mkPairData-cpu-arguments": 150000, "quotientInteger-cpu-arguments-constant": 148000, "consByteString-memory-arguments-slope": 1, "cekVarCost-exBudgetMemory": 100, "indexByteString-cpu-arguments": 150000, "unListData-cpu-arguments": 150000, "equalsInteger-cpu-arguments-slope": 1326, "cekStartupCost-exBudgetMemory": 100, "subtractInteger-cpu-arguments-intercept": 197209, "divideInteger-cpu-arguments-model-arguments-intercept": 425507, "divideInteger-memory-arguments-intercept": 0, "cekForceCost-exBudgetMemory": 100, "blake2b-cpu-arguments-intercept": 2477736, "remainderInteger-cpu-arguments-constant": 148000, "tailList-cpu-arguments": 150000, "encodeUtf8-cpu-arguments-intercept": 150000, "equalsString-cpu-arguments-slope": 1000, "lessThanByteString-memory-arguments": 1, "multiplyInteger-cpu-arguments-slope": 11218, "appendByteString-cpu-arguments-intercept": 396231, "lessThanEqualsByteString-cpu-arguments-slope": 248, "modInteger-memory-arguments-slope": 1, "addInteger-cpu-arguments-slope": 0, "equalsData-cpu-arguments-slope": 10000, "decodeUtf8-memory-arguments-intercept": 0, "chooseList-cpu-arguments": 150000, "constrData-cpu-arguments": 150000, "equalsByteString-memory-arguments": 1, "cekApplyCost-exBudgetCPU": 29773, "quotientInteger-memory-arguments-slope": 1, "verifySignature-cpu-arguments-intercept": 3345831, "unMapData-memory-arguments": 32, "mkCons-memory-arguments": 32, "sliceByteString-memory-arguments-slope": 1, "sha3_256-memory-arguments": 4, "ifThenElse-memory-arguments": 1, "mkNilPairData-memory-arguments": 32, "equalsByteString-cpu-arguments-slope": 247, "appendString-cpu-arguments-intercept": 150000, "quotientInteger-cpu-arguments-model-arguments-slope": 118, "cekApplyCost-exBudgetMemory": 100, "equalsString-memory-arguments": 1, "multiplyInteger-memory-arguments-slope": 1, "cekBuiltinCost-exBudgetMemory": 100, "remainderInteger-memory-arguments-intercept": 0, "sha2_256-cpu-arguments-intercept": 2477736, "remainderInteger-cpu-arguments-model-arguments-intercept": 425507, "lessThanEqualsByteString-memory-arguments": 1, "tailList-memory-arguments": 32, "mkNilData-cpu-arguments": 150000, "chooseData-cpu-arguments": 150000, "unBData-memory-arguments": 32, "blake2b-memory-arguments": 4, "iData-memory-arguments": 32, "nullList-memory-arguments": 32, "cekDelayCost-exBudgetCPU": 29773, "subtractInteger-memory-arguments-intercept": 1, "lessThanByteString-cpu-arguments-intercept": 103599, "consByteString-cpu-arguments-slope": 1000, "appendByteString-memory-arguments-slope": 1, "trace-memory-arguments": 32, "divideInteger-cpu-arguments-constant": 148000, "cekConstCost-exBudgetCPU": 29773, "encodeUtf8-memory-arguments-slope": 8, "quotientInteger-cpu-arguments-model-arguments-intercept": 425507, "mapData-memory-arguments": 32, "appendString-cpu-arguments-slope": 1000, "modInteger-cpu-arguments-constant": 148000, "verifySignature-cpu-arguments-slope": 1, "unConstrData-memory-arguments": 32, "quotientInteger-memory-arguments-intercept": 0, "equalsByteString-cpu-arguments-constant": 150000, "sliceByteString-memory-arguments-intercept": 0, "mkPairData-memory-arguments": 32, "equalsByteString-cpu-arguments-intercept": 112536, "appendString-memory-arguments-slope": 1, "lessThanInteger-cpu-arguments-slope": 497, "modInteger-cpu-arguments-model-arguments-intercept": 425507, "modInteger-memory-arguments-minimum": 1, "sha3_256-cpu-arguments-intercept": 0, "verifySignature-memory-arguments": 1, "cekLamCost-exBudgetMemory": 100, "sliceByteString-cpu-arguments-intercept": 150000 } } } ``` The meaning of the fields is: | Field | Initial Value | Description | |----------------------- |------------------------------------------------------------------------ |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | lovelacePerUTxOWord | 34482 | Deposit charged per word of UTxO storage. | | executionPrices | `{ "prSteps": { "numerator" : 721, "denominator" : 10000000}, "prMem": { "numerator" : 577, "denominator" : 10000 } }` | Fee per Plutus execution step and per memory unit | | maxTxExUnits | `{ "exUnitsMem": 10000000, "exUnitsSteps": 10000000000 }` | Maximum number of memory units and steps in a single transaction. | | maxBlockExUnits | `{ "exUnitsMem": 50000000, "exUnitsSteps": 40000000000 }` | Maximum number of memory units and steps in a single block. | | maxValueSize | 5000 | The limit on the serialized size of the Value in each output. | | collateralPercentage | 150 | Percentage of fee that is used as collateral for a failed transaction. | | maxCollateralInputs | 3 | Maximum number of collateral inputs in a transaction. | | costModels | `{ "PlutusV1": { ... } }` | Detailed cost models for each Plutus version. | Each version of the Plutus interpreter may use different cost model parameters and settings. Although the parameters are updatable, they are likely to be changed only when introducing new Plutus interpreter versions at a "hard fork". For simplicity, the details of the parameter settings is omitted here. ### Obsoleted Updatable Protocol Parameters ``minUTxOValue`` is no longer used. It is replaced by ``lovelacePerUTxOWord``. ### Non-Updatable Parameters There are no changes to the non-updatable protocol parameters. ## Rationale: how does this CIP achieve its goals? The majority of the parameters are needed to enable the use of Plutus scripts on-chain. They relate to the fees calculations for transactions that include Plutus scripts. ``executionPrices`` are specified in fractions of lovelace per Plutus CPU execution step or memory unit. These have been set to be consistent with the cost for a full transaction. ``lovelacePerUTxOWord`` replaces ``minUTxOValue``. Rather than determining a fixed minimum deposit, the new value scales each word that is used. The value is set to give a very similar result for an ada-only UTxO entry (previously, 1,000,000 lovelace; now 999,978 lovelace, since each ada-only UTxO entry is 29 words). ``collateralPercentage``has been chosen to be higher than the transaction fee. Collateral should only be used to pay fees if a user has deliberately submitted a transaction that is known to fail. Setting the percentage high acts to discourage the submission of rogue transactions, which maliciously consume chain resources. ``maxCollateralInputs`` has been set to allow the option of multiple inputs to be used to pay collateral, if needed (e.g. so that multiple instance of a transaction can be submitted without sharing a single collateral, that might restrict concurrency or cause script failure if the collateral was not available). ``maxValueSize`` has been set based on benchmarking. ``costModels`` has been set for ``PlutusV1`` based on benchmarking inputs. Each Plutus Core primitive has associated costs. ## Path to Active ### Acceptance Criteria - [x] The Alonzo ledger era is activated. - [x] Documented parameters have been in operational use by Cardano Node and Ledger as of the Alonzo ledger era. ### Implementation Plan - [x] Alonzo ledger era parameters are deemed correct by working groups at IOG. ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). ================================================ FILE: CIP-0029/CIP-0029.md ================================================ Moved to [CIP-0029/README.md](./README.md). ================================================ FILE: CIP-0029/README.md ================================================ --- CIP: 29 Title: Phase-1 Monetary Scripts Serialization Formats Status: Active Category: Tools Authors: - Matthias Benkort Implementors: - IOG Discussions: - https://github.com/cardano-foundation/CIPs/pull/117 Created: 2020-08-17 License: CC-BY-4.0 --- ## Abstract This specification describes how to serialize Phase-1 monetary scripts (a.k.a. _"native scripts"_) to various formats (JSON, CBOR) to facilitate inter-operability between applications. ## Motivation: why is this CIP necessary? While the existence of scripts is well-known, and have an unambiguous on-chain representation. There's no agreed upon format for off-chain or higher-level interfaces for which a binary string is a poor fit. This CIP regroups both the on-chain binary format and other, more verbose, formats like JSON. ## Specification This specification covers at present two serialization formats: JSON and CBOR. The CBOR matches exactly the on-chain representation and is extracted from the cardano-ledger-specs source code and put here as a convenient place to lookup while the source can change location over time. ### CBOR The CBOR serialization format is given as a [CDDL specification in annexe](./phase-1-monetary-scripts.cddl). When a hash of the phase-1 monetary script is needed, it usually refers to a Blake2b-192 digest of the corresponding serialized script byte-string prefixed with a null byte: `\x00`. ### JSON The JSON format is given as a [JSON schema in annexe](./phase-1-monetary-scripts.json). It is preferred in user interfaces such as command-lines or APIs, where some level of human inspection may be required. ### Notes - Scripts may contain unbounded integers! Implementation parsing them, either from CBOR or JSON shall be prepared to handle possible big integers (>= 2^64). ### Test Vectors ```yaml - json: { "type": "sig" , "keyHash": "00000000000000000000000000000000000000000000000000000000" } cbor: "8200581c00000000000000000000000000000000000000000000000000000000" - json: { "type": "all" , "scripts": [ { "type": "sig" , "keyHash": "00000000000000000000000000000000000000000000000000000000" } , { "type": "any" , "scripts": [ { "type": "after" , "slot": 42 } , { "type": "sig" , "keyHash": "00000000000000000000000000000000000000000000000000000001" } ] } ] } cbor: "8201828200581c000000000000000000000000000000000000000000000000000000008202828204182a8200581c00000000000000000000000000000000000000000000000000000001" - json: { "type": "before" , "slot": 42 } cbor: "8205182a" - json: { "type": "atLeast" , "required": 2 , "scripts": [ { "type": "sig", "keyHash": "00000000000000000000000000000000000000000000000000000000" } , { "type": "sig", "keyHash": "00000000000000000000000000000000000000000000000000000001" } , { "type": "sig", "keyHash": "00000000000000000000000000000000000000000000000000000002" } ] } cbor: "00830302838200581c000000000000000000000000000000000000000000000000000000008200581c000000000000000000000000000000000000000000000000000000018200581c00000000000000000000000000000000000000000000000000000002" ``` ## Rationale: how does this CIP achieve its goals? - The preimage for computing script hashes is prefixed with `\x00` to distinguish them from phase-2 monetary scripts (a.k.a Plutus Script) which are then prefixed with `\x01`. This is merely a discriminator tag. - The current JSON format is based off the cardano-cli's format which has been used widely for minting tokens and is likely the most widely accepted format at the moment. ## Path to Active ### Acceptance Criteria - [x] There exist official software releases supporting this serialization format: - [x] [cardano-cli](https://github.com/IntersectMBO/cardano-cli) - [x] [cardano-api](https://github.com/IntersectMBO/cardano-api) ### Implementation Plan - [x] Incorporating this serialization format into Cardano software libraries and command line tools. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0029/phase-1-monetary-scripts.cddl ================================================ script = [ script_key // script_all // script_any // script_n_of_k // script_after // script_before ] script_key = (0, keyhash) script_all = (1, [ * script ]) script_any = (2, [ * script ]) script_n_of_k = (3, n: uint, [ * script ]) ; Timelock validity intervals are half-open intervals [a, b). ; This field specifies the left (included) endpoint a. script_after = (4, uint) ; Timelock validity intervals are half-open intervals [a, b). ; This field specifies the right (excluded) endpoint b. script_before = (5, uint) keyhash = bytes .size 28 ================================================ FILE: CIP-0029/phase-1-monetary-scripts.json ================================================ { "$schema": "" , "title": "Phase-1 Monetary Scripts" , "oneOf": [ { "$ref": "#/definitions/Script@keyHash" } , { "$ref": "#/definitions/Script@after" } , { "$ref": "#/definitions/Script@before" } , { "$ref": "#/definitions/Script@any" } , { "$ref": "#/definitions/Script@all" } , { "$ref": "#/definitions/Script@atLeast" } ] , "definitions": { "Script@keyHash": { "type": "object" , "additionalProperties": false , "required": [ "type", "keyHash" ] , "properties": { "type": { "type": "string" , "enum": [ "sig" ] } , "keyHash": { "type": "string" , "encoding": "base16" , "minLength": 56 , "maxLength": 56 } } } , "Script@before": { "type": "object" , "additionalProperties": false , "required": [ "type", "slot" ] , "properties": { "type": { "type": "string" , "enum": [ "before" ] } , "slot": { "type": "integer" , "minimum": 1 } } } , "Script@after": { "type": "object" , "additionalProperties": false , "required": [ "type", "slot" ] , "properties": { "type": { "type": "string" , "enum": [ "after" ] } , "slot": { "type": "integer" , "minimum": 1 } } } , "Script@any": { "type": "object" , "additionalProperties": false , "required": [ "type", "scripts" ] , "properties": { "type": { "type": "string" , "enum": [ "any" ] } , "scripts": { "type": "array" , "items": { "$ref": "#" } } } } , "Script@all": { "type": "object" , "additionalProperties": false , "required": [ "type", "scripts" ] , "properties": { "type": { "type": "string" , "enum": [ "all" ] } , "scripts": { "type": "array" , "items": { "$ref": "#" } } } } , "Script@atLeast": { "type": "object" , "additionalProperties": false , "required": [ "type", "required", "scripts" ] , "properties": { "type": { "type": "string" , "enum": [ "atLeast" ] } , "required": { "type": "integer" , "minimum": 0 } , "scripts": { "type": "array" , "items": { "$ref": "#" } } } } } } ================================================ FILE: CIP-0030/README.md ================================================ --- CIP: 30 Title: Cardano dApp-Wallet Web Bridge Status: Active Category: Wallets Authors: - rooooooooob Implementors: - Begin - Eternl - Flint - GeroWallet - Lace - Nami - NuFi - RayWallet - Yoroi Discussions: - https://github.com/cardano-foundation/CIPs/pull/88 - https://github.com/cardano-foundation/CIPs/pull/148 - https://github.com/cardano-foundation/CIPs/pull/151 - https://github.com/cardano-foundation/CIPs/pull/183 - https://github.com/cardano-foundation/CIPs/pull/208 - https://github.com/cardano-foundation/CIPs/pull/323 - https://github.com/cardano-foundation/CIPs/issues/169 - https://github.com/cardano-foundation/CIPs/issues/178 - https://github.com/cardano-foundation/CIPs/issues/204 - https://github.com/cardano-foundation/CIPs/issues/253 - https://github.com/cardano-foundation/CIPs/issues/386 - https://github.com/cardano-foundation/CIPs/issues/404 - https://github.com/cardano-foundation/CIPs/issues/419 - https://github.com/cardano-foundation/CIPs/pull/446 Created: 2021-04-29 License: CC-BY-4.0 --- ## Abstract This documents describes a webpage-based communication bridge allowing webpages (i.e. dApps) to interface with Cardano wallets. This is done via injected javascript code into webpages. This specification defines the manner that such code is to be accessed by the webpage/dApp, as well as defining the API for dApps to communicate with the user's wallet. This document currently concerns the Shelley-Mary era but will have a second version once Plutus is supported. This specification is intended to cover similar use cases as web3 for Ethereum or [EIP-0012](https://github.com/ergoplatform/eips/pull/23) for Ergo. The design of this spec was based on the latter. ## Motivation: why is this CIP necessary? In order to facilitate future dApp development, we will need a way for dApps to communicate with the user's wallet. While Cardano does not yet support smart contracts, there are still various use cases for this, such as NFT management. This will also lay the groundwork for an updated version of the spec once the Alonzo hardfork is released which can extend it to allow for Plutus support. ## Specification ### Data Types #### Address A string representing an address in either bech32 format, or hex-encoded bytes. All return types containing `Address` must return the hex-encoded bytes format, but must accept either format for inputs. #### Bytes A hex-encoded string of the corresponding bytes. #### `cbor` A hex-encoded string representing [CBOR](https://tools.ietf.org/html/rfc7049) corresponding to `T` defined via [CDDL](https://tools.ietf.org/html/rfc8610) either inside of the [Shelley Multi-asset binary spec](https://github.com/input-output-hk/cardano-ledger-specs/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl) or, if not present there, from the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md). This representation was chosen when possible as it is consistent across the Cardano ecosystem and widely used by other tools, such as [cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib), which has support to encode every type in the binary spec as CBOR bytes. #### DataSignature ```ts type DataSignature = {| signature: cbor, key: cbor, |}; ``` #### TransactionUnspentOutput If we have CBOR specified by the following CDDL referencing the Shelley-MA CDDL: ```cddl transaction_unspent_output = [ input: transaction_input, output: transaction_output, ] ``` then we define ```ts type TransactionUnspentOutput = cbor ``` This allows us to use the output for constructing new transactions using it as an output as the `transaction_output` in the Shelley Multi-asset CDDL does not contain enough information on its own to spend it. #### Paginate ```ts type Paginate = {| page: number, limit: number, |}; ``` Used to specify optional pagination for some API calls. Limits results to {limit} each page, and uses a 0-indexing {page} to refer to which of those pages of {limit} items each. dApps should be aware that if a wallet is modified between paginated calls that this will change the pagination, e.g. some results skipped or showing up multiple times but otherwise the wallet must respect the pagination order. #### Extension An extension is an object with a single field `"cip"` that describes a CIP number extending the API (as a plain integer, without padding). For example: ```ts { "cip": 30 } ``` ### Error Types #### APIError ```ts APIErrorCode { InvalidRequest: -1, InternalError: -2, Refused: -3, AccountChange: -4, } APIError { code: APIErrorCode, info: string } ``` * InvalidRequest - Inputs do not conform to this spec or are otherwise invalid. * InternalError - An error occurred during execution of this API call. * Refused - The request was refused due to lack of access - e.g. wallet disconnects. * AccountChange - The account has changed. The dApp should call `wallet.enable()` to reestablish connection to the new account. The wallet should not ask for confirmation as the user was the one who initiated the account change in the first place. #### DataSignError ```ts DataSignErrorCode { ProofGeneration: 1, AddressNotPK: 2, UserDeclined: 3, } type DataSignError = { code: DataSignErrorCode, info: String } ``` * ProofGeneration - Wallet could not sign the data (e.g. does not have the secret key associated with the address) * AddressNotPK - Address was not a P2PK address and thus had no SK associated with it. * UserDeclined - User declined to sign the data #### PaginateError ```ts type PaginateError = {| maxSize: number, |}; ``` {maxSize} is the maximum size for pagination and if the dApp tries to request pages outside of this boundary this error is thrown. #### TxSendError ```ts TxSendErrorCode = { Refused: 1, Failure: 2, } type TxSendError = { code: TxSendErrorCode, info: String } ``` * Refused - Wallet refuses to send the tx (could be rate limiting) * Failure - Wallet could not send the tx #### TxSignError ```ts TxSignErrorCode = { ProofGeneration: 1, UserDeclined: 2, } type TxSignError = { code: TxSignErrorCode, info: String } ``` * ProofGeneration - User has accepted the transaction sign, but the wallet was unable to sign the transaction (e.g. not having some of the private keys) * UserDeclined - User declined to sign the transaction ### Initial API In order to initiate communication from webpages to a user's Cardano wallet, the wallet must provide the following javascript API to the webpage. A shared, namespaced `cardano` object must be injected into the page if it did not exist already. Each wallet implementing this standard must then create a field in this object with a name unique to each wallet containing a `wallet` object with the following methods. The API is split into two stages to maintain the user's privacy, as the user will have to consent to `cardano.{walletName}.enable()` in order for the dApp to read any information pertaining to the user's wallet with `{walletName}` corresponding to the wallet's namespaced name of its choice. #### `cardano.{walletName}.enable({ extensions: Extension[] } = {}): Promise` Errors: `APIError` This is the entrypoint to start communication with the user's wallet. The wallet should request the user's permission to connect the web page to the user's wallet, and if permission has been granted, the full API will be returned to the dApp to use. The wallet can choose to maintain a whitelist to not necessarily ask the user's permission every time access is requested, but this behavior is up to the wallet and should be transparent to web pages using this API. If a wallet is already connected this function should not request access a second time, and instead just return the `API` object. Upon start, dApp can explicitly request a list of additional functionalities they expect as a list of CIP numbers capturing those extensions. This is used as an extensibility mechanism to document what functionalities can be provided by the wallet interface. CIP-0030 provides a set of base interfaces that every wallet must support. Then, new functionalities are introduced via additional CIPs and may be all or partially supported by wallets. DApps are expected to use this endpoint to perform an initial handshake and ensure that the wallet supports all their required functionalities. Note that it's possible for two extensions to be mutually incompatible (because they provide two conflicting features). While we may try to avoid this as much as possible while designing CIPs, it is also the responsability of wallet providers to assess whether they can support a given combination of extensions, or not. Hence wallets aren't expected to fail should they not recognize or not support a particular combination of extensions. Instead, they should decide what they enable and reflect their choice in the response to `api.getExtensions()` in the Full API. As a result, dApps may fail and inform their users or may use a different, less-efficient, strategy to cope with a lack of functionality. It is at the extension author's discretion if they wish to separate their endpoints from the base API via namespacing. Although, it is highly recommend that authors do namespace all of their extensions. If namespaced, endpoints must be preceded by `.cipXXXX.` from the `API` object, without any leading zeros. For example; CIP-0123's endpoints should be accessed by: ```ts api.cip123.endpoint1() api.cip123.endpoint2() ``` For list of accepted CIP-30 extensions please see [CIP-30 Accepted Extensions Register](./extensions-register.md). Authors should be careful when omitting namespacing. Omission should only be considered when creating endpoints to override those defined in this specification or other extensions. Even so when overriding; the new functionality should not prevent dApps from accessing past functionality thus overriding must ensure backwards compatibility. Any namespace omission needs to be fully justified via the proposal's Rationale section, with explanation to why it is necessary. Any potential backwards compatibility considerations should be noted to give wallets and dApps a clear unambiguous direction. ##### Draft or Experimental Extensions Extensions that are draft, in development, or prototyped should not use extension naming nor should they use official namspacing until assigned a CIP number. Draft extension authors are free to test their implementation endpoints by using the [Experimental API](#experimental-api). Once a CIP number is assigned implementors should move functionality out of the experimental API. ##### Can extensions depend on other extensions? Yes. Extensions may have other extensions as pre-requisite. Some newer extensions may also invalidate functionality introduced by earlier extensions. There's no particular rule or constraints in that regards. Extensions are specified as CIP, and will define what it entails to enable them. ##### Should extensions follow a specific format? Yes. They all are CIPs. ##### Can extensions add their own endpoints and/or error codes? Yes. Extensions may introduce new endpoints or error codes, and modify existing ones. Although, it is recommended that endpoints are namespaced. Extensions may even change the rules outlined in this very proposal. The idea being that wallet providers should start off implementing this CIP, and then walk their way to implementing their chosen extensions. ##### Are wallet expected to implement all extensions? No. It's up to wallet providers to decide which extensions they ought to support. #### `cardano.{walletName}.isEnabled(): Promise` Errors: `APIError` Returns true if the dApp is already connected to the user's wallet, or if requesting access would return true without user confirmation (e.g. the dApp is whitelisted), and false otherwise. If this function returns true, then any subsequent calls to `wallet.enable()` during the current session should succeed and return the `API` object. #### `cardano.{walletName}.apiVersion: String` The version number of the API that the wallet supports. Set to `1`. #### `cardano.{walletName}.supportedExtensions: Extension[]` A list of extensions supported by the wallet. Extensions may be requested by dApps on initialization. Some extensions may be mutually conflicting and this list does not thereby reflect what extensions will be enabled by the wallet. Yet it informs on what extensions are known and can be requested by dApps if needed. #### `cardano.{walletName}.name: String` A name for the wallet which can be used inside of the dApp for the purpose of asking the user which wallet they would like to connect with. #### `cardano.{walletName}.icon: String` A URI image (e.g. data URI base64 or other) for img src for the wallet which can be used inside of the dApp for the purpose of asking the user which wallet they would like to connect with. ### Full API Upon successful connection via `cardano.{walletName}.enable()`, a javascript object we will refer to as `API` (type) / `api` (instance) is returned to the dApp with the following methods. All read-only methods (all but the signing functionality) should not require any user interaction as the user has already consented to the dApp reading information about the wallet's state when they agreed to `cardano.{walletName}.enable()`. The remaining methods `api.signTx()` and `api.signData()` must request the user's consent in an informative way for each and every API call in order to maintain security. The API chosen here is for the minimum API necessary for dApp <-> Wallet interactions without convenience functions that don't strictly need the wallet's state to work. The API here is for now also only designed for Shelley's Mary hardfork and thus has NFT support. When Alonzo is released with Plutus support this API will have to be extended. #### `api.getExtensions(): Promise` Errors: `APIError` Retrieves the list of extensions enabled by the wallet. This may be influenced by the set of extensions requested in the initial `enable` request. #### `api.getNetworkId(): Promise` Errors: `APIError` Returns the network id of the currently connected account. 0 is testnet and 1 is mainnet but other networks can possibly be returned by wallets. Those other network ID values are not governed by this document. This result will stay the same unless the connected account has changed. #### `api.getUtxos(amount: cbor = undefined, paginate: Paginate = undefined): Promise` Errors: `APIError`, `PaginateError` If `amount` is `undefined`, this shall return a list of all UTXOs (unspent transaction outputs) controlled by the wallet. If `amount` is not `undefined`, this request shall be limited to just the UTXOs that are required to reach the combined ADA/multiasset value target specified in `amount`, and if this cannot be attained, `null` shall be returned. The results can be further paginated by `paginate` if it is not `undefined`. #### (DEPRECATED) `api.getCollateral(params: { amount: cbor }): Promise` Errors: `APIError` ##### DEPRECATION NOTICE Since [CIP-0040 | Collateral Output](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0040/README.md) and Babbage era "Collateral Return" and "Total Collateral" fields on a transaction body are supported, a transaction can now use up to three **any** collateral inputs and specify the collateral return outputs to receive extra ada and tokens back as change. Transaction-building SDKs and libraries now all support this functionality as well (see [Blaze](https://blaze.butane.dev/), [Mesh](https://meshjs.dev/), [Lucid Evolution](https://anastasia-labs.github.io/lucid-evolution/), [CSL](https://github.com/Emurgo/cardano-serialization-lib)). The dedicated transaction fields and strong tooling support removes the **need** for dedicated cumbersome API for providing *special* collateral inputs to exist. DApps should make effort to build transactions using the latest available best methods and practices. In this case it means always utilising collateral return and not risking burning UTxOs with no return. Wallets looking to implement this standard are free to **not** support this deprecated API function, which does require some extra special management of UTxOs within the wallet, beyond normal logic. Deprecating this method aims to motivate DApp implementors not to use this method, but rather to use newer better techniques. Any future versions of "wallet-to-dapp" APIs seeking to replace CIP30 should **not ever** include any methods of this kind. This mistake of history should be forgotten forever. ##### Description The function takes a required object with parameters. With a single **required** parameter for now: `amount`. (**NOTE:** some wallets may be ignoring the amount parameter, in which case it might be possible to call the function without it, but this behavior is not recommended!). Reasons why the `amount` parameter is required: 1. Dapps must be motivated to understand what they are doing with the collateral, in case they decide to handle it manually. 2. Depending on the specific wallet implementation, requesting more collateral than necessarily might worsen the user experience with that dapp, requiring the wallet to make explicit wallet reorganisation when it is not necessary and can be avoided. 3. If dapps don't understand how much collateral they actually need to make their transactions work - they are placing more user funds than necessary in risk. So requiring the `amount` parameter would be a by-spec behavior for a wallet. Not requiring it is possible, but not specified, so dapps should not rely on that and the behavior is not recommended. This shall return a list of one or more UTXOs (unspent transaction outputs) controlled by the wallet that are required to reach **AT LEAST** the combined ADA value target specified in `amount` **AND** the best suitable to be used as collateral inputs for transactions with plutus script inputs (pure ADA-only utxos). If this cannot be attained, an error message with an explanation of the blocking problem shall be returned. **NOTE:** wallets are free to return utxos that add up to a **greater** total ADA value than requested in the `amount` parameter, but wallets must never return any result where utxos would sum up to a smaller total ADA value, instead in a case like that an error message must be returned. The main point is to allow the wallet to encapsulate all the logic required to handle, maintain, and create (possibly on-demand) the UTXOs suitable for collateral inputs. For example, whenever attempting to create a plutus-input transaction the dapp might encounter a case when the set of all user UTXOs don't have any pure entries at all, which are required for the collateral, in which case the dapp itself is forced to try and handle the creation of the suitable entries by itself. If a wallet implements this function it allows the dapp to not care whether the suitable utxos exist among all utxos, or whether they have been stored in a separate address chain (see https://github.com/cardano-foundation/CIPs/pull/104), or whether they have to be created at the moment on-demand - the wallet guarantees that the dapp will receive enough utxos to cover the requested amount, or get an error in case it is technically impossible to get collateral in the wallet (e.g. user does not have enough ADA at all). The `amount` parameter is required, specified as a `string` (BigNumber) or a `number`, and the maximum allowed value must be agreed to be something like 5 ADA. Not limiting the maximum possible value might force the wallet to attempt to purify an unreasonable amount of ADA just because the dapp is doing something weird. Since by protocol the required collateral amount is always a percentage of the transaction fee, it seems that the 5 ADA limit should be enough for the foreseeable future. #### `api.getBalance(): Promise>` Errors: `APIError` Returns the total balance available of the wallet. This is the same as summing the results of `api.getUtxos()`, but it is both useful to dApps and likely already maintained by the implementing wallet in a more efficient manner so it has been included in the API as well. #### `api.getUsedAddresses(paginate: Paginate = undefined): Promise` Errors: `APIError` Returns a list of all used (included in some on-chain transaction) addresses controlled by the wallet. The results can be further paginated by `paginate` if it is not `undefined`. #### `api.getUnusedAddresses(): Promise` Errors: `APIError` Returns a list of unused addresses controlled by the wallet. #### `api.getChangeAddress(): Promise
` Errors: `APIError` Returns an address owned by the wallet that should be used as a change address to return leftover assets during transaction creation back to the connected wallet. This can be used as a generic receive address as well. #### `api.getRewardAddresses(): Promise` Errors: `APIError` Returns the reward addresses owned by the wallet. This can return multiple addresses e.g. CIP-0018. #### `api.signTx(tx: cbor, partialSign: bool = false): Promise>` Errors: `APIError`, `TxSignError` Requests that a user sign the unsigned portions of the supplied transaction. The wallet should ask the user for permission, and if given, try to sign the supplied body and return a signed transaction. If `partialSign` is true, the wallet only tries to sign what it can. If `partialSign` is false and the wallet could not sign the entire transaction, `TxSignError` shall be returned with the `ProofGeneration` code. Likewise if the user declined in either case it shall return the `UserDeclined` code. Only the portions of the witness set that were signed as a result of this call are returned to encourage dApps to verify the contents returned by this endpoint while building the final transaction. #### `api.signData(addr: Address, payload: Bytes): Promise` Errors: `APIError`, `DataSignError` This endpoint utilizes the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/README.md) for standardization/safety reasons. It allows the dApp to request the user to sign a payload conforming to said spec. The user's consent should be requested and the message to sign shown to the user. The payment key from `addr` will be used for base, enterprise and pointer addresses to determine the EdDSA25519 key used. The staking key will be used for reward addresses. This key will be used to sign the `COSE_Sign1`'s `Sig_structure` with the following headers set: * `alg` (1) - must be set to `EdDSA` (-8) * `kid` (4) - Optional, if present must be set to the same value as in the `COSE_key` specified below. It is recommended to be set to the same value as in the `"address"` header. * `"address"` - must be set to the raw binary bytes of the address as per the binary spec, without the CBOR binary wrapper tag The payload is not hashed and no `external_aad` is used. If the payment key for `addr` is not a P2Pk address then `DataSignError` will be returned with code `AddressNotPK`. `ProofGeneration` shall be returned if the wallet cannot generate a signature (i.e. the wallet does not own the requested payment private key), and `UserDeclined` will be returned if the user refuses the request. The return shall be a `DataSignature` with `signature` set to the hex-encoded CBOR bytes of the `COSE_Sign1` object specified above and `key` shall be the hex-encoded CBOR bytes of a `COSE_Key` structure with the following headers set: * `kty` (1) - must be set to `OKP` (1) * `kid` (2) - Optional, if present must be set to the same value as in the `COSE_Sign1` specified above. * `alg` (3) - must be set to `EdDSA` (-8) * `crv` (-1) - must be set to `Ed25519` (6) * `x` (-2) - must be set to the public key bytes of the key used to sign the `Sig_structure` #### `api.submitTx(tx: cbor): Promise` Errors: `APIError`, `TxSendError` As wallets should already have this ability, we allow dApps to request that a transaction be sent through it. If the wallet accepts the transaction and tries to send it, it shall return the transaction id for the dApp to track. The wallet is free to return the `TxSendError` with code `Refused` if they do not wish to send it, or `Failure` if there was an error in sending it (e.g. preliminary checks failed on signatures). ### Experimental API Multiple experimental namespaces are used: - under `api` (ex: `api.experimental.myFunctionality`). - under `cardano.{walletName}` (ex: `window.cardano.{walletName}.experimental.myFunctionality`) The benefits of this are: 1. Wallets can add non-standardized features while still following the CIP30 structure 1. dApp developers can use these functions explicitly knowing they are experimental (not stable or standardized) 1. New features can be added to CIP30 as experimental features and only moved to non-experimental once multiple wallets implement it 1. It provides a clear path to updating the CIP version number (when functions move from experimental -> stable) ## Rationale: how does this CIP achieve its goals? See justification and explanations provided with each API endpoint. ### Extensions Extensions provide an extensibility mechanism and a way to negotiate (possibly conflicting) functionality between a DApp and a wallet provider. There's rules enforced as for what extensions a wallet decide to support or enable. The current mechanism only gives a way for wallets to communicate their choice back to a DApp. We use object as extensions for now to leave room for adding fields in the future without breaking all existing interfaces. At this point in time however, objects are expected to be singleton. Extensions can be seen as a smart versioning scheme. Except that, instead of being a monotonically increasing sequence of numbers, they are multi-dimensional feature set that can be toggled on and off at will. This is a versioning "à-la-carte" which is useful in a context where: 1. There are multiple concurrent standardization efforts on different fronts to accommodate a rapidly evolving ecosystem; 2. Not everyone agrees and has desired to support every existing standard; 3. There's a need from an API consumer standpoint to clearly identify what features are supported by providers. #### Namespacing Extensions By encouraging the explicit namespacing of each extension we aim to improve the usability of extensions for dApps. By allowing special cases where namespacing can be dropped we maintain good flexibility in extension design. ## Path to Active ### Acceptance Criteria - [x] The interface is implemented and supported by various wallet providers. See also: [cardano-caniuse](https://www.cardano-caniuse.io/). - [x] The interface is used by DApps to interact with wallet providers. Few examples: - https://www.jpg.store/ - https://app.minswap.org/ - https://muesliswap.com/ - https://exchange.sundaeswap.finance/ - https://app.indigoprotocol.io/ ### Implementation Plan - [x] Provide some reference implementation of wallet providers - [Berry-Pool/nami-wallet](https://github.com/berry-pool/nami/blob/4d7539b2768464480a9cff53a2d66af9879f8534/src/pages/Content/injected.js) - [Emurgo/yoroi-wallet](https://github.com/Emurgo/yoroi-frontend/blob/f4eabb25eedd564821514059479835601f8073ab/packages/yoroi-connector/example-cardano/index.js) - [x] Provide some reference implementation of the dapp connector - [cardano-foundation/connect-with-wallet](https://github.com/cardano-foundation/cardano-connect-with-wallet) ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0030/extensions-register.md ================================================ # CIP-30 Accepted Extensions Register This registry aims to document all CIP-30 extensions accepted as CIPs. The aim of this document is to aid the discoverability of CIP-30 extensions. | Extension CIP | Link | Description | | --- | --- | --- | | CIP-0095 - Web-Wallet Bridge - Conway ledger era | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0095 | Extension to enable support for Conway ledger era and governance | | CIP-0103 - Web-Wallet Bridge - Bulk transaction signing | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0103 | Extension to provide an additional endpoint for dApp to sign multiple transactions in bulk | | CIP-0104 - Web-Wallet Bridge - Account public key | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0104 | Extension to provide an additional endpoint for dApp to get the extended account public key from a connected wallet | | CIP-0106 - Web-Wallet Bridge - Multisig wallets | https://github.com/cardano-foundation/CIPs/tree/master/CIP-0106 | Extension to provide a interface for dApps and Cardano Multisig-wallets | ================================================ FILE: CIP-0031/README.md ================================================ --- CIP: 31 Title: Reference inputs Status: Active Category: Plutus Authors: - Michael Peyton Jones Implementors: - Michael Peyton Jones - Jared Corduan Discussions: - https://github.com/cardano-foundation/CIPs/pull/159 Created: 2021-11-29 License: CC-BY-4.0 --- ## Abstract We introduce a new kind of input, a _reference_ input, which allows looking at an output without spending it. This will facilitate access to information stored on the blockchain without the churn associated with spending and recreating UTXOs. ## Motivation: why is this CIP necessary? Datums in transaction outputs provide a way to store and access information on the blockchain. However, they are quite constrained in a number of ways. Most notably, in order to access the information which is contained in them, you have to _spend_ the output that the datum is attached to. This has a number of undesirable features: 1. Even if the output is recreated after being spent, it is still a _new_ output. Any other user who wishes to look at the data cannot spend the old output (which is gone), but must rather spend the new output (which they will not know about until the next block). In practice this throttles some applications to one "operation" per block. 2. Looking at the _information_ in the datum requires _spending_ the output, which means that care must be taken over the distribution of any funds in the output (possibly requiring scripts), and spending conditions must be met. This is overly stringent, inconvenient, and expensive. We would like to have a mechanism for accessing the information in datums that avoids these issues. ### Use cases Here are some cases where we expect this to be helpful. 1. Inspecting the state (datum, or locked value) of an on-chain application without having to consume the output, e.g. checking the current state of a stablecoin state machine. 2. On-chain data providers that store data in outputs, to be referenced by other scripts. 3. (With inline datums) Creating a single UTXO with data to be used in multiple subsequent transactions, but only paying the cost for submitting it once. ### Enabling further improvements This proposal was designed in tandem with two further proposals which make use of reference scripts, CIP-32 (Inline datums) and CIP-33 (Reference scripts). A full assessment of the worth of this proposal should take into account the fact that it is an enabler for these other proposals. ## Specification ### Reference inputs We introduce a new kind of transaction input, a reference input. Transaction authors specify inputs as either normal (spending) inputs or reference inputs. A reference input is a transaction input, which is linked to a particular transaction output as normal, except that it _references_ the output rather than _spending_ it. That is: - A referenced output must exist in the UTXO set. - Any value on a referenced output is _not_ considered when balancing the transaction. - The spending conditions on referenced outputs are _not_ checked, nor are the witnesses required to be present. - i.e. validators are not required to pass (nor are the scripts themselves or redeemers required to be present at all), and signatures are not required for pubkey outputs. - Referenced outputs are _not_ removed from the UTXO set if the transaction validates. - Reference inputs _are_ visible to scripts. For clarity, the following two behaviours which are present today are unchanged by this proposal: 1. Transactions must _spend_ at least one output.[^1] 2. Spending an output _does_ require the spending conditions to be checked.[^2] [^1]: This restriction already exists, and is important. It seems unnecessary, since transactions must always pay fees and fees must come from somewhere, but fees could in principle be paid via reward withdrawals, so the requirement to spend a UTXO is relevant. [^2]: That is, this proposal does not change outputs or the spending of outputs, it instead adds a new way of _referring_ to outputs. ### Script context Scripts are passed information about transactions via the script context. The script context therefore needs to be augmented to contain information about reference inputs. Changing the script context will require a new Plutus language version in the ledger to support the new interface. The change in the new interface is: a _new_ field is added to the structure which contains the list of reference inputs. The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include reference inputs, attempting to do so will be a phase 1 transaction validation failure. ### Extra datums Today, transactions can contain extra datums that are not required for validation. Currently the extra datums must all be pre-images of datum hashes that appear in outputs. We change this so that the extra datums can also be pre-images of datum hashes that appear in reference inputs.[^3] Note that the existing mechanism includes the hash of the extra datum structure in the transaction body, so that additional datums cannot be stripped by an attacker without voiding transaction signatures. [^3]: Pre-images of datum hashes that appear in _spent_ inputs are of course mandatory. ### CDDL The CDDL for transaction bodies will change to the following to reflect the new field. ``` transaction_body = { 0 : set ; inputs ... , ? 16 : set ; reference inputs } ``` ## Rationale: how does this CIP achieve its goals? The key idea of this proposal is to use UTXOs to carry information. But UTXOs are currently a bad fit for distributing information. Because of locality, we have to include outputs that we use in the transaction, and the only way we have of doing that is to _spend_ them - and a spent output cannot then be referenced by anything else. To put it another way: outputs are resource-like, but information is not resource-like. The solution is to add a way to _inspect_ ("reference") outputs without spending them. This allows outputs to play double duty as resource containers (for the value they carry) and information containers (for the data they carry). ### Requirements We have a number of requirements that we need to fulfil. - Determinism - It must be possible to predict the execution of scripts precisely, given the transaction. - Locality - All data involved in transaction validation should be included in the transaction or the outputs which it spends (or references). - Non-interference - As far as possible, transactions should not interfere with others. The key exception is when transactions consume resources that other transactions want (usually by consuming UTXO entries). - Replay protection - The system should not be attackable (e.g. allow unexpected data reads) by replaying old traffic. - Storage control and garbage-collection incentives - The amount of storage required by the system should have controls that prevent it from overloading nodes, and ideally should have incentives to shrink the amount of storage that is used over time. - Optimized storage - The system should be amenable to optimized storage solutions. - Data transfer into scripts - Scripts must have a way to observe the data. - Tool and library support - It should not be too difficult for tools and libraries to work with the new system. - Hydra - The system should be usable without compromising the needs of Hydra, such as parallel processing of independent parts of the transaction graph. Reference inputs satisfy these requirements, mostly by inheriting them from the corresponding properties of UTXOs. - Referencing an output still requires the output to be presented as part of the transaction and be unspent, so determinism is preserved. - Referenced outputs appear as transaction inputs, so locality is preserved. - Outputs can be referenced multiple times, so we have non-interference even under heavy usage of referencing. Conflicts can occur only if the output is actually spent. - Replay protection is inherited because a transaction must always spend at least one UTXO, and UTXOs can only be spent once. - Storage control is inherited from control of the UTXO set, via the min UTXO value incentives. Data can be "retired" by spending the input (rather than referencing it), reclaiming the min UTXO value. - Optimized storage is inherited directly from work on improving UTXO storage. - Data transfer into scripts works automatically since scripts can see transaction inputs. - Tools and libraries will only have to deal with a new kind of transaction input, and unless they care about scripts they can likely ignore them entirely. - Hydra is able to work with reference inputs (see below). ### Why UTXOs? There are various approaches to augmenting Cardano with the ability to store and retrieve data more easily. All of these require some kind of resource-like system for the _storage_ that is used for data. The main argument in favour of the reference input approach is that it reuses our existing resource-like system: UTXOs. As we've seen above, this allows us to satisfy most of our requirements for free. Any other approach would need new solutions to these problems. As a brief example, suppose we wanted to instead implement data storage as an on-chain, hash-indexed data store (a proposal we considered). Then we would need to answer a lot of questions: - How is the data accessed and retrieved? Are these stateful operations? Does this make transaction ordering more significant, threatening determinism? - How is the storage usage controlled? Do people pay for storing data? Do they pay for a fixed period, or perpetually? How is data retired? - How is the storage going to be implemented? How will this affect node memory usage? - How are scripts going to access the data in the store? - How will tools interact with and visualize the store and changes to it? ### How should we present the information to scripts? Scripts definitely need to see reference inputs. But we have at least two options for how we represent this in the script context: put the reference inputs in their own field; or include them with the other inputs, but tag them appropriately. Keeping them separate seems wise given the potential for confusing reference inputs for normal inputs. That would be quite a dangerous programming error, as it might lead a script to believe that e.g. an output had been spent when in fact it had only been referenced. We also have the question of what to do about old scripts. We can't really present the information about reference inputs to them in a faithful way: representing them as spending inputs would be wildly misleading, and there is nowhere else to put them. We could omit the information entirely, but this is dangerous in a different way. Omitting information may lead scripts to make assumptions about the transaction that are untrue; for this reason we prefer not to silently omit information as a general principle. That leaves us only one option: reject transactions where we would have to present information about reference inputs to old scripts. ### Accessing the datums of reference inputs Currently this proposal has somewhat limited utility, because datums in outputs are just hashes, and the spending party is required to find and provide the preimage themselves. Therefore the CIP-32 proposal for inline datums is complementary, as it allow UTXOs to carry the data itself rather than a hash. In the mean time (or if CIP-32 is not implemented), we still want users to be _able_ to provide the datums corresponding to datum hashes in reference outputs, so that at least it is possible to reference the data, albeit clumsily. The easiest solution here is to reuse the existing mechanism for providing pre-images of datum hashes which appear in outputs. Providing datum hash pre-images remains optional, since there are reasons to use reference inputs even without looking at the datum, e.g. to look at the value in an output. ### Accessing the value locked in outputs The motivation of this proposal mainly requires looking at the _datums_ of outputs. But reference inputs allow us to do more: they let us look at the _value_ locked in an output (i.e. how much Ada or other tokens it contains). This is actually a very important feature. Since anyone can lock an output with any address, addresses are not that useful for identifying _particular_ outputs on chain, and instead we usually rely on looking for particular tokens in the value locked by the output. Hence, if a script is interested in referring to the data attached to a _particular_ output, it will likely want to look at the value that is locked in the output. For example, an oracle provider would need to distinguish the outputs that they create (with good data) from outputs created by adversaries (with bad data). They can do this with a token, so long as scripts can then see the token! ### Hydra We want reference inputs to be usable inside Hydra heads. This raises a worry: since Hydra processes independent parts of the transaction graph in parallel, what happens if it accepts one transaction that references an output, and one that spends the output, but then the first transaction gets put into a checkpoint before the second? Fortunately, Hydra already has to deal with double-spend conflicts of this kind (although in the naive protocol this results in a decommit). This proposal simply introduces a new kind of conflict, a reference-spend conflict. Reference-spend conflicts should be handled by the same mechanism that is used to handle double-spend conflicts. ### Controlling referencing One thing that a user might want to do is to control who can reference an output. For example, an oracle provider might want to only allow a transaction to reference a particular output if the transaction also pays them some money. Reference inputs alone do _not_ provide any way to do this. Another mechanism would be required, but there is no consensus on what the design should be, so it is currently out of scope for this proposal. A brief summary of a few options and reasons why they are not obvious choices is included below. A key issue is that the choice to control referencing must lie with the _creator_ of the output, not the _spender_. Therefore we _must_ include some kind of change to outputs so that the creator can record their requirements. #### Check inputs A "check input" is like a reference input except that the spending conditions _are_ checked. That is, it acts as proof that you _could_ spend the input, but does not in fact spend it. Since check inputs cause validator scripts to be run, it seems like they could allow us to control referencing. There are two wrinkles: - The same script would be used for both referencing and spending, overloading the meaning of the validator script. This is still _usable_, however, since the redeemer could be used to indicate which action is being taken. - We would need a flag on outputs to say "this output cannot be referenced, but only checked". Exactly what this should look like is an open question, perhaps it should be generic enough to control all the possible ways in which an output might be used (of which there would be three). #### Referencing conditions "Referencing conditions" would mean adding a new field to outputs to indicate under what conditions the output may be referenced. This could potentially be an entire additional address, since the conditions might be any of the normal spending conditions (public key or script witnessing). However, this would make outputs substantially bigger and more complicated. ### Related work Reference inputs are very similar to Ergo's "data inputs". We chose to name them differently since "data" is already a widely used term with risk for confusion. We might also want to introduce other "verb" inputs in future. ## Path to Active ### Acceptance Criteria - [x] Fully implemented in Cardano as of the Vasil protocol upgrade. ### Implementation Plan - [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0032/README.md ================================================ --- CIP: 32 Title: Inline datums Status: Active Category: Plutus Authors: - Michael Peyton Jones Implementors: - Michael Peyton Jones - Jared Corduan Discussions: - https://github.com/cardano-foundation/CIPs/pull/160 Created: 2021-11-29 License: CC-BY-4.0 --- ## Abstract We propose to allow datums themselves to be attached to outputs instead of datum hashes. This will allow much simpler communication of datum values between users. ## Motivation: why is this CIP necessary? Conceptually, datums are pieces of data that are attached to outputs. However, in practice datums are implemented by attaching _hashes_ of datums to outputs, and requiring that the spending transaction provides the actual datum. This is quite inconvenient for users. Datums tend to represent the result of computation done by the party who creates the output, and as such there is almost no chance that the spending party will know the datum without communicating with the creating party. That means that either the datum must be communicated between parties off-chain, or communicated on-chain by including it in the witness map of the transaction that creates the output ("extra datums"). This is also inconvenient for the spending party, who must watch the whole chain to spot it. It would be much more convenient to just put the _datum itself_ in an output, which is what we propose. ### Use cases We expect that, provided we are able to bring the cost low enough, a large proportion of dapp developers will make use of this feature, as it will simplify their systems substantially. ## Specification Transaction outputs are changed so that the datum field can contain either a hash or a datum (an "inline datum"). The min UTXO value for an output with an inline datum depends on the size of the datum, following the `coinsPerUTxOWord` protocol parameter. When an output with an inline datum is spent, the spending transaction does not need to provide the datum itself. ### Script context Scripts are passed information about transactions via the script context. The script context therefore needs to be augmented to contain information about inline datums. Changing the script context will require a new Plutus language version in the ledger to support the new interface. There are two changes in the new version of the interface: - The datum field on transaction outputs can either be a hash or the actual datum. - The datum field on transaction inputs can either be a hash or the actual datum. The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include inline datums, attempting to do so will be a phase 1 transaction validation failure. ### CDDL The CDDL for transaction outputs will change as follows to reflect the new alternative. ``` transaction_output = [ address , amount : value , ? datum : $hash32 / plutus_data ] ``` TODO: should there be a dedicated production for datum-hash-or-datum? Does it need to be tagged? ## Rationale: how does this CIP achieve its goals? The key idea of this proposal is simply to restore the conceptually straightforward situation where datums are attached to outputs. Historically, this was the way that the EUTXO model was designed, and switching to datum hashes on outputs was done to avoid bloating UTXO entries, which at that time (pre-multiasset) were constant-size (see [^1] page 7). Now that we have variable-sized UTXO entries and the accounting to support them, we can restore inline datums. Since inline datums change very little about the model apart from where data is stored, we don't need to worry about violating any of the other requirements of the ledger, but we do need to worry about the effect on the size of the UTXO set. ### UTXO set size This proposal gives users a way to put much larger amounts of data into the UTXO set. Won’t this lead to much worse UTXO set bloat? The answer is that we already have a mechanism to discourage this, namely the minimum UTXO value. If inline datums turns out to drive significantly increased space usage, then we may need to increase `coinsPerUTxOWord` in order to keep the UTXO size down. That will be costly and inconvenient for users, but will still allow them to use inline datums where they are most useful and the cost is bearable. Furthermore, we hope that we will in fact be able to _reduce_ `coinsPerUTxOWord` when the upcoming work on moving the UTXO mostly to on-disk storage is complete. Another guard rail would be to enforce upper limits on the size of inline datums. At the extreme, we could bound them to the size of a hash, which would guarantee no more space usage than today. However, this is much worse for users, since it introduces a sharp discontinuity where an inline datum is entirely acceptable, until it crosses the size threshold at which point it is unacceptable, and there is no way to avoid this. Generally we prefer to avoid such discontinuities in favour of gradually increasing costs. In practice, what is implemented here may depend on whether the UTXO-on-disk work is completed by the time that this proposal is implemented. ### Other modes of specifying datums We could deprecate the other methods of specifying datums (datum hashes or datum hashes+extra datums). However, the other approaches also have some advantages. - Transmission costs: creator pays versus consumer pays - Inline datums: creator pays - Datum hashes: consumer pays - Datum hashes+extra datums: both pay - Min UTXO value costs - Inline datums: depends on data size - Datum hashes: fixed cost - Datum hashes+extra datums: fixed cost - Privacy - Inline datums: datum is immediately public - Datum hashes: datum is not public until consumed - Datum hashes+extra datums: datum is immediately public, but only to chain-followers - Communication of datums - Inline datums: easy on-chain communication - Datum hashes: off-chain communication necessary - Datum hashes+extra datums: complicated on-chain communication Any one of these factors could be important to particular use cases, so it is good to retain the other options. ### The script context #### Including information about inline datums In principle we do not need to let scripts see whether a datum is inline or not. We could pretend that inline datums are non-inline and insert them into the datum witness map. The underlying question is: do we want scripts to be able to make assertions about whether datums are inline or not? There are reasons to want to do this: _not_ using inline datums causes communication issues for users, and so it is quite reasonable that an application developer may want to be able to enforce their use. Furthermore, as a general principle we try to keep the script context as faithful to real transactions as possible. Even if the use for the information is not immediately obvious, we try to err on the side of providing it and letting users decide. Hence we _do_ include information about inline datums in the script context. #### Representation and backwards compatibility There are a couple of options for how to change the representation of the script context to include the new information, and whether to make a backwards compatibility effort for old language versions. For the new script context: 1. Match the ledger representation as much as possible: change the fields on inputs and outputs to be either a datum hash or a datum. 2. Try to only have one way to look up datums: put inline datums in the datum witness map and insert their hashes into the corresponding inputs and outputs; optionally add a boolean to inputs and outputs to indicate whether the datum was originally inline. For backwards compatibility: 1. Don't try to represent inline datums for scripts using old language versions: old scripts simply can't be run in transactions that use inline datums (since we can't represent the information). 2. Rewrite inline datums as non-inline datums: put inline datums in the datum witness map and insert their hashes into the corresponding inputs and outputs. For the new script context, option 1 has the significant advantage of matching the ledger representation of transactions. This makes it easier to implement, and also avoids conceptual overhead for users who would have to distinguish the two ways of representing transactions. While the conceptual distance here may be small, if we let it grow over time then it may become quite confusing. We then have the choice of what to do about backwards compatibility. Option 2 would work, but is more complicated for the ledger and is inconsistent in representation with our choice for the new script context (inline datums are sometimes represented faithfully, and sometimes put in the witness map). Option 1 is simple, but doesn't allow old scripts to work with inline datums. This would not be so bad if it just meant that old scripts could not be spent in transactions that include inline datums, but it also introduces a new way to make an unspendable output. If a user creates an output with an old script and an inline datum, then any transaction spending that output will include an inline datum, which we would not allow. Unfortunately, we cannot prevent users from creating such outputs in general, since script addresses do not include the script language, so the ledger cannot tell whether the inline datum is permissible or not. Client code typically _will_ be able to do this, since it will usually know the script. The mitigating factor is that we expect this to be uncommon in practice, particularly since we expect that most users will move to the new version relatively quickly, since we expect support for inline datums to be desirable, and released alongside other desirable features. Hence we choose both option 1s and do _not_ provide backwards compatibility for old language versions. ## Path to Active ### Acceptance Criteria - [x] Fully implemented in Cardano as of the Vasil protocol upgrade. ### Implementation Plan - [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). [^1]: Chakravarty, Manuel M. T. et al., "The extended UTXO model" ================================================ FILE: CIP-0033/README.md ================================================ --- CIP: 33 Title: Reference scripts Status: Active Category: Plutus Authors: - Michael Peyton Jones Implementors: - Michael Peyton Jones - Jared Corduan Discussions: - https://github.com/cardano-foundation/CIPs/pull/161 - https://github.com/cardano-foundation/CIPs/pull/213 Created: 2021-11-29 License: CC-BY-4.0 --- ## Abstract We propose to allow scripts ("reference scripts") to be attached to outputs, and to allow reference scripts to be used to satisfy script requirements during validation, rather than requiring the spending transaction to do so. This will allow transactions using common scripts to be much smaller. ## Motivation: why is this CIP necessary? Script sizes pose a significant problem. This manifests itself in two ways: 1. Every time a script is used, the transaction which caused the usage must supply the whole script as part of the transaction. This bloats the chain, and passes on the cost of that bloat to users in the form of transaction size fees. 2. Transaction size limits are problematic for users. Even if individual scripts do not hit the limits, a transaction which uses multiple scripts has a proportionally greater risk of hitting the limit. We would like to alleviate these problems. The key idea is to use reference inputs and modified outputs which carry actual scripts ("reference scripts"), and allow such reference scripts to satisfy the script witnessing requirement for a transaction. This means that the transaction which _uses_ the script will not need to provide it at all, so long as it referenced an output which contained the script. ## Specification We extend transaction outputs with a new optional field, which contains a script (a "reference script"). The min UTXO value for an output with an additional script field depends on the size of the script, following the `coinsPerUTxOWord` protocol parameter. When we are validating a transaction and we look for the script corresponding to a script hash, in addition to the scripts provided in the transaction witnesses, we also consider any reference scripts from the outputs referred to by the inputs of the transaction. ### Script context Scripts are passed information about transactions via the script context. We propose to augment the script context to include some information about reference scripts. Changing the script context will require a new Plutus language version in the ledger to support the new interface. The change is: a new optional field is added to outputs and inputs to represent reference scripts. Reference scripts are represented by their hash in the script context. The interface for old versions of the language will not be changed. Scripts with old versions cannot be spent in transactions that include reference scripts, attempting to do so will be a phase 1 transaction validation failure. ### CDDL The CDDL for transaction outputs will change as follows to reflect the new field. ``` transaction_output = [ address , amount : value , ? datum : $hash32 , ? ref_script : plutus_script ] ``` TODO: can we use a more generic type that allows _any_ script in a forwards-compatible way? ## Rationale: how does this CIP achieve its goals? The key idea of this proposal is stop sending frequently-used scripts to the chain every time they are used, but rather make them available in a persistent way on-chain. The implementation approach follows in the wake of CIP-31 (Reference inputs) and CIP-32 (Inline datums). The former considers how to do data sharing on chain, and concludes that referencing UTXOs is a good solution. The latter shows how we can safely store substantial data in UTXOs by taking advantage of existing mechanisms for size control. It is therefore natural to use the same approach for scripts: put them in UTXOs, and reference them using reference inputs. ### Storing scripts in outputs There are a few possible alternatives for where to store reference scripts in outputs. #### 1: The address field In principle, we could add an "inline scripts" extension that allowed scripts themselves to be used in the address field instead of script hashes. We could then use such scripts as reference scripts. However, this approach suffers from a major confusion about the functional role of the script. You would only be able to provide a reference script that _also_ controlled the spending of the output. This is clearly not what you want: the reference script could be anything, perhaps a script only designed for use in quite specific circumstances; whereas in many cases the user will likely want to retain control over the output with a simple public key. #### 2: The datum field With inline datums, we could put reference scripts in the datum field of outputs. This approach has two problems. First, there is a representation confusion: we would need some way to know that a particular datum contained a reference script. We could do this implicitly, but it would be better to have an explicit marker. Secondly, this prevents having an output which is locked by a script that needs a datum _and_ has a reference script in it. While this is a more unusual situation, it's not out of the question. For example, a group of users might want to use a Plutus-based multisig script to control the UTXO with a reference script in it. #### 3: A new field A new field is the simplest solution: it avoids these problems because the new field clearly has one specific purpose, and we do not overload the meanings of the other fields. ### UTXO set size This proposal gives people a clear incentive to put large amounts (i.e. kilobytes) of data in outputs as reference scripts. This is essentially the same problem which is faced in CIP-32, and we can take the same stance. We don't want to bloat the UTXO set unnecessarily, but we already have mechanisms for limiting that (in the form of the min UTXO value), and these should work transparently for reference scripts as they will for inline datums. ### Changing the script context We don't strictly need to change the script context. We could simply omit any information about reference scripts carried by outputs. This would mean that we don't need to change the interface. We don't have obvious use cases for the information about reference scripts, but the community may come up with use cases, and our general policy is to try and include as much information about the transaction as we can, unless there is a good reason not to. We also have the question of what to do about old scripts. We can't really present the information about reference scripts to them in a faithful way, there is nowhere to put the information. We could omit the information entirely, but this is dangerous in a different way. Omitting information may lead scripts to make assumptions about the transaction that are untrue; for this reason we prefer not to silently omit information as a general principle. That leaves us only one option: reject transactions where we would have to present information about reference scripts to old scripts. ## Path to Active ### Acceptance Criteria - [x] Fully implemented in Cardano as of the Vasil protocol upgrade. ### Implementation Plan - [x] Passes all requirements of both Plutus and Ledger teams as agreed to improve Plutus script efficiency and usability. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0034/README.md ================================================ --- CIP: 34 Title: Chain ID Registry Status: Proposed Category: Tools Authors: - Sebastien Guillemot Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/158 - https://github.com/cardano-foundation/CIPs/pull/332 - https://github.com/cardano-foundation/CIPs/pull/412 Created: 2021-11-24 License: CC-BY-4.0 --- ## Abstract Currently Cardano has two easily-usable networks: "mainnet" and "testnet". However, in the future, we expect more networks to exist and so we need some way to refer to these networks to be able to write better multi-network applications and systems. ## Motivation: why is this CIP necessary? Cardano currently has three ways to refer to a network: - The "network ID" included in every address and also optionally present in the transaction body. This only stores 16 possibilities (4 bits) - The "network magic" used for Byron addresses and in the handshake with other nodes in the network layer. This is a random 32-bit number - The genesis block hash (a 28-byte number) Blockchains can have multiple deployments of the same codebase. For example: 1. Test networks where the base asset has no value (so devs can test at no cost) 1. Test networks where the protocol is simplified for ease of testing (ex: Cardano but with a Proof of Authority consensus for stable block production in testing) 1. Test networks for new features 1. Plutus Application Backend (PAB) testnet 2. Shelley incentivized testnet 1. Forks that diverge in feature set (the many forks of Bitcoin and Ethereum) dApps may be deployed on specific testnets that match their criteria and wallets need to know about these networks to know how to behave. Additionally, having a standardized registry for networks allows easy integration into the broader crypto ecosystem via standards like [CAIP-2](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-2.md) ## Specification We create a machine-readable registry of networks All entries in this registry should have the following entries: - User-friendly name - Network ID - Network magic - Genesis hash When representing these networks in a human-readable string, the following format shall be used: ``` cip34:NetworkId-NetworkMagic ``` # Rationale: how does this CIP achieve its goals? We pick this format for the following reason: - The network ID is too small to be used by itself. You can see from [chainlist](https://chainlist.org/) that 16 possibilities is too few - The genesis hash is too long and user-unfriendly to be used. ## Path to Active ### Acceptance Criteria - [ ] There are at least two (from different providers) wallets, libraries, CLI packages, or other tools which use this standard for network identification. ### Implementation Plan - [x] Develop and publish reference implementation: [CIP34-JS](https://www.npmjs.com/package/@dcspark/cip34-js) ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0034/registry.json ================================================ { "PreProduction": { "Name": "Pre-Production", "NetworkId": 0, "NetworkMagic": 1, "GenesisHash": "d4b8de7a11d929a323373cbab6c1a9bdc931beffff11db111cf9d57356ee1937" }, "Preview": { "Name": "Preview", "NetworkId": 0, "NetworkMagic": 2, "GenesisHash": "72593f260b66f26bef4fc50b38a8f24d3d3633ad2e854eaf73039eb9402706f1" }, "Mainnet": { "Name": "Mainnet", "NetworkId": 1, "NetworkMagic": 764824073, "GenesisHash": "5f20df933584822601f9e3f8c024eb5eb252fe8cefb24d1317dc3d432e940ebb" }, "LegacyTestnet": { "Name": "Legacy Testnet", "NetworkId": 0, "NetworkMagic": 1097911063, "GenesisHash": "96fceff972c2c06bd3bb5243c39215333be6d56aaf4823073dca31afe5038471" } } ================================================ FILE: CIP-0034/schema.json ================================================ { "definitions": { "network": { "$id": "#/definitions/network", "type": "object", "properties": { "Name": { "type": "string" }, "NetworkId": { "type": "integer", "minimum": 0, "exclusiveMaximum": 16 }, "NetworkMagic": { "type": "integer", "minimum": 0, "exclusiveMaximum": 4294967295 }, "GenesisHash": { "type": "string", "pattern": "^[0-9a-fA-F]+$", "minLength": 64, "maxLength": 64 } }, "required": [ "Name", "NetworkId", "NetworkMagic", "GenesisHash" ] } }, "type": "object", "additionalProperties": { "$ref": "#/definitions/network" } } ================================================ FILE: CIP-0035/README.md ================================================ --- CIP: 35 Title: Changes to Plutus Core Status: Active Category: Meta Authors: - Michael Peyton Jones Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/215 - https://github.com/cardano-foundation/CIPs/pull/428 - https://github.com/cardano-foundation/CIPs/pull/437 - https://github.com/cardano-foundation/CIPs/pull/484 Created: 2022-02-09 License: CC-BY-4.0 --- # Changes to Plutus Core ## Abstract This CIP specifies a process for proposing changes to Plutus Core, its builtins, and its interface to the Cardano ledger. It gives a taxonomy of typical changes, and explains how these changes may be made, which in some cases requires a CIP. It introduces the 'Plutus' CIP category for tracking these. ## Motivation: why is this CIP necessary? The Plutus Core language, its builtins, and its interface to the ledger are all likely to evolve significantly over time. There are many reasons for this: - We may be able to increase performance, improve safety, or reduce script sizes by changing the language. - We may be able to improve performance by providing builtin versions of expensive functions. - We may need to provide builtin versions of sensitive functions (e.g. cryptography) in order to ensure access to high-quality implementations. - We may find bugs in the implementation that need to be fixed. - We may need to change the interface to the ledger in order to represent changes in transaction formats. - We may wish to remove elements which have been deprecated due to the addition of improved versions. - … and more This CIP gives a taxonomy of changes, explains how such changes might be implemented in Cardano, and prescribes processes for proposing such changes. ## Background This CIP assumes general familiarity with Plutus Core and the Cardano ledger, but we give some brief background here. ### Plutus Core _Plutus Core_ is a script language used in the Cardano ledger. For the purposes of this document, Plutus Core consists of various _language constructs_, and also _builtin types and functions_. Plutus Core has a number of builtin types, such as integers, and builtin functions, such as integer addition. Builtin functions provide access to functionality that would be difficult or expensive to implement using the basic constructs of Plutus Core, which is otherwise little more than the untyped lambda calculus. Builtin functions can operate only over builtin types or arbitrary Plutus Core terms treated opaquely. Builtin types come with a _size metric_ which is used by costing functions. For example, the size metric for integers returns the bit-size of the integer. The performance of Plutus Core scripts has two components: how expensive the script actually is to run (_real performance_) and how expensive we say it is to run in the ledger (_model performance_). Model performance is calculated by costing _evaluation_ in abstract resource units ("exunits") of CPU and memory. Individual steps of evaluation are costed, and builtin functions must also come with a _costing function_ that provides costing information for them. The costing function for a builtin function is a mathematical function which takes the sizes of the arguments (as computed by their size metrics), and returns an estimate of the budget that will be used to perform that function. For example, the costing function for addition says that the CPU and memory costs are both proportional to the maximum of the sizes of the input integers (with some appropriate constants). Determining costing functions is done empirically, by running the function in question against a large number of inputs and choosing a costing function that fits the data well. Plutus Core has a _language version_ (LV). This is the version of the Plutus Core programming language itself, and it controls e.g. which constructs are available in the language. Changing any of the features which are guarded by the language version requires a new language version to be supported by the chain. Note that changing the set of builtin types or functions does _not_ require a new language version; any individual Plutus Core language version is compatible with any set of builtin types and functions. Depending on the type of change, a major or minor bump to the language version may be required. The following table shows typical examples. | Change | Type | Notes | |-------------------------------------------------------|-------|---------------------------| | Adding a construct to the language | Minor | Backwards-compatible. | | Removing a construct from the language | Major | Not backwards-compatible. | | Changing the behaviour of a construct in the language | Major | Not backwards-compatible. | | Changing the binary format of the language in a backwards-compatible way | Minor | Safe even if it makes previously non-deserializable scripts deserializable.[^backwards-safe] | | Changing the binary format of the language | Major | Not backwards-compatible. | [^backwards-safe]: See "Are backwards-compatible binary format changes really safe?". Since we always need a new Plutus Core langauge version for any change to the language, in the rest of this document we will focus on the introduction of a new langauge version as the proxy for changes to the language. ### Scripts in the Cardano ledger The Cardano ledger recognizes various kinds of _scripts_ identified by _language_. This language tag is the only way that the ledger has to distinguish between different types of script. Hence if we require different behaviour, we need a new language. We refer to these languages as _ledger languages_ (LLs). Part of the specification of a language in the ledger is how scripts of that language are run, what arguments they are passed, how those arguments are structured, etc. We refer to this as the _ledger-script interface_. Because we want to occasionally change e.g. the ledger-script interface for Plutus Core scripts, this means we need several ledger languages which all run scripts written in Plutus Core.[^ledger-language-versions] All Plutus Core ledger languages which are used in the ledger must be supported forever, in order to be able to validate the history of the chain. [^ledger-language-versions]: The Plutus Core family of ledger languages are sometimes referred to as the Plutus Core _ledger language versions_, and named as such ("PlutusV1", "PlutusV2" etc.) although they actually entirely distinct _languages_ from the perspective of the ledger. In this document we will use the more precise language and refer to them just as distinct ledger languages. Ledger languages also have an associated subset of the _protocol parameters_. These parameters provide the ability to control some aspects of evaluation without a software update. The most notable example is a set of parameters which parameterize the costing of program execution. Hence, a different Plutus Core ledger language can have a different set of costing protocol parameters. We can change the behaviour of ledger languages in a backwards compatible way with new protocol versions. This ensures that the new behaviour only becomes available at a particular time in the history of the chain. Overall the combination of ledger language and protocol version controls: - The protocol parameters which are available - The ledger-script interface - The Plutus Core language versions that are available - The set of builtin types and values that are available ### Types of change This document considers the following types of change: 1. The Plutus Core language 1. Adding a new Plutus Core language version 2. The Plutus Core builtin functions and types 1. Adding a new builtin function or type 2. Removing a builtin function or type 3. Changing the behaviour of a builtin function or type 3. The ledger-script interface 1. Changing the interface between the ledger and the interpreter 4. Protocol parameters 1. Improving model performance (i.e. changing the costing parameters so that scripts use less budget) 2. Regressing model performance (i.e. changing the costing parameters so that scripts use more budget) 3. Adding costing parameters 4. Removing costing parameters 5. Performance of the Plutus Core interpreter 1. Improving real performance 2. Regressing real performance ### Types of release Changes to Plutus Core can be released onto Cardano in four ways, with ascending levels of difficulty: 1. A _protocol parameter_ change (PP), taking effect as soon as the new parameters are accepted (in a new epoch). 2. A _software update_ (SU) to the node, taking effect when nodes upgrade. 3. A _hard fork_ (HF) (accompanied by a software update), requiring a software update for the new protocol version, and taking effect after the hard fork. 4. A new Plutus Core _ledger language_ (LL), introduced in a hard fork, and taking effect for scripts that use the new language, but not for those that use the old language. Intuitively, these correspond to how _compatible_ the change is. - A backwards- and forwards-compatible change can be deployed with a software update, as nobody can perceive the difference. - A backwards-compatible (but not forwards-compatible) change must be deployed in a hard fork, since it makes more blocks acceptable than before. - A backwards-incompatible change requires a new Plutus Core ledger language, so that the ledger can distinguish them, and maintain the old behaviour for old scripts. The following table lists, for each type of change in "Types of change", what kind of release it requires. | Change | Release | Notes | |----------------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------| | Adding a new Plutus Core language version | HF | Backwards-compatible since the new behaviour is guarded by the new LV. | | Adding a new builtin function or type | HF (rarely LL[^binary-backwards]) | Backwards-compatible. Requires a binary format change. | | Removing a builtin function or type | LL | This will cause scripts which use this builtin to be rejected, so is not backwards compatible. | | Changing the behaviour of a builtin function or type | LL | This changes the behaviour of existing scripts, so is not backwards compatible. | | Changing the interface between the ledger and the interpreter | LL | The ledger must provide scripts with exactly the right interface. New interface means new language. | | Improving model performance | PP | _Must_ strictly follow an improvement in real performance.[^why-perf-1] | | Regressing model performance | PP | | | Adding cost model parameters | HF | All nodes must recognize the new parameter. | | Removing cost model parameters | LL | Old scripts will require all the old parameters. | | Improving real performance | SU | | | Regressing real performance | SU | _Must_ strictly follow a regression in model performance.[^why-perf-2] | [^binary-backwards]: The binary format change is backwards compatible unless it breaches the limit of how many builtin functions or types can be encoded, in which case that must be changed, forcing a new LL. [^why-perf-1]: See "Why do performance changes require extra steps?". [^why-perf-2]: See "Why do performance changes require extra steps?". ## Specification ### Scope This CIP deals with the types of change listed in "Types of change". That list aims to cover the most typical changes to Plutus Core, but it is not exhaustive. CIPs which do not propose changes in the list but whose authors believe they significantly affect Plutus Core should nonetheless be assigned to the Plutus category. Additionally, there is significant overlap with the Ledger category around the ledger-script interface and the protocol parameters. CIPs which change these parts of Cardano should generally use the Plutus category and not the Ledger category, although the Editors may ask the Ledger reviewers to comment. ### The Plutus reviewers The following table gives the current set of reviewers for Plutus CIPs. | Name | Email | GitHub username | |----------------------|------------------------------|-----------------| | Ziyang Liu | ziyang.liu@iohk.io | zliu41 | ### Changes that require a CIP This proposal requires that some of the changes listed in "Types of change" (specified below) should: 1. Be proposed in a CIP. 2. Go through additional process in addition to the [usual CIP process](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md). The additional process mostly takes the form of additional information that should be present in the CIP before it moves to particular stages. The requirement to propose a change via a CIP is, as all CIPs are, advisory. In exceptional circumstances or where swift action is required, we expect that changes may still be made without following this process. In such circumstances, a retrospective CIP SHOULD be made after the fact to record the changes and the rationale for them. Changes that require a CIP do not have to each be in an individual CIP, they can be included in batches or in other CIPs. So, for example, a single CIP could propose multiple new builtin functions, or a CIP proposing a change to the ledger could also propose a change to the ledger-script interface. ### Processes All changes that require a CIP SHOULD adhere to the following generic process. In order to move to Proposed status: - The Specification MUST include: - The type of change that is being proposed. - For changes to Plutus Core itself, a formal specification of the changes which is precise enough to update the Plutus Core specification from. - The Acceptance Criteria MUST include: - The external implementations are available. - The `plutus` repository is updated with the specification of the proposal. - The `plutus` repository is updated with an implementation of the proposal. - The Implementation Plan MUST include: - The type of release that the change requires. #### Additions to the Plutus Core Builtins Proposals for additions to the set of Plutus Core builtins SHOULD be proposed in a CIP and SHOULD adhere to the following additional process. In order to move to Proposed status: - The Specification MUST include: - Names and types/kinds for the new functions or types. - A source for the implementation (e.g. a library which can be linked against); or a generic description of the functionality which is implementable in any programming language. - For new builtin types: a rough description of how the size of a value of that type can be measured. - For new builtin functions: a description of their time and space complexity. - The Rationale MUST include: - If an external implementation is provided: an argument that it satisfies the following non-exhaustive list of criteria: - It is trustworthy - It always terminates - It (or its Haskell bindings) never throw any exceptions - Its behaviour is predictable (e.g. does not have worst-case behaviour with much worse performance) - Discussion of how any measures and costing functions were determined. - The Acceptance Criteria MUST include: - The ledger is updated to include new protocol parameters to control costing of the new builtins. The Rationale of a CIP should always be a clear argument for why the CIP should be adopted. In this case we recommend including: - An argument for the utility of the new builtins. - Examples of real-world use cases where the new additions would be useful. - If feasible, a comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance). #### Protocol parameter updates Protocol parameter updates that affect Plutus Core should be proposed in the Ledger category and following its processes. The only additional process required is review by the Plutus reviewers. #### Performance changes This CIP does not require any process for proposing performance changes. #### Bug fixes A "bug fix" is a change to behaviour where: - The implemented behaviour does not match the specification; or - The specified behaviour is clearly wrong (in the judgement of relevant experts) In this case the fix may be submitted directly to the `plutus` repository and is NOT required to go through the CIP process. It must still be released as appropriate. For example, if a bug fix changes behaviour, it will have to wait for a new Plutus Core ledger language. #### Other changes Proposals for other additions, removals, or changes to behaviour of any part of Plutus Core or its builtins SHOULD be proposed in a CIP. ## Rationale: how does this CIP achieve its goals? ### Do removals and changes really need a new ledger language? Not being able to make removals or changes to behaviour without a LL is quite painful. For example, it means that we cannot just fix bugs in the semantics: we must remain bug-for-bug compatible with any given LL. It is tempting to think that if we can show that a particular behaviour has never been used in the history of the chain, then changing it is backwards-compatible, since it won’t change the validation of any of the actual chain. However, this is sadly untrue. 1. The behaviour could be triggered (potentially deliberately) in the interval between the update proposal being accepted and it being implemented. This is extremely dangerous and could lead to an un-managed hard fork. 2. The behaviour could be triggered in a script which has not yet been executed on the chain, but whose hash is used to lock an output. This could lead to that output being unexpectedly un-spendable, or some other change in behaviour. Moreover, since we only have the hash of the script, we have no way of telling whether this is the case. So even if a behaviour is obscure, we cannot just change it. ### Are backwards-compatible binary format changes really safe? Changing the binary format in a backwards compatible way may mean that binary scripts which previously would have been invalid might now deserialize correctly into a program. There is a worry here: scripts which fail execution (a phase 2 validation failure) actually get posted on the chain as failures. We must be careful not to turn any such failures into successes, otherwise we could break history. However, we do not need to worry in this case, since checking that a script deserializes properly is a phase 1 validation check, so no scripts will be posted as failures due to failing to deserialize, so we cannot break any such postings by making deserialization more lenient. ### Why do performance changes require extra steps? Performance changes must be carefully managed in order to avoid the possibility of an accidental hard fork. Consider an example of improving performance. The interpreter gets 50% faster (real performance), which is released as a software update. Now, we want to lower the cost model parameters (model performance) so that users will be charged fewer resources for their scripts. However, the parameter change means that scripts which previously would have exceeded the transaction/block limit become acceptable. The parameter change is not itself a hard fork, because all the nodes accept the new parameters by consensus. But if the model performance tracks real performance well, then nodes which have not adopted the software update may have issues with the real performance of these newly allowed scripts! In the worst case, they might suffer resource exhaustion, preventing them from following the new chain, which is tantamount to a hard fork. This is a relatively unlikely scenario, since it requires a situation where nodes are close enough to their resource limits that an (effective) regression in real performance of scripts can push them over the edge. Nonetheless, the cautious approach is to not perform such parameter updates until we are sure that all nodes are using a version with the required software update, i.e. after the protocol version has been bumped in a hard fork. Conversely, if (for some reason) we needed to regress the real performance of the interpreter, we should only do this after all the nodes have accepted a regression in model performance (increasing the cost model parameters). ### Why are we concerned about the implementations of builtins being trustworthy? Builtin functions in Plutus Core are implemented via Haskell functions. Often these implementations come from somewhere else, e.g. a cryptography library written in C. It is vitally important that these libraries are trustworthy. The Plutus Core package (and hence its dependencies) are linked into the Cardano node. A buffer overrun vulnerability in the implementation of a builtin function could therefore become an attack on a node. ### Why is the process for new builtins so much more structured? We expect additions to builtins to be particularly common, and to have lots of interest from the community. However, the process of adding new builtins is not totally straightforward, due in particular to the need to find a good implementation and to cost it. Surfacing these difficulties quickly is a key goal of this process. Finally, builtins are a comparatively structured extension point for the language. In comparison, proposals for changes to Plutus Core itself are likely to be much more heterogeneous. ### Why are we reluctant to release new ledger language? Ledger languages incur a large maintenance cost. Each one must continue to work, perfectly, in perpetuity. Furthermore, they may need their own, independent set of cost model protocol parameters, etc. So it is very desirable to keep the number of ledger languages down. The simplest way to do this is to batch changes, and only release a new ledger language occasionally. ## Path to Active ### Acceptance Criteria This CIP requires the acceptance of the Plutus team, which it has in virtue of its authorship. ### Implementation Plan No implementation is required. ## Copyright This CIP is licensed under [CC-BY-4.0][]. [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode ================================================ FILE: CIP-0036/README.md ================================================ --- CIP: 36 Title: Catalyst Registration Transaction Metadata Format (Updated) Category: Tools Status: Proposed Authors: - Giacomo Pasini - Kevin Hammond - Mark Stopka Implementors: - cardano-signer Discussions: - https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038 - https://github.com/cardano-foundation/CIPs/pull/188 - https://github.com/cardano-foundation/CIPs/pull/349 - https://github.com/cardano-foundation/CIPs/pull/373 Created: 2021-12-06 License: CC-BY-4.0 --- ## Abstract Cardano uses a sidechain for its treasury system. One needs to "register" to participate on this sidechain by submitting a registration transaction on the mainnet chain. This CIP details the registration transaction format. This is a revised version of the original [CIP-15 | Registration Transaction Metadata Format](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015). ## Motivation: why is this CIP necessary? Cardano uses a sidechain for its treasury system ("Catalyst") and for other voting purposes. One of the desirable properties of this sidechain is that even if its safety is compromised, it doesn't cause loss of funds on the main Cardano chain. To achieve this, instead of using your wallet's recovery phrase on the sidechain, we need to use a brand new "voting key". However, since 1 ADA = 1 vote, a user needs to associate their mainnet ADA to their new voting key. This can be achieved through a registration transaction. In addition, to encourage participation by a broader range of ADA holders, it should be possible to delegate one's rights to vote to (possibly multiple) representatives and/or expert voters. Such delegations will still be able to receive Catalyst rewards. We therefore need a registration transaction that serves three purposes: 1. Registers a "voting key" to be included in the sidechain and/or delegates to existing "voting key"s 2. Associates mainnet ADA to this voting key(s) 3. Declares a payment address to receive Catalyst rewards **Note**: This schema does not attempt to differentiate delegations from direct registrations, as the two options have exactly the same format. It also does not distinguish between delegations that are made as "private" arrangements (proxy votes) from those that are made by delegating to representatives who promote themselves publicly. Distinguishing these possibilities is left to upper layers or future revisions of this standard, if required. In this document, we will use the term 'delegations' to refer to all these possibilities. ## Specification ### Registration metadata format A registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it. Notably, there should be five entries inside the metadata map: - A non-empty array of delegations, as described below; - A stake address for the network that this transaction is submitted to (to point to the Ada that is being delegated); - A Shelley payment address (see [CIP-0019](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)) discriminated for the same network this transaction is submitted to, to receive rewards. - A nonce that identifies that most recent delegation - A non-negative integer that indicates the purpose of the vote. This is an optional field to allow for compatibility with CIP-15. For now, we define 0 as the value to use for Catalyst, and leave others for future use. A new registration should not invalidate a previous one with a different voting purpose value. ### Delegation format A delegation assigns (a portion of) the ADA controlled by one or more UTxOs on mainnet to the voting key in the sidechain as voting power. The UTxOs can be identified via the stake address at some designated point in time. Each delegation therefore contains: - a voting key: simply an ED25519 public key. This is the spending credential in the sidechain that will receive voting power from this delegation. For direct voting it's necessary to have the corresponding private key to cast votes in the sidechain. How this key is created is up to the wallet. - the weight that is associated with this key: this is a 4-byte unsigned integer (CBOR major type 0, The weight may range from 0 to 2^32-1) that represents the relative weight of this delegation over the total weight of all delegations in the same registration transaction. ### Voting key The terms "(CIP-36) voting keys" and "(CIP-36) vote keys" should be used interchangeably to indicate the keys described in this specification. But it should be made clear that implementations should favour the term "(CIP-36) vote key" and that the association of both terms aims to reduce the possibility of confusion. The term governance should not be associated with these keys nor should these keys be associated with other vote or voting keys used in the ecosystem. When discussing these keys in a wider context they should be specified by such terminology as "CIP-36 vote keys" or "CIP-36 style vote keys". #### Derivation path To avoid linking voting keys directly with Cardano spending keys, the voting key derivation path must start with a specific segment: `m / 1694' / 1815' / account' / chain / address_index` We recommend that implementors only use `address_index=0` to avoid the need for voting key discovery. #### Tooling Supporting tooling should clearly define and differentiate this as a unique key type, describing such keys as "CIP-36 vote keys". When utilizing Bech32 encoding the appropriate `cvote_sk` and `cvote_vk` prefixes should be used as described in [CIP-05](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005). Examples of acceptable `keyType`s for supporting tools: | `keyType` | Description | | --------- | ----------- | | `CIP36VoteSigningKey_ed25519` | Catalyst Vote Signing Key | | `CIP36VoteExtendedSigningKey_ed25519` | Catalyst Vote Signing Key | | `CIP36VoteVerificationKey_ed25519` | Catalyst Vote Verification Key | | `CIP36VoteExtendedVerificationKey_ed25519` | Catalyst Vote Verification Key | For hardware implementations: | `keyType` | Description | | --------- | ----------- | | `CIP36VoteVerificationKey_ed25519` | Hardware Catalyst Vote Verification Key | | `CIP36VoteHWSigningFile_ed25519` | Hardware Catalyst Vote Signing File | The intention with this design is that if projects beyond Catalyst implement this specification they are able to add to themselves `keyType` **Description**s. ### Example - Registration #### Voting registration example: ``` 61284: { // delegations - CBOR byte array 1: [["0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663", 1], ["0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee", 3]], // stake_pub - CBOR byte array 2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee", // payment_address - CBOR byte array 3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4", // nonce 4: 5479467 // voting_purpose: 0 = Catalyst 5: 0 } ``` The entries under keys 1, 2, 3, 4 and 5 represent the Catalyst delegation array, the staking credential on the Cardano network, the payment address to receive rewards, a nonce, and a voting purpose, respectively. A registration with these metadata will be considered valid if the following conditions hold: - The nonce is an unsigned integer (of CBOR major type 0) that should be monotonically rising across all transactions with the same staking key. The advised way to construct a nonce is to use the current slot number. This is a simple way to keep the nonce increasing without having to access the previous transaction data. - The payment address is a Shelley payment address discriminated for the same network this transaction is submitted to. - The delegation array is not empty - The weights in the delegation array are not all zero Delegation to the voting key `0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663` will have relative weight 1 and delegation to the voting key `0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee` relative weight 3 (for a total weight of 4). Such a registration will assign 1/4 and 3/4 of the value in ADA to those keys respectively, with any remainder assigned to the second key. The registration witness depends on the type of stake credential used. To produce the witness field in case of a staking public key, the CBOR representation of a map containing a single entry with key 61284 and the registration metadata map in the format above is formed, designated here as `sign_data`. This data is signed with the staking key as follows: first, the blake2b-256 hash of `sign_data` is obtained. This hash is then signed using the Ed25519 signature algorithm. The witness metadata entry is added to the transaction under key 61285 as a CBOR map with a single entry that consists of the integer key 1 and signature as obtained above as the byte array value. #### Witness example: ``` 61285: { // witness - ED25119 signature CBOR byte array 1: "0x8b508822ac89bacb1f9c3a3ef0dc62fd72a0bd3849e2381b17272b68a8f52ea8240dcc855f2264db29a8512bfcd522ab69b982cb011e5f43d0154e72f505f007" } ``` ### Deregistration metadata format (Catalyst) This deregistration format is currently only specified for Catalyst (vote_purpose=0), other voting chain purposes may handle a deregistration in a different way. There was a discussion before if an empty delegation array could also be used to fulfil a deregistration. This idea was cancelled, because it would currently require additional resources in the Hardware-Wallets state machine to do additional checks about an empty array. So the decision was made to leave the registration part untouched and only add the deregistration via the unused key 61286. Wallets/Tools are not forced to support this deregistration method. Definition: - A deregistration removes all the voting power (associated stake amount) for the provided stake credential from the delegated vote-public-keys. - A deregistration resets the state of the stake credential on the voting chain like they were never registered before. - A deregistration transaction is a regular Cardano transaction with a specific transaction metadata associated with it. Notably, there should be three entries inside the metadata map (key 61286): - The public key of the stake signing key - A nonce that identifies that most recent deregistration. - A non-negative integer that indicates the purpose of the vote. For now, we define 0 as the value to use for Catalyst, and leave others for future use. Be aware, the deregistration metadata key is 61286, and not 61284 like it is used for a registration! The registraton metadata format and specification is independent from the deregistration one, and may not be supported by all wallets/tools. #### Example - Deregistration (Catalyst) ``` { 61286: { // stake_pub - CBOR byte array 1: "0x57758911253f6b31df2a87c10eb08a2c9b8450768cb8dd0d378d93f7c2e220f0", // nonce 2: 74412400, // voting_purpose: 0 = Catalyst 3: 0 }, 61285: { // witness - ED25119 signature CBOR byte array 1: "0xadb7c90955c348e432545276798478f02ee7c2be61fd44d22f9de22131d9bcf0b23eb413766b74b9e7ba740e71266467a5d35363411346972db9e7b710b00603" } } ``` CBOR-Hex: `A219EF66A301582057758911253F6B31DF2A87C10EB08A2C9B8450768CB8DD0D378D93F7C2E220F0021A046F7170030019EF65A1015840ADB7C90955C348E432545276798478F02EE7C2BE61FD44D22F9DE22131D9BCF0B23EB413766B74B9E7BA740E71266467A5D35363411346972DB9E7B710B00603` The entries under keys 1, 2 and 3 represent the staking credential on the Cardano network, a nonce, and a voting purpose, respectively. A deregistration with these metadata will be considered valid if the following conditions hold: - The stake credentials is a stake public-key byte array (of CBOR major type 2) - The nonce is an unsigned integer (of CBOR major type 0) that should be monotonically rising across all transactions with the same staking key. The advised way to construct a nonce is to use the current slot number. This is a simple way to keep the nonce increasing without having to access the previous transaction data. - The voting_purpose is an unsigned integer (of CBOR major type 0) To produce the witness field in case of a staking public key, the CBOR representation of a map containing a single entry with key 61286 and the deregistration metadata map in the format above is formed, designated here as `sign_data`. This data is signed with the staking key as follows: first, the blake2b-256 hash of `sign_data` is obtained. This hash is then signed using the Ed25519 signature algorithm. The witness metadata entry is added to the transaction under key 61285 as a CBOR map with a single entry that consists of the integer key 1 and signature as obtained above as the byte array value. ### Metadata schema See the [schema file](./schema.cddl). ### Test vector See [test vector file](./test-vector.md). ## Rationale: how does this CIP achieve its goals? ### Associating voting power with a voting key This method has been used since Fund 2. For future fund iterations, a new method making use of time-lock scripts may be introduced as described [below][future-development]. Recall: Cardano uses the UTXO model so to completely associate a wallet's balance with a voting key (i.e. including enterprise addresses), we would need to associate every payment key to a voting key individually. Although there are attempts at this (see [CIP-0008]), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small) Given the above, we choose to associate staking credentials with voting keys. At the moment, the only supported staking credential is a staking key. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet. The voting power that is associated with each delegated voting key is derived from the user's total voting power as follows. 1. The total weight is calculated as a sum of all the weights; 2. The user's total voting power is calculated as a whole number of ADA (rounded down); 3. The voting power associated with each voting key in the delegation array is calculated as the weighted fraction of the total voting power (rounded down); 4. Any remaining voting power is assigned to the last voting key in the delegation array. This ensures that the voter's total voting power is never accidentally reduced through poor choices of weights, and that all voting powers are exact ADA. ### Future development [future-development]: #future-development A future change of the Catalyst system may make use of a time-lock script to commit ADA on the mainnet for the duration of a voting period. The voter registration metadata in this method will not need an association with a staking credential. Therefore, the `staking_credential` map entry and the `registration_witness` payload with key 61285 will no longer be required. ### Changelog Fund 3 added the `reward_address` inside the `key_registration` field. Fund 4: - added the `nonce` field to prevent replay attacks; - changed the signature algorithm from one that signed `sign_data` directly to signing the Blake2b hash of `sign_data` to accommodate memory-constrained hardware wallet devices. It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated. This has been deferred to a future revision of the protocol. Fund 8: - renamed the `voting_key` field to `delegations` and add support for splitting voting power across multiple vote keys. - added the `voting_purpose` field to limit the scope of the delegations. - rename the `staking_pub_key` field to `stake_credential` and `registration_signature` to `registration_witness` to allow for future credentials additions. Fund 10: - Replaced the `reward_address` field with `payment_address` field, keeping it at index 3. Stipulating that `payment_address` must be a Shelley payment address, otherwise voting reward payments will not be received. - **Note:** up to Catalyst's Fund 9, voting rewards were paid via MIR transfer to a stake address provided within the `reward_address` field. From Fund 10 onwards, a regular payment address must be provided in the `payment_address` field to receive voting rewards. This allows Catalyst to avoid MIR transfers and instead pay voting rewards via regular transactions. Fund 11: - added the `deregistration` metadata format. ## Path to Active ### Acceptance Criteria - [ ] Have this registration format supported in Catalyst infrastructure for two Catalyst funds. - [ ] Have this registration format supported by three wallets/tools. - [cardano-signer](https://github.com/gitmachtl/cardano-signer) ### Implementation Plan - [x] Authors to provide test vector file. - See the [schema file](./schema.cddl). - [x] Authors to provide CDDL schema file. - See [test vector file](./test-vector.md). - [x] Authors to test this format for security and compatibility with existing Catalyst infrastructure. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0036/schema.cddl ================================================ registration_cbor = { 61284: key_registration, 61285: registration_witness } $cip36_vote_pub_key /= bytes .size 32 $payment_address /= bytes $nonce /= uint $weight /= uint .size 4 $voting_purpose /= uint legacy_key_registration = $cip36_vote_pub_key delegation = [$cip36_vote_pub_key, $weight] ; May support other stake credentials in the future. ; Such additional credentials should be tagged at the CDDL/CBOR level ; so that parsing is not ambiguous and future proof. ; However, to avoid breaking changes, the simple key credential is ; left untagged. $stake_credential /= $staking_pub_key $stake_witness /= $ed25519_signature ; A stake key credential, not tagged for backward compatibility $staking_pub_key /= bytes .size 32 ; Witness for a stake key credential, not tagged for backward compatibility $ed25519_signature /= bytes .size 64 key_registration = { 1 : [+delegation] / legacy_key_registration, 2 : $stake_credential, 3 : $payment_address, 4 : $nonce, ? 5 : $voting_purpose .default 0 } registration_witness = { 1 : $stake_witness } deregistration_cbor = { 61286: key_deregistration, 61285: deregistration_witness } key_deregistration = { 1 : $stake_credential, 2 : $nonce, ? 3 : $voting_purpose .default 0 } deregistration_witness = { 1 : $stake_witness } ================================================ FILE: CIP-0036/test-vector.md ================================================ # Test Vector for CIP-0036 ## Keys **Note:** Not all keys are required for certificate recreation. Payment **private** signing key Hex: ``` 614fdfe13d403bee2014570b190d81851f17d8daca0b6dd1ce33014403191003 ``` Payment **public** verification Hex: ``` 7a24dd8e692cec94b612c2ec81f508aada96557c2052a447b9d197b006fa7d2a ``` Staking **private** signing key Hex: ``` 852fa5d17df3efdfdcd6dac53ec9fe5593f3c0bd7cadb3c2af76c7e15dfa8a5c ``` Staking **public** verification key Hex: ``` e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369 ``` CIP-36 Vote **public** verification key Hex: ``` 0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0 ``` CIP-36 Vote **extended private** signing key Hex: ``` 4820f7ce221e177c8eae2b2ee5c1f1581a0d88ca5c14329d8f2389e77a465655c27662621bfb99cb9445bf8114cc2a630afd2dd53bc88c08c5f2aed8e9c7cb89 ``` ## Addresses - This example uses Pre-Production testnet (testnet-magic 1). Payment Address: ``` bech32: "addr_test1qprhw4s70k0vzyhvxp6h97hvrtlkrlcvlmtgmaxdtjz87xrjkctk27ypuv9dzlzxusqse89naweygpjn5dxnygvus05sdq9h07" hex-encoded: "004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9" ```` Staking Address: ``` bech32: "stake_test1upetv9m90zq7xzk303rwgqgvnje7hvjyqef6xnfjyxwg86gzpmj80" hex-encoded: "e072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9" ``` ## Certificate Example - Assigning all voting power to a single voting key. ### Human Readable Format Legacy CIP-15 version: ```javascript "61284": { "1": "0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", "3": "0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", "4": 1234 } ``` CIP-36 version: ```javascript "61284": { "1": [["0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", 1]], "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", "3": "0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", "4": 1234, "5": 0 } ``` ### CBOR Encoding Legacy CIP-15 version: ``` a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e43236903581de072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d2 ``` CIP-36 version: ``` a119ef64a501818258200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a001025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369035839004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d20500 ``` ### Blake2b-256 Hash Legacy CIP-15 version: ``` 9946e71b5f6c16150cf431910a0f7dbb8084a992577847802e60d32becb3d6be ``` CIP-36 version: ``` 3110fbad72589a80de7fc174310e92dac35bbfece1690c2dce53c2235a9776fa ``` ## Metadata Example with Witness Legacy CIP-15 version: ```javascript { "61284": { "1": "0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", "3": "0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", "4": 1234 }, "61285": { "1": "0xa9ec8735804c6c4c5c4a02e9589c65508ec7060063b2d7dbeba82d1cbfa1b8be6b457f95d4ead5e8b454b989624fa44e0b89a64d089fdc0a6a1268fef4876d0f" } } ``` CIP-36 version: ```javascript { "61284": { "1": [["0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", 1]], "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", "3": "0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", "4": 1234, "5": 0 }, "61285": { "1": "0xcbb96ba1596fafc18eec84e306feea3067ba1c6ace95b11af820bcbd53837ef32bdcf28176749061e1f2a1300d4df98c80582722786e40cf330072d0b78a7408" } } ``` ================================================ FILE: CIP-0037/README.md ================================================ --- CIP: 37 Title: Dynamic Saturation Based on Pledge Status: Proposed Category: Ledger Authors: - Casey Gibson Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/163 Created: 2021-12-03 License: CC-BY-4.0 --- ## Abstract The pledge should be used to calculate the saturation point of a pool: setting a maximum delegation proportional to pledge. ## Motivation: why is this CIP necessary? Currently Cardano has been plagued with an ever increasing amount of single entity Stake Pool Operators (SPO) creating multiple pools. The pools that are known to be operated by single entity SPOs account for just 18.72% of the total stake and 50% of the total stake can be attributed to at least 23 single entities (as of 3rd Dec 2021). The vision of Cardano is that it everyone should be able to have the opportunity to be able to run a stake pool regardless of their financial capabilities and this is even more important for developing countries. The issue we're currently facing is that many SPOs have been able to exploit a loophole that has allowed them to use their influence to create many sub-pools without any restrictions. As the size of their pools grow, instead of honouring the saturation limits already in place, they are bypassing them by creating more sub-pools. From a technical point, it is theoretically possible for a single entity to run enough stake pools to control more then 50% of the total stake. While unlikely, the system does not take into account external influences (eg. political) that could harm the system. Shelly has been active for less then 2 years and we are already seeing the risks on a small scale. As real world adoption continues, there could be situations in the next decade that could jeopardise the decentralisation of Cardano. One example could be that a political party could run a ISPO (Initial Stake Pool Offering) on a mass scale. Seeing as Cardano has the potential to be used for voting (even at a political level), the integrity of Cardano could be questioned if political parties controlled stake pools with large shares of total stake. The pledge used in a pool was meant to show how serious a SPO is and how much "skin in the game" they had. The idea was that if they have more pledge, they have more to lose if something goes wrong. This seems to have lost it's meaning as SPOs that already have a dominating position have created many sub-pools. Some have split up their pledge evenly, some have next to no pledge and have gained high amounts of stake through influential means. This has not only reduced the security of Cardano, but has also lost the meaning of having pledge in the pool. For example, a SPO might have a pledge of 30,000 ADA across 10 pools, while another SPO might have 1,000,000 pledge but only has 1 pool with a small amount of active stake. Seeing as the SPO with 1M pledge has more overall, they have more to lose and should be trusted more. Since there is no technical advantage to having a high pledge, the meaning and purpose of a pledge is redundant. To make the pledge a meaningful metric that is fair to all SPOs and aligns with the core values of Cardano, the pledge should be used to calculate the saturation point of a pool. This will mean that SPOs, no matter how many pools they operate, will have a maximum saturation based on their total pledge. For example, if a pool operates a single pool and wanted to open up another pool with the same amount of stake, they will have to assign the equal amount of pledge against that new pool. If a pool wishes to up their saturation point, they will need to assign a higher amount of pledge. This proposal has had active discussions for over 6 months and is now waiting for a review from IOG to provide feedback on the feasibility and soundness of the approach. 1. This CIP should be considered a medium priority as it directly impacts the health and growth of the Cardano ecosystem. Large Cardano pools have had several years to take advantage of the lack of oversight and have control of a large portion of mining operations. This continued lack of restrictions will further damage the trust and reliability of the framework. 2. Timelines around the implementation of the CIP will depend on urgency, however its implementation should be trivial as there are no new parameters required or risks involved. Further this CIP from a high-level aspect only requires an update to the existing algorithm. From an external context, the CIP will require trivial updates as it should be self-contained in cardano-node. ## Specification For this to be able to work, there firstly needs to be an upper limit and a lower limit. The K parameter can still be used as the upper saturation limit of a single pool. As in, if a SPO has enough pledge assigned to a single pool, that pool will be able to run at the maximum saturation point of K. The lower limit is in place to safe guard small SPOs and allow them to grow. An example of how Dynamic Saturation would be calculated: 500,000 ADA Pledged = Saturation point at 100% of K 250,000 ADA Pledged = Saturation point at 50% of K 125,000 ADA Pledged = Saturation point at 25% of K 62,500 ADA Pledged = Saturation point at 12.5% of K To not penalise small pools, there should be a lower limit saturation point, such as 10% of K. Based on this, a pool with a pledge of 50,000 has the same saturation point as a pool with 25,000 pledge, both being 10% of K. This will allow smaller pools to still have some growth potential. The only way a pool can receive more stake across all their pools without impacting their rewards is to increase their total pledge. Example with SPO of 1,000,000 Pledge with current k implementation: | Pools | Pledge | Saturation Per Pool | Total Stake | Fees | |-------|-----------|---------------------|-------------|----------------------| | 1 | 1,000,000 | 100% of K | ~65M | 340 fee + margin | | 2 | 500,000 | 100% of K | ~130M | 340 fee + margin x2 | | 4 | 250,000 | 100% of K | ~260M | 340 fee + margin x4 | | 8 | 125,000 | 100% of K | ~520M | 340 fee + margin x8 | | 16 | 62,500 | 100% of K | ~1040M | 340 fee + margin x16 | Example with SPO of 1,000,000 Pledge with Dynamic Saturation: | Pools | Pledge | Saturation Per Pool | Total Stake | Fees | |-------|-----------|---------------------|-------------|----------------------| | 1 | 1,000,000 | 100% of K | ~65M | 340 fee + margin | | 2 | 500,000 | 100% of K | ~130M | 340 fee + margin x2 | | 4 | 250,000 | 50% of K | ~130M | 340 fee + margin x4 | | 8 | 125,000 | 25% of K | ~130M | 340 fee + margin x8 | | 16 | 62,500 | 12.5% of K | ~130M | 340 fee + margin x16 | As we can see above with the **current** implementation of K, a pool owner can split the pool and double their delegators active stake (or however many times they split). The Dynamic Saturation method caps the pools so that the amount of total stake across all pools is the same no matter how much they split up their pledge and the only benefit will be the extra fee collected (340 ADA) per pool. This will mean that the saturation metric will have a direct corelation to an SPOs total pledge. ### Proposals Based On Feedback After some discussions among the community and some help from https://github.com/cffls, the below code example has been proposed for how the dynamic saturation could work. ``` let lovelace = 1000000; function calc_sat(pledge){ k = 500; e = 0.2; l = 125; total_supply = 33719282563 * lovelace; orig_sat = total_supply / k; new_sat = orig_sat * Math.max(e, min(1 / k, pledge / orig_sat * l)); final_sat = max(new_sat, orig_sat); console.log(`pledge: ${pledge / lovelace}, sat: ${final_sat / lovelace}`); } function max(val1, val2){ if(val1 < val2){ return val1; } return val2; } function min(val1, val2){ if(val1 > val2){ return val1; } return val2; } calc_sat(50000 * lovelace); calc_sat(100000 * lovelace); calc_sat(150000 * lovelace); calc_sat(250000 * lovelace); calc_sat(500000 * lovelace); calc_sat(750000 * lovelace); calc_sat(1000000 * lovelace); calc_sat(2000000 * lovelace); ``` Results: ``` [Log] pledge: 50000, sat: 13487713.0252 [Log] pledge: 100000, sat: 13487713.0252 [Log] pledge: 150000, sat: 18750000 [Log] pledge: 250000, sat: 31250000 [Log] pledge: 500000, sat: 62500000 [Log] pledge: 750000, sat: 67438565.126 [Log] pledge: 1000000, sat: 67438565.126 [Log] pledge: 2000000, sat: 67438565.126 ``` ## Rationale: how does this CIP achieve its goals? Since a single entity SPO only has a certain amount of ADA they can pledge, they will eventually hit their saturation point no matter how many pools they create. The only way they can add more delegators is to increase their pledge. Once they run out of pledge and reach their saturation point, the delegators will have no choice but to move to another SPO and increase decentralisation. In the above example, the base pledge of 500,000 ADA should be set as a parameter that can be adjusted in the future. E.g, if it is found that it is too low or too high to gain 100% saturation, it can be adjusted in the same way k can be adjusted. One of the questions raised by the community was, will the lower limit stop the growth of small pools if it is set at a level where they can't reach the expected annual 5% return on ADA. This case could be handled a few ways, but the main aim would be to keep it at a sustainable amount for small pools. 1. The value is a percentage of k, such as 10%. This percentage could increase as needed, such as to 15% of k. 2. The value could be calculated based on the average of active stake compared to active pools. E.g, active stake = 23837 M / 3000 = saturation point of 7.94 M ADA ## Path To Active ### Acceptance Criteria - [ ] The new relationship between pledge and saturation defined here is implemented in the Ledger and enacted through a hard-fork. ### Implementation Plan - [ ] Agreement by the Ledger team as defined in [CIP-0084](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0084) under _Expectations for ledger CIPs_ including "expert opinion" on changes to rewards & incentives. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0040/README.md ================================================ --- CIP: 40 Title: Collateral Output Status: Active Category: Ledger Authors: - Sebastien Guillemot - Jared Corduan - Andre Knispel Implementors: N/A Discussions: - https://github.com/cardano-foundation/CIPs/pull/216 Created: 2022-02-10 License: CC-BY-4.0 --- ## Abstract This document describes adding a new output type to transactions called Collateral Outputs. ## Motivation: why is this CIP necessary? As of Alonzo, transactions that call Plutus smart contracts are required to put up collateral to cover the potential cost of smart contract execution failure. Inputs used as collateral have the following properties: 1. Cannot contain any tokens (only ADA) 2. Cannot be a script address 3. Must be a UTXO input 4. Must be at least some percentage of the fee in the tx (concrete percentage decided by a protocol parameter) 5. Can be the same UTXO entry as used in non-collateral tx input 6. Is consumed entirely (no change) if the contract execution fails during phase 2 validation 7. Is not consumed if phase phase 2 validation succeeds Additionally, there cannot be more than *maxColInputs* (protocol parameter) inputs and the inputs have to cover a percentage of the fee defined by *collateralPercent* (protocol parameter) However, - Restriction #1 is problematic because hardcore dApp users rarely have UTXO entries that do not contain any tokens. To combat this, wallets have created a special wallet-dependent "collateral" UTXO to reserve for usage of collateral for dApps which is not a great UX. - Restriction #6 is problematic because wallets want to protect users from signing transactions with large collateral as they cannot verify whether or not the transaction will fail when submitted (especially true for hardware wallets) ## Specification If phrase-2 verification fails, we can send outputs to a special output marked as the collateral output. There are two ways to create collateral outputs 1. Add collateral outputs as a new field inside the transaction. This change is similar to how collateral inputs were created a new field 2. Change the definition of outputs as `TxOut = Addr × Value × DataHash? × Source?` where source (optional for backwards compatibility) is an enum `0 = regular output, 1 = collateral output`. Option #1 provides the best backwards compatibility because we don't expect phase-2 validation to be a common occurrence and so wallets that (due to not being updated) never check collateral outputs will still in the overwhelming majority of cases return the correct result. Additionally, this requires updating the collateral requirement. If no collateral output is specified (and therefore no tokens are in the collateral input), then we keep the old definition ``` ubalance (collateral txb ◁ utxo) ≥ quot (txfee txb * (collateralPercent pp)) 100 ``` However, if collateral output is specified, then 1. Each collateral output needs to satisfy the same minimum ADA requirement as regular outputs 2. Collateral output needs to be balanced according to `sum(collateral_input) = sum(collateral_output) + collateral_consumed` Where `collateral_consumed` is equal to the old formula (`quot (txfee txb * (collateralPercent pp)) 100`). Note that when collateral is consumed, any certificate, etc. in the transaction is ignored so they have no impact on the change calculation. ## Rationale: how does this CIP achieve its goals? ### Self-contained balancing Some use-cases like hardware wallets, who do not have access to the content of the collateral inputs, cannot easily check if the collateral is balanced. Similar to how we specify an explicit fee as part of the transaction body to tackle this problem, the transaction body also needs a new field that explicitly specified how much collateral will be consumed in the case of phase-2 validation failure. ## Path to Active ### Acceptance Criteria - [x] Fully implemented in Cardano as of the Vasil protocol upgrade. ### Implementation Plan - [x] Passes all Ledger team requirements for desirability and feasibility. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0042/README.md ================================================ --- CIP: 42 Title: New Plutus Builtin serialiseData Status: Active Category: Plutus Authors: - Matthias Benkort - Sebastian Nagel Implementors: - Michael Peyton Jones Discussions: - https://github.com/cardano-foundation/CIPs/pull/218 Created: 2022-02-09 License: Apache-2.0 --- ## Abstract This document describes the addition of a new Plutus builtin for serialising `BuiltinData` to `BuiltinByteString`. ## Motivation: why is this CIP necessary? As part of developing on-chain script validators for [the Hydra Head protocol](https://eprint.iacr.org/2020/299), we stumble across a peculiar need for on-chain scripts: we need to verify and compare digests obtained from hashing elements of the script's surrounding transaction. In this particular context, those elements are transaction outputs (a.k.a. `TxOut`). While Plutus already provides built-in for hashing data-structure (e.g. `sha2_256 :: BuiltinByteString -> BuiltinByteString`), it does not provide generic ways of serialising some data type to `BuiltinByteString`. In an attempt to pursue our work, we have implemented [an on-chain library (plutus-cbor)][plutus-cbor] for encoding data-types as structured [CBOR / RFC 8949][CBOR] in a _relatively efficient_ way (although still quadratic, it is as efficient as it can be with Plutus' available built-ins) and measured the memory and CPU cost of encoding `TxOut` **in a script validator on-chain**. ![](https://i.imgur.com/AtHE0p4.png) The above graph shows the memory and CPU costs **relative against a baseline**, of encoding a `TxOut` using `plutus-cbor` in function of the number of assets present in that `TxOut`. The costs on the y-axis are relative to the maximum execution budgets (as per mainnet's parameters, December 2021) allowed for a single script execution. As can be seen, this is of linear complexity, i.e. O(n) in terms of the number of assets. These results can be reproduced using the [encoding-cost][] executable in our repository. > Note that we have also calculated similar costs for ada-only `TxOut`, in function of the number of `TxOut` which is about twice as worse but of similar linear shape. We we can see on the graph, the cost is manageable for a small number of assets (or equivalently, a small number of outputs) but rapidly becomes limiting. Ideally, we would prefer the transaction size to be the limiting factor when it comes to the number of outputs we can handle in a single validation. Besides, in our discussions with the Marlowe team, we also discovered that they shared a similar problem when it came to serialising merkleized ASTs. Underneath it all, it seems that it would be beneficial to have a new built-in at our disposal to serialise any Plutus `BuiltinData` to `BuiltinByteString` such that validators could leverage more optimized implementations and bytestring builders via built-ins than what's available on-chain, hopefully reducing the overall memory and CPU costs. ## Specification ### Function definition We define a new Plutus built-in function with the following type signature: ```hs serialiseData :: BuiltinData -> BuiltinByteString ``` ### Binary data format Behind the scene, we expect this function to use a well-known encoding format to ease construction of such serialisation off-chain (in particular, for non-Haskell off-chain contract codes). A natural choice of binary data format in this case is [CBOR][] which is: 1. Efficient; 2. Relatively simple; 3. Use pervasively across the Cardano ecosystem Furthermore, the Plutus' ecosystem already provides [a _quite opinionated_ implementation of a CBOR encoder][encodeData] for built-in `Data`. For the sake of documenting it as part of this proposal, we provide here-below the CDDL specification of that existing implementation: ```cddl plutus_data = constr / { * plutus_data => plutus_data } / [ * plutus_data ] / big_int / bounded_bytes constr = #6.121([]) / #6.122([a]) / #6.123([a, a]) / #6.124([a, a, a]) / #6.125([a, a, a, a]) / #6.126([a, a, a, a, a]) / #6.127([a, a, a, a, a, a]) ; similarly for tag range: #6.1280 .. #6.1400 inclusive / #6.102([uint, [* a]]) big_int = int / big_uint / big_nint big_uint = #6.2(bounded_bytes) big_nint = #6.3(bounded_bytes) bounded_bytes = bytes .size (0..64) ``` > NOTE: The CDDL specification is extracted from the wider [alonzo_cddl specification][] of the Cardano ledger. ### Cost Model The `Data` type is a recursive data-type, so costing it properly is a little tricky. The Plutus source code defines an instance of `ExMemoryUsage` for `Data` with [the following interesting note](https://github.com/input-output-hk/plutus/blob/37b28ae0dc702e3a66883bb33eaa5e1156ba4922/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/ExMemory.hs#L205-L225): > This accounts for the number of nodes in a `Data` object, and also the sizes of the contents of the nodes. This is not ideal, but it seems to be the best we can do. At present this only comes into play for 'equalsData', which is implemented using the derived implementation of '==' [...]. We propose to re-use this instance to define a cost model linear in the size of data defined by this instance. What remains is to find a proper coefficient and offset for that linear model. To do so, we can benchmark the execution costs of encoding arbitrarily generated `Data` of various sizes, and retro-fit the cost into a linear model (provided that the results are still attesting for that type of model). Benchmarking and costing `serialiseData` was done in [this PR](https://github.com/input-output-hk/plutus/pull/4480) according to this strategy. As the benchmark is not very uniform, because some cases of `Data` "structures" differ in CPU time taken to process, the linear model is used as an **upper bound** and thus conservatively overestimating actual costs. ## Rationale: how does this CIP achieve its goals? * Easy to implement as it reuses existing code of the Plutus codebase; * Such built-in is generic enough to also cover a wider set of use-cases, while nicely fitting ours; * Favoring manipulation of structured `Data` is an appealing alternative to many `ByteString` manipulation use-cases; * CBOR as encoding is a well-known and widely used standard in Cardano, existing tools can be used; * The hypothesis on the cost model here is that serialisation cost would be proportional to the `ExMemoryUsage` for `Data`; which means, given the current implementation, proportional to the number and total memory usage of nodes in the `Data` tree-like structure. * Benchmarking the costs of serialising `TxOut` values between [plutus-cbor][] and [cborg][] confirms [cborg][] and the existing [encodeData][]'s implementation in Plutus as a great candidate for implementing the built-in: ![](https://i.imgur.com/6GWrIHb.png) Results can be reproduced with the [plutus-cbor benchmark][]. ### Alternatives * We have identified that the cost mainly stems from concatenating bytestrings; so possibly, an alternative to this proposal could be a better way to concatenate (or to cost) bytestrings (Builders in Plutus?) * If costing for `BuiltinData` is unsatisfactory, maybe we want have only well-known input types, e.g. `TxIn`, `TxOut`, `Value` and so on.. `WellKnown t => t -> BuiltinByteString` ### Backward Compatibility * Additional built-in: so can be added to PlutusV1 and PlutusV2 without breaking any existing script validators. A hard-fork is however required as it would makes more blocks validate. ## Path To Active ### Acceptance Criteria - [x] Release it as a backward-compatible change within the Vasil protocol upgrade ### Implementation Plan - [x] Using the existing _sizing metric_ for `Data`, determine a costing function (using existing tooling / benchmarks? TBD) - [x] The Plutus team updates plutus to add the built-in to PlutusV1 and PlutusV2 and uses a suitable cost function - [x] The binary format of `Data` is documented and embraced as an interface within `plutus`. (see [cardano-ledger's CDDL specification](https://github.com/IntersectMBO/cardano-ledger/blob/faa40b812511bfb6592cdfbdd85fe560cbcaed43/eras/babbage/impl/cddl-files/babbage.cddl#L306-L311)) ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). [CBOR]: https://www.rfc-editor.org/rfc/rfc8949 [plutus-cbor]: https://github.com/input-output-hk/hydra-poc/tree/a4b843a040897e45120cb63b666d965759091651/plutus-cbor [cborg]: https://hackage.haskell.org/package/cborg-0.2.4.0 [encoding-cost]: https://github.com/input-output-hk/hydra-poc/tree/759fee84475f951aaf2f35acdb8ab82094ec5fbf/plutus-cbor/exe/encoding-cost/Main.hs [alonzo_cddl specification]: https://github.com/input-output-hk/cardano-ledger/blob/aebd64e015ec0825776c256faed9d8632712beb0/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L276-L296 [encodeData]: https://github.com/input-output-hk/plutus/blob/1f31e640e8a258185db01fa899da63f9018c0e85/plutus-core/plutus-core/src/PlutusCore/Data.hs#L108 [plutus-cbor benchmark]: https://github.com/input-output-hk/hydra-poc/tree/759fee84475f951aaf2f35acdb8ab82094ec5fbf/plutus-cbor/bench/Main.hs ================================================ FILE: CIP-0045/README.md ================================================ --- CIP: 45 Title: Decentralized WebRTC dApp-Wallet Communication Status: Active Category: Wallets Authors: - Fabian Bormann - Jaime Caso Implementors: - Fabian Bormann - Jaime Caso Discussions: - https://github.com/cardano-foundation/CIPs/pull/395 Created: 2022-11-29 License: CC-BY-4.0 --- ## Abstract We want to introduce a decentralized communication method between dApps and wallets based on WebTorrent trackers and WebRTC. This CIP also contains a proof of concept implementation injecting the wallet rpc methods into the dApps global window object similar to [CIP-0030](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030). ## Motivation In a decentralized ecosystem a communication between wallet-apps and dApps is still challanging. The inter-app communication on mobile devices does not directly allow remote procedure calls and is mostly restricted to Universal Links (iOS) or Deeplinks (Android). State-of-the-art solutions like WalletConnect tackle these problems using WebRTC communication which also works across devices, but requires a central signaling server to estalblish a WebRTC connection. In this CIP we want to introduce an architecture which uses WebTorrent trackers for the peer discovery to remove the need of this central component. ## Specification ### Establish a WebRTC Connection Using a Signaling Server (State-of-the-art approach) ```mermaid sequenceDiagram dApp-->>+Signaling Server: Who am I? Signaling Server-->>dApp: You are Wallet-->>+Signaling Server: Who am I? Signaling Server-->>Wallet: You are dApp->>Wallet: messages Wallet->>dApp: messages ``` The data will be send peer to peer via a WebRTC data channel once the ip discovery has been finished. E.g. WalletConnect expects/provides a relay server URL to initialize the connection. While this method allows dApps to communitcate peer-to-peer with wallets it also leads to a [possible SPOF](https://twitter.com/walletconnect/status/1407279853943001088?lang=en). ### Establish a WebRTC Connection Using WebTorrent Tracker (Our approach) ```mermaid flowchart LR subgraph dApp subgraph .torrent server end end subgraph Wallet[Wallet App] end dApp-->|.torrent| TrackerA[Tracker 1] dApp-->|.torrent| TrackerB[Tracker 2] dApp-->|.torrent| TrackerC[...] dApp-->|.torrent| TrackerD[Tracker n] dApp-->|.torrent| TrackerA[Tracker 1] dApp-->|.torrent| TrackerB[Tracker 2] dApp-->|.torrent| TrackerC[...] dApp-->|.torrent| TrackerD[Tracker n] dApp-->|Share public key| Wallet ``` Deep links, Universal Links, or even the clipboard could be utilized to share the identifier (public key) on the same device (in cases of a wallet based on web technology like Ionic). For sharing the identifier across different devices, QR codes would come into play. This method could be applied, for example, between a wallet mobile app and a dapp running on a PC, or vice versa. The wallet application would then initiate a query to a list of trackers using this distinct identifier in order to establish the WebRTC connection. After this process is completed, the data is transmitted peer-to-peer following the WebRTC standard, for instance, to invoke RPC calls. ```mermaid flowchart LR Wallet-->|queries| TrackerA[Tracker 1] Wallet-->|queries| TrackerB[Tracker 2] Wallet-->|queries| TrackerC[...] Wallet-->|queries| TrackerD[Tracker n] Wallet-->|queries| TrackerA[Tracker 1] Wallet-->|queries| TrackerB[Tracker 2] Wallet-->|queries| TrackerC[...] Wallet-->|queries| TrackerD[Tracker n] subgraph dApp subgraph .torrent server end end Wallet<--Establish WebRTC data channel\n for peer to peer communication-->dApp ``` #### CIP-0013 Compliant Identifiers The keys (public key and corresponding 64-byte secret key) are generated using a function that implements Ed25519. This function requires a (random) seed, which can also be stored and re-used to ensure that whenever a client employs a dApp or a Wallet, the same key pair is generated consistently, even if the browser or mobile app is restarted. The public key will be used as an identifier for the torrent-based peer discovery. When this identifier is shared through methods like QR codes or links, it needs to be compliant to the following Cardano Uri Scheme [(CIP-0013)](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013): | [scheme] | [authority] | [version] | [data] | |---------------|-------------|------------|--------------| | web+cardano: | //connect | /v1 | ?identifier= | ``` web+cardano://connect/v1?identifier= ``` ### Proof of Concept The idea of using WebTorrent trackers instead of signaling servers for peer discovery was already mentioned in [Aug 2018 by Chris McCormick](https://mccormick.cx/news/entries/on-self-hosting-and-decentralized-software): "I've also been tinkering with WebTorrent. [...] Working with this technology made me realise something the other day: it's now possible to host back-end services, or "servers" inside browser tabs. [...] So anyway, I've made this weird thing to enable developers to build "backend" services which run in browser tabs" McCormick's idea has been developed and open sourced as a library called [bugout](https://github.com/chr15m/bugout/) (MIT). For this proof of concept we wrote two small pieces of software: - A html page aka the dApp - An ionic react app (to target mutliple devices) aka the wallet app The whole code is provided within this [demo implementation](https://github.com/fabianbormann/WebRTC-WebTorrent-tracker-communication-demo) that also contains a step-by-step guide. #### dApp The dApp consists of a standard HTML5 template including the following lines of code: ```html ``` #### Wallet App The wallet app is a standard ionic react app built by the ionic cli: ```zsh ionic start WalletApp blank --type=react cd WalletApp npm i bugout ``` The following lines of code were added to the index.tsx file: ```js const bugout = new Bugout( "", { announce: [ 'udp://tracker.opentrackr.org:1337/announce', 'udp://open.tracker.cl:1337/announce', 'udp://opentracker.i2p.rocks:6969/announce', 'https://opentracker.i2p.rocks:443/announce', 'wss://tracker.files.fm:7073/announce', 'wss://spacetradersapi-chatbox.herokuapp.com:443/announce', 'ws://tracker.files.fm:7072/announce' ] }); bugout.on("server", function() { console.log("[info]: connected to server") bugout.rpc("", "api", {"api": { version: "1.0.3", name: 'boostwallet', methods: ["getRewardAddresses"] }}); }); bugout.register("getRewardAddresses", (address:string, args:any, callback:Function) => { callback(["e1820506cb0ce54ae755b2512b6cf31856d7265e8792cb86afc94e0872"]); }); ``` This example has a few restrictions: 1. bugout is currently not compatible with Webpack 5, so polyfills are not automatically included and a react-scripts eject is needed to add them to the webpack.config.js file 2. bugout does not directly provide type declarations. There are some declarations within a [PR](https://github.com/chr15m/bugout/pull/45), but they need to be adjusted (a few parameters are not mandatory) and added to a bugout.d.ts file. ### User Flow ```mermaid sequenceDiagram dApp-->>Wallet: Share address using Deeplink /Universal Link / QR Wallet-->>Tracker List: Accept connection and start quering using the address Wallet-->>dApp: Once connected register RPC functions and share the API dApp-->>dApp: Inject the API to window.cardano[walletName] dApp-->>Wallet: Call RPC functions (e.g. getRewardAddresses) Wallet-->>Wallet: If needed bring app to foregrund (e.g. request signing) Wallet-->>dApp: Send response ``` ### Security Aspects We decided to spawn the server within the dApp to force the user to manually scan a QR code (using a wallet app) or accept an "Open with ``" ui dialog (in case of Universal Links or Deeplinks). This prevents the user from connecting the wallet to an unwanted dApp. Additionally we need to add a few security checks to prevent a misusage of this method. - The wallet app needs to verifiy the origin (address) of the RPC call - dApps should ask the user for permission to inject the wallet names into the window.cardano object to prevent XSS attack (Maybe using a graphical representation of the wallet app address e.g. blockies) ## Rationale The purpose of this CIP mainly consists of two parts. It addresses the current lack of dApp mobile support, but at the same time provides an even more decentralized alternative to state-of-the-art communication methods. To achieve this goal we have introduced a WebTorrent and WebRTC based architecture. To demonstrate a viable implementation, we have implemented a proof of concept which also shows how a rpc method injection like CIP-0030 might look like. ## Path to Active ### Acceptance Criteria - [x] A library should be build to make it easy from dAPP and wallet side to implement the proposed communication method - [x] The library target should be browser to avoid the need of manual polyfills - [x] Mobile testing on different devices and operating systems needs to be done with a special focus to the wallet app running in background mode - [x] Potential security issues and attack vectors need to be discussed in detail 1. We discussed potential security issues in the [CIP discussion](https://github.com/cardano-foundation/CIPs/pull/395#issuecomment-1669460822) and we implement an identicon solutin, but it is obviously an never ending task - [x] A full reference implementation is needed to test if the entire user flow and at the same time provide this as a how-to for developers 1. Has been implemented here https://github.com/fabianbormann/cip-0045-demo-implementation ### Implementation Plan - [x] Fork/Extend bugout to add webpack 5 and typescript support - [x] Povide a general intermediate cardano-connect typescript library to provide 1. A check for mobile/desktop environment 2. Depending on the environment provide interfaces for CIP-0030 / and / or CIP-? 3. Add a full implementation of the server/client side code above to define a communication standard similar to CIP-0030 (getRewardAddresses, signData, signTx, ...) - [x] Start discussions about security gaps within the proposed method with various developers and also look for research papers - [x] Check if the wallet app also reacts to rpc calls in background mode on Android - [x] Check if the wallet app also reacts to rpc calls in background mode on iOS - [x] Implement the library within an example dApp: 1. Implemented in Cardano Ballot for the [summit voting 2023](https://voting.summit.cardano.org/) 2. Implemented by (SundeaSwap)[https://www.youtube.com/watch?v=mRpXIh-DyYM] 3. Implemented into the [cardano-connect-with-wallet core and react library](https://github.com/cardano-foundation/cardano-connect-with-wallet/tree/main) 4. Implemented in [walkinwallet](https://walkinwallet.com/) ### Updates - The re-implementation of bugout that matches the expectations below is now available as [meerkat](https://github.com/fabianbormann/meerkat) - A general [cardano-connect typescript library](https://github.com/fabianbormann/cardano-peer-connect) with 100% CIP-30 support has been provided - The copy & paste [demo implementation](https://github.com/fabianbormann/cip-0045-demo-implementation) is ready to use - Cardano Foundation's [connect-with-wallet](https://github.com/cardano-foundation/cardano-connect-with-wallet) component does include the dApp part of CIP-45 (via feature flag), so that dApp developers don't need to write a single line of code if they rely on this component - The wording of the CIP-45 has been changed. Many thanks to [@jehrhardt](https://github.com/jehrhardt) for his valuable explanation and suggestions ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0049/README.md ================================================ --- CIP: 49 Title: ECDSA and Schnorr signatures in Plutus Core Status: Active Category: Plutus Authors: - Koz Ross - Michael Peyton-Jones - Iñigo Querejeta Azurmendi Implementors: - MLabs Discussions: - https://github.com/cardano-foundation/CIPs/pull/250 Created: 2022-04-27 License: Apache-2.0 --- ## Abstract Support ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core; specifically, allow validation of such signatures as builtins. These builtins work over ``BuiltinByteString``s. ## Motivation: why is this CIP necessary? Signature schemes based on the SECP256k1 curve are common in the blockchain industry; a notable user of these is Bitcoin. Supporting signature schemes which are used in other parts of the industry provides an interoperability benefit: we can verify signatures produced by other systems as they are today, without requiring other people to produce signatures specifically for us. This not only provides us with improved interoperability with systems based on Bitcoin, but also compatibility with other interoperability systems, such as Wanchain and Renbridge, which use SECP256k1 signatures for verification. Lastly, if we can verify Schnorr signatures, we can also verify Schnorr-compatible multi or threshold signatures, such as [MuSig2](https://eprint.iacr.org/2020/1261.pdf) or [Frost](https://eprint.iacr.org/2020/852). ## Specification Two new builtin functions would be provided: * A verification function for ECDSA signatures using the SECP256k1 curve; and * A verification function for Schnorr signatures using the SECP256k1 curve. These would be based on [`secp256k1`](https://github.com/bitcoin-core/secp256k1), a reference implementation of both kinds of signature scheme in C. This implementation would be called from Haskell using direct bindings to C. These bindings would be defined in `cardano-base`, using its existing `DSIGN` interface, with new builtins in Plutus Core on the basis of the `DSIGN` interface for both schemes. The builtins would be costed as follows: ECDSA signature verification has constant cost, as the message, verification key and signature are all fixed-width; Schnorr signature verification is instead linear in the message length, as this can be arbitrary, but as the length of the verification key and signature are constant, the costing will be constant in both. More specifically, Plutus would gain the following primitive operations: * `verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString -> BuiltinBool`, for verifying 32-byte message hashes signed using the ECDSA signature scheme on the SECP256k1 curve; and * `verifySchnorrSecp256k1Signature :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString -> BuiltinBool`, for verifying arbitrary binary messages signed using the Schnorr signature scheme on the SECP256k1 curve. Both functions take parameters of a specific part of the signature scheme, even though they are all encoded as `BuiltinByteString`s. In order, for both functions, these are: 1. A verification key; 2. An input to verify (either the message itself, or a hash); 3. A signature. The two different schemes handle deserialization internally: specifically, there is a distinction made between 'external' representations, which are expected as arguments, and 'internal' representations, used only by the implementations themselves. This creates different expecations for each argument for both of these schemes; we describe these below. For the [ECDSA signature scheme](https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm), the requirements are as follows. Note that these differ from the serialization used by Bitcoin, as the serialisation of signatures uses DER-encoding, which result in variable size signatures up to 72 bytes (instead of the 64 byte encoding we describe in this document). * The verification key must correspond to the _(x, y)_ coordinates of a point on the SECP256k1 curve, where _x, y_ are unsigned integers in big-endian form. * The verification key must correspond to a result produced by [``secp256k1_ec_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L394), when given a length argument of 33, and the ``SECP256K1_EC_COMPRESSED`` flag. This implies all of the following: * The verification key is 33 bytes long. * The first byte corresponds to the parity of the _y_ coordinate; this is `0x02` if _y_ is even, and `0x03` otherwise. * The remaining 32 bytes are the bytes of the _x_ coordinate. * The input to verify must be a 32-byte hash of the message to be checked. We assume that the caller of `verifyEcdsaSecp256k1Signature` receives the message and hashes it, rather than accepting a hash directly: doing so [can be dangerous](https://bitcoin.stackexchange.com/a/81116/35586). Typically, the hashing function used would be SHA256; however, this is not required, as only the length is checked. * The signature must correspond to two unsigned integers in big-endian form; henceforth _r_ and _s_. * The signature must correspond to a result produced by [``secp256k1_ecdsa_serialize_compact``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1.h#L487). This implies all of the following: * The signature is 64 bytes long. * The first 32 bytes are the bytes of _r_. * The last 32 bytes are the bytes of _s_. ``` ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓ ┃ r <32 bytes> │ s <32 bytes> ┃ ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛ <--------- signature ----------> ``` For the Schnorr signature scheme, we have the following requirements, as described in the requirements for [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki): * The verification key must correspond to the _(x, y)_ coordinates of a point on the SECP256k1 curve, where _x, y_ are unsigned integers in big-endian form. * The verification key must correspond to a result produced by [``secp256k1_xonly_pubkey_serialize``](https://github.com/bitcoin-core/secp256k1/blob/master/include/secp256k1_extrakeys.h#L61). This implies all of the following: * The verification key is 32 bytes long. * The bytes of the signature correspond to the _x_ coordinate. * The input to verify is the message to be checked; this can be of any length, and can contain any bytes in any position. * The signature must correspond to a point _R_ on the SECP256k1 curve, and an unsigned integer _s_ in big-endian form. * The signature must follow the BIP-340 standard for encoding. This implies all of the following: * The signature is 64 bytes long. * The first 32 bytes are the bytes of the _x_ coordinate of _R_, as a big-endian unsigned integer. * The last 32 bytes are the bytes of `s`. ``` ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓ ┃ R <32 bytes> │ s <32 bytes> ┃ ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛ <--------- signature ----------> ``` The builtin operations will error with a descriptive message if given inputs that don't correspond to the constraints above, return `False` if the signature fails to verify the input given the key, and `True` otherwise. ## Rationale: how does this CIP achieve its goals? We consider the implementation trustworthy: `secp256k1` is the reference implementation for both signature schemes, and is already being used in production by Bitcoin. Specifically, ECDSA signatures over the SECP256k1 curve were used by Bitcoin before Taproot, while Schnorr signatures over the same curve have been used since Taproot. An alternative approach could be to provide low-level primitives, which would allow any signature scheme (not just the ones under consideration here) to be implemented by whoever needs them. While this approach is certainly more flexible, it has two significant drawbacks: * It requires 'rolling your own crypto', rather than re-using existing implementations. This has been shown historically to be a bad idea; furthermore, if existing implementations have undergone review and audit, any such re-implementations would give us the same assurances as those that have been reviewed and audited. * It would be significantly costlier, as the computation would happen in Plutus Core. Given the significant on-chain size restrictions, this would likely be too costly for general use: many such schemes rely on large precomputed tables, for example, which are totally unviable on-chain. It may be possible that some set of primitive can avoid both of these issues (for example, the suggestions in [this CIP](https://github.com/cardano-foundation/CIPs/pull/220)); in the meantime, providing direct support for commonly-used schemes such as these is worthwhile. ### Backward Compatibility At the Plutus Core level, implementing this proposal induces no backwards-incompatibility: the proposed new primitives do not break any existing functionality or affect any other builtins. Likewise, at levels above Plutus Core (such as `PlutusTx`), no existing functionality should be affected. On-chain, this requires a hard fork. ## Path to Active ### Acceptance Criteria - [x] Include tests of functionality with implementation. - [x] Satisfaction of CIP-0035 requirements ([Additions to the Plutus Core Builtins](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0035#additions-to-the-plutus-core-builtins)) including costing. - [x] Inclusion of SECP in Plutus core ([as of Valentine hard fork](https://docs.cardano.org/cardano-testnet/about/secp/)). ### Implementation Plan - [x] Provide an implementation: by MLabs, [merged into Plutus](https://github.com/input-output-hk/plutus/pull/4368). ## Copyright This CIP is licensed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). ================================================ FILE: CIP-0050/README.md ================================================ --- CIP: 50 Title: Pledge Leverage-Based Staking Rewards Category: Ledger Status: Proposed Authors: - Michael Liesenfelt - Ryan Wiley - Rich Manderino [ECP] - Stef M [RABIT] - Wayne [OTG] - Homer J (AAA) - Chad [BBHMM] Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/242 - https://forum.cardano.org/t/cip-shelley-s-basho-voltaire-decentralization-update/97685 - https://forum.cardano.org/t/minimum-pool-fees-with-a-brief-mention-of-k-changes/97002/82 - https://github.com/cardano-foundation/CIPs/pull/1042 Created: 4 April 2022 (original), 20 May 2025 (updated) License: CC-BY-4.0 --- ## Abstract Improving decentralization is critical for Cardano’s long-term health and growth. The current reward-sharing scheme (RSS) has yielded a stable but suboptimal level of decentralization. In hindsight, the original parameters *k* (the desired number of pools) and *a₀* (pledge influence factor) have not achieved their intended goals. Many stake pools with zero or minimal pledge manage to attract large delegations, undermining the Sybil-resistance that pledge was meant to provide (Liesenfelt, 2022). This proposal introduces a new pledge leverage parameter, *L*, into the RSS to more directly and fairly constrain such under-pledged pools. By capping rewards for pools with excessive stake relative to pledge, *L* penalizes severely under-pledged pools while having minimal effect on well-pledged or small pools. The adjusted scheme aligns economic incentives with decentralization: it redistributes stake toward well-pledged pools (increasing their rewards) and makes it more difficult for single entities to dominate via multiple pools. We present the motivation, specification, and rationale for this change, including simulations illustrating its impact. The goal is to significantly improve effective decentralization (approaching the theoretical *k* target) without unfairly harming small pool operators. ## Motivation: Why is this CIP necessary? ### Stagnating Decentralization and Sybil Concerns Cardano’s block production is less decentralized in practice than the protocol parameter *k* = 500 implies. Although *k* intends to cap pool sizes and guide the network toward saturated equal-sized pools, in reality many of the top pools are operated by the same entities, which defeats the purpose (Fancee, 2022). For example, certain large exchanges run dozens of pools (e.g. 91 by Binance and 31 by Coinbase), collectively controlling roughly 12.59% of stake. This means the Nakamoto Coefficient – the minimum number of distinct entities required to control greater than 50% of block production is only about 25 as of epoch 559 (Balance Analytics, 2025). In other words, the *effective* decentralization is on the order of only a few dozen independent actors, far below the target of 500 pools (Liesenfelt, 2022). As of epoch 560, **473 pools have zero pledge**, yet they still command **2,740,223,943 ADA** in delegated stake (Koios, 2025). This concentration is fueled by Sybil behavior: many pools are essentially split nodes run by one operator. Pool-splitting hurts the network as a whole: operators running multiple low-pledge pools collect multiple fixed fees and margins, reducing rewards for delegators and squeezing out smaller, independent operators (Kiayias, 2020). Under the current Reward Sharing Scheme (RSS) there is no explicit mechanism to limit leverage (stake-to-pledge ratio). An operator can split stake across many pools with zero or tiny amounts of pledge and still earn nearly full rewards on each pool. The saturation parameter *k* limits stake per pool but cannot limit how many pools a single entity operates. The pledge-influence factor a₀ was intended to discourage Sybil attacks, yet at its present value (0.3) it provides only a modest boost to heavily pledged pools. A private pool with high pledge might earn ~3.33 % annualized, while a zero-pledge public pool still earns ~2.6% which is only ~22% less. That small gap is *statistically unnoticed* by most delegators and is overwhelmed by normal epoch-to-epoch luck variance. Crucially, it now takes a pledge of only about **53,870,468 ADA** spread across enough low-pledge pools to control more than 50% of total stake (Koios, 2025). This minimal capital requirement highlights how the current design enables highly leveraged Sybil attacks that erode decentralization and threaten network resilience. ### Limits of the Current Parameters (*k* and *a₀*) Cardano’s decentralization parameters face a dilemma. The parameter *k* governs the target number of pools (decentralization threshold), and *a₀* is the traditional lever for Sybil resistance via pledge. In theory, setting a higher *a₀* would strongly reward pledged stake and penalize pools with little pledge, thereby discouraging Sybil attacks (multiple zero-pledge pools). However, increasing *a₀* would also widen the reward gap between large pledged pools and smaller community pools, harming small pool operators. As of February 2022, with *a₀*=0.3, roughly **1.25 billion ADA** concentrated in **19 fully pledged pools** earns maximal rewards (Fancee, 2022), giving wealthy operators a significant yield advantage. Raising *a₀* further would make this disparity even worse – effectively creating *two classes of stakeholders*, where large custodial actors can offer materially higher yields than individual operators. This is antithetical to Cardano’s egalitarian ethos and has proven politically difficult: the community not made any significant efforts to adjust *a₀* upward, likely knowing it would push many small pools out of the ecosystem. Cardano's previous increase of k from 150 to 500 did result in a modest increase in the number of unique pools making blocks, but it also presented a tradeoff. Some multi-pool operators responded by creating additional low-pledge pools to capture more stake. A concern that has been shared about raising *k* is that it carries the risk of a proliferation of minimally-pledged pools run by the same entities, increasing total pool count with only a minor improvement in the actual diversity of operators. This dilution weakens Sybil resistance and keeps effective decentralization, as measured by k-effective, significantly below the target *k*. To investigate these relationships, the Rewards Sharing Simulation (RSS) engine (University of Edinburgh: Blockchain Technology Lab, 2025) was used with minor modifications to model CIP-50 behavior. When sweeping *k* from 250 to 2,000 while holding *a₀* at a very low value (0.1), the headline “target pool” count grows, but the Nakamoto coefficient actually falls from about 142 at *k*=1,000 to just 116 at *k*=2,000. The hypothesis here is that pledge is too insignificant which leads big operators to simply split their stake into even more zero-pledge pools. The on-chain diversity looks larger, yet real control collapses into fewer hands. ![Current Cardano Rewards Sharing Scheme](images/RSS1.png "Current Cardano Rewards Sharing Scheme") (University of Edinburgh: Blockchain Technology Lab, 2025) Moving a₀ to the opposite extreme tells demonstrates a different issue. At *a₀*=10, the simulation does push the Nakamoto coefficient upward to around 173 at *k*=1,000. But there is a small drop to 169 at *k*=2,000. The hypothesis here is that in this case, pledge has actually been made *too* significant such that only whales with large amounts of pledge are able to compete. This would presumably reshape the ecosystem into an elite upper tier and a struggling lower tier. In effect, we swap Sybil risk for wealth concentration which indirectly harms decentralization. In summary, Cardano’s current RSS parameters are insufficient to prevent Sybil attacks and pool splitting: *k* sets an ideal pool count but doesn’t control for unique identities, and *a₀* is too weak (for political and economic reasons) to enforce meaningful pledge contributions. As a result, many pools with zero or tiny pledge and high delegated stake thrive – which deviates from the original decentralization goals of the Shelley design. An adjustment is needed to strengthen Sybil resistance without unfairly disadvantaging small pools. ### Objectives for an Improved Scheme Any improvement to the reward scheme should adhere to the following high-level goals: * **Fairness**: All stakeholders, from small delegators to whales and exchanges, should have the opportunity to earn *on average* the same *yield* (rewards per unit of stake). The system should avoid creating “VIP” pools with inherently better returns. In other words, no two classes of stakeholders. * **Sybil Protection:** Running multiple pools *must* come at a cost. The scheme should *require* a meaningful pledge to support each pool’s delegated stake – not just mildly incentivize it. Creating many low-pledge pools should result in diminishing returns, removing the current advantage of pool splitting (Kiayias, 2020). * **Decentralization:** The effective number of independent block-producing entities (k-effective) should converge towards the target *k*. The **Minimum Attack Vector (MAV)** (a.k.a. Nakamoto coefficient – number of entities to control 51%) should remain stable or increase. * **Predictability and Simplicity:** The new reward formula should be as simple and transparent as possible, avoiding unnecessary complexity (e.g. no exotic curves or cryptic parameters). Operators and delegators should easily understand the cause-and-effect of the parameters on rewards. This CIP addresses these goals by introducing a new pledge leverage parameter *L* and corresponding modifications to the reward formula. The motivation is to curb extreme leverage (high stake with low pledge) in a targeted way that primarily affects Sybil or multi-pool scenarios, while ordinary single-pool operators with reasonable pledge are largely unaffected (and may even benefit from a fairer playing field). In short, we seek to increase decentralization and security without sacrificing the openness and egalitarian nature of Cardano’s stake pool system. ## Specification ### Introducing the Pledge Leverage Parameter (*L*) For reference we will share the relevant elements of the existing Cardano rewards formula here: ![Cardano Rewards Formula](images/RewardsFormula.png "Current Cardano Rewards Formula") (Pledging and Rewards | Cardano Docs, n.d.) * *R* - Epoch Rewards Pot * *a₀* - Pledge Influence Factor * *k*  - Target Number of Stake Pools * *𝜎'* - Pool stake eligible for rewards * *𝜎* = Pool’s total stake (pledge + delegated stake) * *p'* = Pool pledge eligible for rewards * *p* = Pool’s pledge * *z0*  - Circulating ADA divided by k We propose adding a new protocol parameter L (maximum pledge leverage) to the staking reward formula that fits in the third equation for calculating 𝜎'. The parameter L is defined as the maximum ratio of total stake to pledge that a pool can have before its rewards begin to plateau. In other words, L imposes a pledge-based saturation point for each pool. * **Range of *L*:** 1 ≤ *L* ≤ 10,000 (dimensionless ratio). An *L* of 10,000 represents an extremely high allowed leverage (i.e. pledge need only be 0.01% of the stake), effectively similar to the status quo with a very weak pledge influence. An *L* of 1 represents a very strict requirement where a pool’s stake cannot exceed its pledge (100% pledge) if it is to earn full rewards. * **Reward Formula Changes:** The reward calculation (pool reward R) is modified to incorporate a pledge leverage cap as a new parameter L. Each pool’s stake is effectively capped by its pledge according to L such that the eligible pool stake used in reward computations is: ![CIP-50 Formula](images/CIP50Formula.png "CIP-50 Formula") This means a pool is subject to *two* soft caps: one based on the global saturation (*k*) and one based on its own pledge. * **Stake cap (k):** If a pool’s total stake 𝜎 exceeds *1/k* (the normal saturation point), it gets no extra rewards beyond that point (as in the current formula). * **Pledge cap (L):** If 𝜎 exceeds *L·p* (i.e. the pool’s stake is more than *L* times its pledge), then any stake above that is not counted for rewards either. In effect, the pool is “leverage-saturated” if it tries to grow too large without sufficient pledge backing. ### Implications: * A pool with **very low pledge** relative to its delegation will hit the pledge cap long before the *k* cap. For example, a pool pledging 1k ADA with *L*=100 can fully utilize at most 100k ADA of stake; beyond that, additional delegations won’t increase its rewards. If that pool has, say, 1 million ADA delegated, it will still only earn rewards as if it had 100k (plus its 1k pledge) – the rest of its stake is effectively providing zero rewards to its delegators. This creates a strong incentive for delegators to move to better-pledged pools if their pool is over-leveraged. * A pool with **adequate pledge** will not be affected by the *L* cap until it reaches the normal saturation point. For instance, with *L*=100 and *k*=500, a pool needs about 1% pledge to utilize full stake up to *1/k*. In absolute terms, given the current saturation point around 75M ADA. At *L*=100, a pledge of ~750k ADA would be required to support 75M stake. Pools that meet this pledge-to-stake ratio can grow to saturation normally and will earn the same rewards as under the current formula. * Pools with a **substantial pledge** relative to their stake will not be constrained by the pledge leverage parameter, *L*. These high-pledge pools will instead only reach the global network saturation point, which is determined by *1/k*. Furthermore, these well-pledged pools will also receive a small additional reward boost based on the pledge influence factor, *a₀*, in the existing reward formula, providing them with a modest advantage over pools that are approaching the leverage cap. * If a pool’s stake is **below saturation**, it can still earn rewards on the full amount of stake as long as its pledge is at least *𝜎·L*. Smaller pools typically have smaller 𝜎, so the pledge needed is modest. For example, at *L*=100 and *k*=500, a pool with 500k ADA total stake would only need a pledge of ~5k ADA (1% of 500k) to not be limited by leverage, and it would offer delegators a competitive APY. This is a reasonable pledge threshold, demonstrating that **honest small pools are not penalized** by *L*. They can achieve comparable yields as large pools on a proportional basis. * Crucially, a pool with **zero pledge will earn zero rewards** if it has any delegated stake. This is a clear break from the current scheme, where a pool with 0 pledge can still generate rewards for delegators (just slightly less). Under the new formula, some amount of pledge becomes absolutely mandatory. This eliminates the “free rider” problem of profit-seeking pool operators undermining the network’s security. ## Rationale: How Does This CIP Achieve Its Goals? ### Penalizing Under-Pledged Pools (Sybil Deterrence) The pledge leverage parameter *L* directly targets the worst-offending pools from a Sybil perspective – those with lots of stake but little skin in the game. By establishing an upper limit on stake relative to pledge, *L* introduces a hard economic penalty for over-leveraged pools. An operator can no longer create unlimited pools with minimal pledge and expect nearly full rewards on all of them. Any pool that is* severely under-pledged *will quickly hit the leverage cap and see its additional delegated stake yield zero incremental rewards. This has an immediate discouraging effect on Sybil behaviors: * A malicious actor attempting to control a large portion of stake by spinning up many pools would now need to proportionally increase pledge for each pool to make them effective. Otherwise, delegators will not join those pools (due to poor returns) or will abandon them once they realize additional stake is wasted. The economic cost of a Sybil attack thus becomes *linearly proportional* to the stake under control, thanks to the pledge requirement, rather than merely the fixed cost of running many nodes. * Importantly, *L* removes the “free ride” incentive that previously existed where splitting one’s stake into multiple pools could circumvent the saturation limit. Under the new scheme, splitting stake across N pools without adding more pledge might split one’s effective rewards as well. For example, if an entity with a fixed total pledge *p* runs two pools, each pool will have at most *p·L* worth of effective stake. If they had combined everything in one pool, they’d have *p·L* effective stake (assuming that was the limiting factor). By splitting into two pools with pledge p/2 each, each pool caps at (p/2·L), for a combined effective stake of *p·L* – the same as one pool. Thus, there is no gain in total rewards by operating multiple pools under a fixed pledge budget. Any attempt to gain more by adding a new pool will just spread the pledge thinner and impose a lower cap per pool, keeping the total unchanged. This is a fundamental change: in the current scheme, splitting stake *can* increase an entity’s total rewards (because each pool can almost fully saturate and earn fees), but with *L* enforced, splitting yields *diminishing returns* unless accompanied by more pledge. * Furthermore, *L* ensures pledge is absolutely mandatory for participation, aligning every operator’s incentives with the network’s security. Unlike today where many pools operate with almost zero pledge, under the new formula a pool with 0 pledge simply cannot earn rewards. Even a minimal pledge pool will severely limit its delegators’ returns if it grows, making it unappealing. This policy embodies the principle that if you want to benefit from community delegation, you must put up a bond to secure the network. It converts pledge from a weak nudge into a strict requirement, dramatically strengthening Sybil resistance. In short, *L* provides an enforceable limit on Sybil actors and their maximum return on invested capital. It closes the loophole that allows large holders to game the system by simply multiplying pools. By tying rewards to pledge, the economic playing field is leveled: operators must either commit capital or accept a cap on their pool’s influence. This directly realigns incentives with decentralization and security. ### Minimal Impact on Honest Small Pools A key advantage of using *L* (a leverage cap) instead of raising *a₀* (linear pledge influence) is that it minimizes negative effects on small or medium operators. The leverage cap kicks in when a pool tries to scale beyond what its pledge supports. Small pools, by definition, are not huge in stake, so most will not even reach the cap if *L* is tuned reasonably. For example, a pool with 1M ADA stake and 10k ADA pledge at *L*=100 is right at the cap (since 10k*100 = 1M); if it grows above 1M, then yes, it would need more pledge to maintain max rewards. But if that pool stays small or gradually grows alongside its pledge, its delegators experience no reduction in yield. In practice, many community pools already maintain a healthy pledge relative to their current delegation. These pools will see no change in their rewards from the new formula, except that they might actually become more attractive to delegators compared to under-pledged competitors. By contrast, increasing *a₀* would hurt small pools immediately by lowering their rewards relative to large pools (regardless of the small pool’s size). The *L* parameter avoids that blunt harm by acting as a soft cut-off rather than a across-the-board tax. Pools earn normally up to a point, then flatline. Thus, a small pool that isn’t anywhere near saturation or leverage limits will function just as before (or better, since delegators may redistribute in its favor). The reward system aims to remain largely egalitarian: most pools that meet the pledge ratio can reach a similar maximum reward per stake. While increasing a₀ can create a slightly steeper reward gradient favoring high-pledge pools, introducing *L* creates a flat plateau for all pools that meet the leverage requirement while still maintaining a minor pledge benefit through *a₀* up to the global saturation point. This leverages the new *L* parameter to be more egalitarian while still incentivizing pledge, aiming to minimize the creation of disparate classes of participants. ### Discouraging Multi-Pool Splitting and Easing *k* Increases One of the strongest arguments for the leverage-based approach is its effect on multi-pool operators (MPOs). In the current scheme, an MPO (like an exchange or a pool group) can slice their stake into *N* pools and, aside from the minor dilution of pledge, face little downside. They often benefit by collecting multiple fixed fees and saturating more pools. This has led directly to the situation of single entities running tens of pools and dominating the top ranks. With *L*, the advantage of operating multiple pools is blunted for operators with too little pledge to support them. Since the rewards of each pool are limited by pledge, an MPO with a fixed total pledge won’t gain by spreading it thin. In fact, operating more pools could reduce their overall efficiency if their pledge per pool drops. The rationale is simple: if splitting your pledge into two pools halves the effective cap of each, you end up with the same total effective stake across your pools (and thus the same total rewards) as if you kept one pool fully pledged. Therefore, a rational operator under the new scheme would have no incentive to run more pools than necessary to accommodate their stake and pledge. We anticipate that many MPOs will consolidate or reduce the number of pools they run once *L* is in effect, because having many half-pledged pools would just advertise their leverage weakness and fail to increase their earnings. This property is especially important when considering future increases in *k*. If Cardano wants to raise *k* (say to 1000 or beyond) to encourage further decentralization, *L* will ensure that those additional pool “slots” actually translate to new operators, not just existing MPOs multiplying again. As noted earlier, raising *k* alone without leverage control might invite big players to split stake into more pools. But if those players are constrained by pledge, they cannot effectively occupy all the new slots at full rewards. For instance, an exchange with limited pledge might fill some pools to the cap, but then either stop or create more pools that are underperforming. This leaves room (and incentive) for other operators to step in and operate the remaining pools, because delegators will seek out pools that *can* give full rewards. Thus, *L* works in synergy with raising *k*: it amplifies the decentralization impact of a larger *k* by preventing single entities from monopolizing the new capacity. In effect, *L* helps align *k* (the protocol’s target) with *k-effective* (the real outcome). We can safely pursue higher *k* values knowing that effective decentralization will follow more closely, rather than being undermined by Sybil pool clusters. ### Validating Behavior with Reward Sharing Simulation Engine To test whether the leverage cap (*L*) proposed in CIP-50 delivers the intended balance between Sybil resistance and fairness, we re-ran the University of Edinburgh Reward-Sharing Simulation Engine with two configurations: 1. **Baseline** – the current Cardano rewards formula exploring *k = 250 → 2,000* and *a₀ ∈ {0.1, 0.3, 0.5, 1, 10}*. 2. **CIP-50** – identical *k* sweep but with *a₀ locked at 0.3* and *L ∈ {10, 100, 1 000, 10,000}*. ![Current RSS vs CIP-50](images/RSS2.png "Current RSS vs CIP-50") (University of Edinburgh: Blockchain Technology Lab, 2025) **Decentralization is roughly the same or slightly improved.** Where the baseline delivers 159 independent entities for the current parameter set (*k=500, a₀=0.3*), CIP-50 achieves **~160** at almost all settings of *L*. Thus the new rule neither harms decentralization nor relies on an unpalatable increase to *a₀*. **Network pledge rises slightly.** Total pledged stake in the baseline hovers between **0.73 and 0.93** of the maximum possible, depending on *a₀* and *k*. CIP-50 nudges this figure upward at *a₀*=0.3, showing that a leverage ceiling likely would entice operators to increase their pledges rather than spawn extra pools. **Lower *L* values are preferred.** While any finite *L* blocks the worst Sybil behavior, tighter caps yield the best Sybil protection without penalizing small-to-medium operators the way a large *a₀* increase would. The sweet spot lies at the lower end of the tested range (~10 to ~100), where Sybil protection is strongest yet the number of viable pools remains healthy. ***L* primarily strengthens Sybil protection.** In the baseline, lowering *a₀* to 0.1 caused a notable drop in Nakamoto coefficient at *k=2000*. To investigate this particular issue, further simulations were run with extremely low values of *a₀* with the current rewards formula and with CIP-50 and a flat *L* value of 10. ![Current RSS with low a0 values](images/RSS3.png "Current RSS with low a0 values") ![CIP-50 with low a0 values and L=10](images/RSS4.png "CIP-50 with low a0 values and L=10") (University of Edinburgh: Blockchain Technology Lab, 2025) The addition of *L* resulted in a notable improvement in the Nakamoto coefficient over the baseline rewards formula. Taken together, the simulations support the hypothesis that CIP-50’s leverage cap will accomplish its primary mission of curbing Sybil pool proliferation. ## Path to Active ### Acceptance Criteria **Consensus on an Initial *L*** – An initial value of *L* must be agreed upon before hard-fork combinator (HFC) activation. The choice should balance Sybil protection against operational viability, drawing on empirical analyses (e.g., RSS results) and community feedback. **Endorsement by Technical Bodies** – The Cardano Parameter-Change Proposals (PCP) Committee and the Intersect Technical Steering Committee (TSC) should both recommend the proposal as technically sound and aligned with the protocol’s long-term roadmap. **CIP Editorial Approval** – Cardano CIP Editors must confirm that the specification is complete, unambiguous, and internally consistent with existing CIPs. **Stakeholder Concurrence** – A majority of stake pool operators (SPOs), ecosystem tooling maintainers, dReps, and other infrastructure providers must signal readiness to upgrade. **Governance Ratification** – The on-chain Hard-Fork Governance Action must pass the requisite dRep and Constitutional Committee thresholds, establishing legal-constitutional legitimacy and stakeholder support for the change. ### Implementation Plan **Community Deliberation (Preparation Phase)** * Publish the finalized CIP-50 revision and present it to the PCP committee , TSC, CIP Editors, and wider community channels (Discord, X, Cardano Forum, etc.). * Collect structured feedback—particularly on candidate values for *L*—and iterate until broad technical consensus emerges. **Specification & Code Integration (Development Phase)** * Once an initial *L* is determined, integrate the leverage-cap logic into cardano-node and related libraries (ledger, CLI, wallet APIs). * Submit pull requests to the canonical repositories; obtain code reviews from IOG, CF, and community contributors. * Release a new protocol version that includes the changes made in this CIP. * Use a dedicated pre-production testnet that mirrors main-net parameters but enforces the new *L* rule, allowing SPOs and exchanges to test end-to-end flows. **Readiness Sign-off (Testing Phase)** * Require at least two weeks of uninterrupted testnet stability plus green results from regression and property-based tests. * Monitor ecosystem dApps and tooling to confirm that major node implementations, explorers, wallets, and exchange integrations support the new rule set. **On-chain Governance (Ratification Phase)** * File the Hard-Fork Governance Action on-chain with the agreed *L*, tagged for the next hard fork event. * Mobilize dRep outreach to ensure quorum and super-majority passage; concurrently, the Constitutional Committee validates procedural compliance. **Hard-Fork Activation (Deployment Phase)** * Upon successful vote, the hard fork event is automatically triggered upon epoch turnover. * Monitor main-net metrics during the changeover epoch; provide real-time support for any late-upgrading SPOs. ## References AdaPulse. (2023, February 23). *MAV: The Safety Metric In Block Production Decentralization*. AdaPulse. Retrieved May 20, 2025, from https://adapulse.io/mav-the-safety-metric-in-block-production-decentralization *Balance Analytics*. (2025, May 20). Average Resulting Decentralization. Retrieved May 20, 2025, from https://www.balanceanalytics.io/chartboards/decentralization Balance Analytics. (2025, May 20). *Group Stake Donut Chart*. Balance Analytics. Retrieved May 20, 2025, from https://www.balanceanalytics.io/chartboards/donut_shop Fancee, T. (2022, February 1). *CIP - Leverage-based Saturation and Pledge Benefit*. Cardano Forum. Retrieved May 20, 2025, from https://forum.cardano.org/t/cip-leverage-based-saturation-and-pledge-benefit/95632 Kiayias, A. (2020, November 12). *The general perspective on staking in Cardano*. Input | Output. Retrieved May 20, 2025, from https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/ Kiayias, A. (2020, November 29). *Blockchain reward sharing - a comparative systematization from first principles*. Input | Output. https://iohk.io/en/blog/posts/2020/11/30/blockchain-reward-sharing-a-comparative-systematization-from-first-principles/ Koios. (2025, May 28). *Pool List API*. https://api.koios.rest/ Liesenfelt, M. (2022, April 4). *Pledge Leverage-Based Staking Rewards*. Cardano Improvement Proposals. Retrieved May 20, 2025, from https://cips.cardano.org/cip/CIP-0050 Pledging and rewards | Cardano Docs. (n.d.). Cardano Docs. Retrieved June 4, 2025, from https://docs.cardano.org/about-cardano/learn/pledging-rewards University of Edinburgh: Blockchain Technology Lab. (2025, May 28). *Rewards Sharing Simulation Engine*. https://github.com/Blockchain-Technology-Lab/Rewards-Sharing-Simulation-Engine ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). ================================================ FILE: CIP-0052/README.md ================================================ --- CIP: 52 Title: Cardano audit best practice guidelines Status: Proposed Category: Meta Authors: - Simon Thompson Implementors: [] Discussions: - https://github.com/cardano-foundation/CIPs/pull/252 - https://github.com/cardano-foundation/CIPs/pull/344 - https://github.com/cardano-foundation/CIPs/pull/406 - https://github.com/cardano-foundation/CIPs/pull/560 Created: 2022-04-25 License: CC-BY-4.0 --- ## Abstract These guidelines describe the audit process in general before setting out for DApp developers what information they will need to supply to auditors as part of the process. These are guidelines rather than requirements, and different auditors may engage differently, providing complementary services. The guidelines aim to establish a common baseline, including alternative ways of satisfying high-level requirements. Appendices provide (1) a glossary, (2) an audit FAQ, (3) a list of auditors for Cardano, and (4) a sample audit report. ## Motivation: why is this CIP necessary? This CIP aims to promote the process of audit for DApps on Cardano, to improve the overall standard of assurance of DApps built for Cardano, and thus to contribute the improvement of the wider Cardano ecosystem. ## Specification ### Introduction DApp users seek assurance about DApps that they wish to use. This comes from running automated tools on DApps and their components, as well as by audit of complete DApps. Secure evidence of these tool (level 1) and audit (level 2) results is provided by a certification service, and made available to users through a service such as a DApp store or wallet. In the longer term, results of formal verification (level 3) will also form part of the certification process. DApp developers seek to drive adoption through their DApps being certified. Wallets and DApp stores are enhanced by providing certification services, and the wider Cardano ecosystem is strengthened through certification becoming widespread. Best practice standards can be developed by the audit and tooling communities, and systematised by the Cardano Foundation. This document is a first step in that direction. **Assurance can only ever be partial:** a DApp can be shown to have some good features and to avoid some bad ones, but this is not a guarantee that using a DApp will not have negative consequences for a user. This is not simply because tools and audits cannot give complete coverage, but also because attacks may come at lower (e.g. network, browser) or higher (e.g. crypto-economic) levels than addressed here. These are guidelines rather than requirements, and different auditors may engage differently, providing complementary services. The guidelines aim to establish a common baseline, including alternative ways of satisfying high-level requirements. Appendices provide (1) a glossary, (2) an audit FAQ, (3) a list of auditors for Cardano, and (4) a sample audit report. ### Prerequisites #### Key terms ***(Smart) contract***: a program that runs on blockchain. In the case of Cardano, this will be a Plutus program that will contain Plutus Core components that run on blockchain as well as other code that runs off chain. All auditors will scrutinise on-chain code, some will examine off-chain code too.Some auditors might also provide orthogonal services eg. auditing a zero-knowledge protocol or an economic model. ***DApp***: a complete “distributed” application that runs on blockchain. This will include off-chain code written in other languages, e.g. running in a browser, and will integrate or link with other services such as wallets and oracles. ***Assurance***: the process of establishing various properties of systems, both positive (it does this) and negative (it doesn’t do this), with different degrees of certainty. ***Audit***: the process of establishing assurance by means of manual examination of artefacts, systems, processes etc. Can involve some tooling, but it is a human-led process. ***Tooling***: using automated processes to establish degrees of assurance of systems. Tools may be run on target DApps by parties providing such a service. ***Evidence***: artefacts coming out of tooling and audit that can support assertions of assurance of systems. Examples include formal proofs, test suites, prior counterexamples and so on, as well as audit reports. ***Certification***: the process and technology of giving to DApp end-users and developers secure evidence of forms of assurance about DApps and their component smart contracts. In the case of Cardano our approach is to provide information on chain as transaction metadata. *Note*: “certification” has also been used informally to cover the combined process of testing, audit, verification and providing evidence of these, as in “level 1 certification”. If it is felt that it is too confusing to use the term in both senses, then another term should be found, e.g. *evidencing* or *witnessing*. ***Component***: a discrete part of the complete system supplied by a third party, such as a wallet, (part of) which will be run on the user’s system. ***Service***: a part of the system, such as Blockfrost, that is provided by an online server accessed through a well-defined protocol. ***Scope***: the parts of the DApp that are subject to audit. A repository may contain much more than Plutus code. Some audits will look at the complete app, some will just concentrate on on-chain transactions, others on the web interface around it. The possible scopes are divided in three main categories: * On-chain * Off-chain * Context: the business and economic models for the DApp ***Deployment***: once a DApp is developed it is deployed by submitting the relevant on-chain scripts onto the Cardano blockchain as transaction validator scripts. The scripts being deployed might be the scripts that have been audited, or be instances of them in the case that the audited scripts are *parametric*. #### Audit FAQ ##### *What is an audit?* An audit is a comprehensive investigation of a DApp that provides an in-depth analysis on bugs, vulnerabilities, code quality and correctness of implementation. An audit does not necessarily analyse completed DApps and often will instead analyse a fragment of a DApp. For example many auditors will only analyse the on-chain code of a DApp. ##### *Who provides an audit?* Audits are provided by companies that specialise in the area of the developed DApp. In this case it will be experts on the Cardano blockchain and Plutus smart contracts. ##### *How does audit work? What is the process?* This first part of the process is tendering, where developers will need to provide preliminary information about their DApp to candidate auditors, as described below. Once a contract is agreed, the next step in the process is to provide the auditors with the necessary information to perform the audit as set out in the guidelines below. Auditors may work with developers to ensure that the documentation and other materials for audit are prepared to the standard that is required for the audit to take place. Different auditors will have different requirements, but the guidelines below establish the minimum requirements. Auditors will typically produce a first version of a report, which the developer can use as a guide to improving their DApp, before submitting changes to produce the final version of the code on which the final, published report is based. Once a DApp is audited, it will be deployed on the Cardano blockchain. ##### *When should a developer contact an auditor?* A developer should contact an auditor when they have a final working version of a DApp or fragment of a DApp that they want to have audited. Once the contract is agreed, the developer will need to provide the auditor with a final version of the DApp for audit. However, it is recommended to contact a potential auditor as early as possible because many auditors also provide consultation services for the design and development of the DApps. A developer is encouraged to contact the auditor as early as possible so as to mitigate any design issues which may be very hard if not impossible to fix. Early contact is also encouraged because securing a time slot with an auditor in advance shortens the DApp’s overall time to market, finally, early contact allows for scheduling and potentially avoids long delays between starting and completing an audit. ##### *What is audited when an audit takes place?* All audits will examine the on-chain code that is used to validate transactions submitted to advance the smart contracts that constitute part of a DApp. Audit may also cover more of the code in a DApp, including on- and off-chain code written in Plutus, as well as other languages, e.g. JavaScript running in a browser. ##### *What guarantees can and cannot be given by an audit?* An audit ***is not*** a guarantee of unbreakable security nor a way to offset trust or responsibility. An audit will provide an in-depth review of the source code of a DApp. The audit will provide a comprehensive code review detailing any found vulnerabilities, comments on the quality of code as well as an analysis of the implementation in regards to the supplied specification. An audit cannot guarantee that all possible vulnerabilities will be found or that the deployed DApp will perform as intended. This is especially true in the cases where an audit only looks at a fragment of a DApp or when a DApp has been updated. ##### *Who are the stakeholders involved in the audit process?* DApps are used by *DApp users*, and built by *DApp developers*. Audit is performed by *audit companies*, using tools developed by themselves and other *tool developers*. Tooling can be run by *tool service providers*, and evidence of those and other results produced by *certification providers*. Audit is also impacted by components (e.g. light wallets) and services (e.g. blockfrost) provided by *ecosystem members*. Standards can be developed by *industry consortia* or *governance organisations* (e.g. the Cardano Foundation). In the widest sense, all *holders of Ada* stand to benefit from Cardano building an expectation that DApps are certified. ### Cardano auditors | Audit company | URL | Contact email | Public key | | ----------- | ----------- | ----------- | ----------- | | FYEO Inc. | https://gofyeo.com/blockchain-security | sales@gofyeo.com | | | Hachi | https://hachi.one | team@hachi.one | | | MLabs | https://mlabs.city | info@mlabs.city | 64BC640B5454215D12165EEAEEFF303D2643ABA2 (PGP, ed25519) | | Runtime Verification | https://www.runtimeverification.com | contact@runtimeverification.com | | | Tweag | https://www.tweag.io | sales@tweag.io | | | Vacuumlabs (audits → Invariant0) | https://vacuumlabs.com/ | info@invariant0.com | 16541FD112978F3C6D49E79881E6B1F9C0BC6BF9 (PGP, ed25519) | | CertiK | https://www.certik.com/products/smart-contract-audit/ | sales@certik.com | | | Invariant0 | https://invariant0.com/ | info@invariant0.com | 3C010EA5654D57D0AEF0E50B75D3AA3D42D52499 (PGP, ed25519) | ### Tendering In order to provide a quote for audit, developers will need to supply * A specification of the DApp to be audited (more details below). * The scope of the audit. * An estimate of the scale of the audit work, e.g. the number of lines in the on-chain code to be audited, or the code itself, in its current state of development. ### Submission In order to be audited, developers will need to supply the following documentation. #### *Specification / design documents* Submitters shall provide specification and design documents that describe in a precise and unambiguous way the architecture, interfaces and requirements characterising the DApp. The documentation shall identify the expected behaviour of the code, given without direct reference to the code itself. The description should also include high-level examples demonstrating use cases of the DApp. All assumptions about how the DApp will be used will be described. The documentation shall identify and document all the interfaces with other components and services. Submitters might also wish to explain mitigating actions that they have taken to protect against potential failures and attacks to the DApp. #### *On-Chain Specification* The format of transactions accepted by the smart contracts should be specified using the template provided in the auxiliary document `Tx-spec.md`. The document should clearly specify the properties to be satisfied by the smart contract. * Properties shall be as extensive as possible and ideally would cover functionality, robustness, safety, liveness and efficiency, e.g. cost of execution, of the smart contract. * Discussion should describe whether any of the properties addresses common vulnerabilities pertaining to Cardano blockchain or the smart contract domain in general. A formal specification is recommended but not mandatory. #### *Off-Chain Specification* For off-chain analysis additional information should be provided for the components and services interfaced: * For all interfacing components, a specification shall be given detailing their expected behaviour in relation to the DApp, including any assumptions, constraints and requirements of the component that are expected to hold by the DApp developers. * It also shall be stated whether any of the interfacing components have been certified. #### *Testing* Ideally, submitters should submit a description of how the DApp has been tested, the results of the tests, and details of how those test results can be replicated.In particular: * The test cases and their results shall be recorded or reproducible in a machine-readable format to facilitate subsequent analysis. * Tests are to be performed for each targeted platform (browser, wallet etc). * The identity, configuration and version of all test components involved shall be documented. * The checksum and version of the DApp submitted for certification shall correspond to the same version making the subject of the test report. * An evaluation of the test coverage and test completion should be provided. In the case that off-chain code is included in the scope of the audit, testing should be able to assess the performance and robustness of the DApp against significant throughput, under substantial workload, and in the scenario of a DoS attack. #### *Source code and version* A final version of the source code should be provided that works with the use cases specified in the documentation. Information needs to be provided to allow the DApp to be built in an unambiguous and reproducible way, including any external components and services that the DApp uses. This could be in the form of * The URL for a commit to a repository. * Build information for the DApp: a pure nix build is particularly suitable, since this will identify versions of libraries, compilers, OS, etc. * For the on-chain code for a DApp, the specific contracts to be audited. #### *Versioning* Versioning information needs to be given in a way that allows end users of a DApp to determine whether or not the version of the DApp that they are using is covered by certification information held on blockchain. This can be done in a number of different ways, depending on the type of audit. These include: 1. The hash of a URL for a commit to a publicly-available repository. 2. A hash that identifies the files that contain the on-chain code that has been audited, e,g computing, from the root of the repository, listed in lexicographic order. #### *Registration* It is planned that DApps will be registered on the Cardano blockchain. This is currently under discussion. Once that discussion has been settled, it will also be possible to provide on-chain evidence of audit, linked to a registered entity. The mechanism for this is described in a separate document which it is intended to make into another CIP. A current draft of that document is here: [Proof of Audit document](https://docs.google.com/document/d/1FvgX8QiGKVPv4c7HanZ92zwstD9U1amOf8eHvyIb1dI). ### Requirements for Auditors #### *Responsibilities* Auditors shall be able to carry out the following activities: * Review the requirement specification document against the intended environment and use so as to: * Identify any inconsistencies, security flaws or incomplete requirements * Identify any implicit assumptions and whether they are justifiable or not * Evaluate the adequacy of strategies applied by the submitter to guarantee the consistency, correctness and completeness of the requirements * Identify a threat model to guarantee that any identified mitigations are indeed appropriate against a list of possible vulnerabilities for Cardano smart contracts, and which is currently being finalised. * The source code shall be audited by manual and/or automated means. In particular, * The source code shall be reviewed against the requirements to ensure that all of these are properly taken into account and completely fulfilled. * The adequacy of the source code documentation and traceability with the requirements shall be assessed. * The source code shall be free from coding patterns/programming mistakes that may introduce exploitable vulnerabilities/failures leading to security issues. * Produce a detailed audit report describing scope, methodology, and results categorised by severity. In particular, * Any discrepancies, deviations or spotted vulnerabilities shall be described and classified with an appropriate severity level. Recommendations to rectify the identified deficiencies shall also be provided whenever appropriate. * When automated tools are used as a replacement for manual review/code inspection, they shall be documented or referenced. Note that it’s the responsibility of the auditor to ensure that such tooling may not exhibit potential failures that can adversely affect the review outcome. * Any strategies/methodologies used to assess the consistency, correctness and completeness of the requirements shall also be documented or referenced. #### *Key competencies* Auditors shall provide credentials for the following competencies: * They shall have an in-depth knowledge of the syntax and semantics of the smart contract language to be audited, the underlying blockchain technology and associated computation and cost models. * They shall be competent in the strategies and methods used to elaborate threat models. * They shall be competent in assessing the suitability of methods (or combination of methods) used to justify the consistency, correctness and completeness of requirements against the list of common vulnerabilities pertinent to the smart contract domain and to guarantee (as far as possible) the absence of security flaws in the design. * They shall be competent in various test and verification methods and have solid background in the various test coverage criteria (i.e., statement, data flow, branching, compound condition, MC/DC and Path). * They shall also be able to assess whether the set of test cases produced for each specific test objective/property are sufficient enough to cover all the possible functional cases. * They shall have analytical and critical thinking ability pertaining to the: * deployment and execution of smart contracts on the underlying blockchain technology; * Potential attacks or sequence of events relative to the smart contract’s logic that may lead to an unsafe state or invalidate some of the fundamental properties of the contract. * They shall be able to judge the adequacy of the justifications provided by submitters w.r.t., development processes (e.g., requirement elicitation techniques, threat models, test objectives and test cases, coding standard, quality management, etc) for Level 2 certification. #### *Disclosure* Disclosure It is common – but not universal – practice for disclosure/publication of audit report, for example as a part of a responsible disclosure policy. A typical policy would be to publish a report after a certain period (e.g. 30-90 day) or at the point that a DApp goes live, whichever is earlier. ## Rationale: how does this CIP achieve its goals? These guidelines are the result of a process of discussion between IOG staff and members of the audit and academic communities over a series of online meetings in February and March 2022. Audit organisations involved include Tweag, WellTyped, Certik, Runtime Verification, BT Block, MLabs, Quviq and Hachi/Meld, all of which supported the guidelines outlined here. ## Path to active ### Acceptance Criteria - [ ] Evidence that Cardano audits are being performed according to this proposed standard, by reference to specific audit(s) citing CIP-0052 and containing these audit elements. ### Implementation Plan - [x] Initial set of Cardano auditors provided with CIP, with others added afterward along with contact information and verification keys. ## Copyright This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) ================================================ FILE: CIP-0052/Tx-spec.md ================================================ # Cardano Tx blueprint specification ## Purpose Establish a standard submitter requirement for a Plutus on-chain audit. This standard is designed to be orthogonal to the domain of the DApp, easy to write, intuitive and helpful for the auditor and finally, concrete. ## Content The common aspect to all Plutus DApps is their transaction blueprint specification. That is, what are the allowable transactions for the particular set of validator scripts and monetary policies in question and what are the specific datum/redeemer pairs that must be consumed and the expectations on the produced datums. This document should include the system flow or transaction dependency. For example, if the system is a DEX, we would expect the flow to outline that one must initiate a pool *before* applying an order to it. ## Format Designed to be as intuitive as possible. No additional explanation needed after looking at an example: ```YAML transactions: openPool: inputs: pkUtxo: value: v satisfies: v must have 2 coins with at least M amount. # spoken-language annotation mints: factoryToken: amount: 1 outputs: scriptUtxo: script: poolValidator datum: Pool v value: v <> factoryToken(1) buy: inputs: scriptUtxo: script: poolValidator datum: Pool v1 redeemer: Buy pkUtxo: address: a value: v2 outputs: scriptUtxo: script: poolValidator datum: Pool buyEquationPool(v1, v2) value: buyEquationPool(v1, v2) # buyEquation is a pure-math formula listed somewhere… pkUtxo: address: a value: buyEquationBuyer(v1, v2) ``` ## Format Considerations We should rely on a simple textual format for two reasons: * easy to automatically generate and consume with tooling; and * easy to incorporate as comments to code and or Markdown files, which is how most clients provide their design documents. ## Specifying Tx-flow In addition to specifying each transaction separately, these will be presented to the chain according to an underlying logic, or flow, which could be seen as a state transition system. Ideally these flows will be specified, but it is understood that specifying those systems formally is a lot of work and detail. We propose a very high-level description of these systems, which omits a lot of detail but conveys the essential information needed by the auditor. We advocate for a simple, flat, set of states: all the states' labels appearing. We can easily generate a dot-file from this and it is low-effort for the developer of the contract to produce. Developers and auditors can add more information as they want on the label itself, which should be ids of elements in the transactions listed above. ```YAML flow: startGovernance: from: initial to: hasNPools(0) openPool: from: hasNPools(n) to: hasNPools(n+1) buy: id: hasNPools(n) sell: id: hasNPools(n) closePool: from: hasNPools(n+1) to: hasNPools(n) ``` It is worth noting that `hasNPools(n+1)` should perhaps be read as just a string, not parsing the application of `n+1` to a family of states `hasNPools`. Even if the output graph contains three states labeled `hasNPools(0)`, `hasNPools(n)` and `hasNPools(n+1)` the auditor can still have a clear understanding of the flow of the DApp in question. ================================================ FILE: CIP-0054/README.md ================================================ --- CIP: 54 Title: Cardano Smart NFTs Status: Proposed Category: Tokens Authors: - Kieran Simkin Implementors: - Kieran Simkin Discussions: - https://forum.cardano.org/t/cip-draft-cardano-smart-nfts/100470 - https://github.com/cardano-foundation/CIPs/pull/263 Created: 2022-05-18 License: CC-BY-4.0 --- ## Abstract This CIP specifies a standard for an API which should be provided to Javascript NFTs, it also defines some additions to the 721 metadata standard defined in [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) which allow an NFT to specify it would like to receive certain current information from the blockchain. ## Motivation: why is this CIP necessary? Currently if an NFT creator wishes to change or otherwise “evolve” their NFT after minting, they must burn the token and re-mint. It would be very nice if the user were able to modify their NFT simply by sending it to themselves with some extra data contained in the new transaction metadata. This would allow implementation of something like a ROM+RAM concept, where you have the original immutable part of the NFT (in Cardano’s case represented by the original 721 key from the mint transaction), and you also have a mutable part – represented by any subsequent transaction metadata. It would also be nice to be able to retrieve data that has been previously committed to the blockchain, separately to the NFT which wishes to access it. This would be useful for retrieving oracle data such as current Ada price quotes – as well as for allowing an NFT to import another NFT’s data. Further to this - for on-chain programatically generated NFTs, it makes sense to mint the code to render the NFT as one token, and then have the individual NFTs contain only the input variables for that code. This CIP specifies an additional metadata option which specifies that an NFT should be rendered by another token - this will massively reduce code duplication in on-chain NFTs. This combination of functionality enables many exciting new possibilities with on-chain NFTs. ## Specification ### The Metadata Minting metadata for Smart NFTs – based on the existing [CIP-0025](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0025) standard: ``` { "721": { "": { "": { "name": , "image": , "mediaType": "image/", "description": , "files": [{ "id": "name": , "mediaType": , "src": , }], "uses": { "transactions": , "tokens": , "renderer": } } }, "version": "1.0" } } ``` Here we have added the “uses” key – any future additions to the Smart NFT API can be implemented by adding additional keys here. We've also added an additional field to the files array - this is to specify a unique identifier to enable the files to be referenced by the Javascript API below. #### The transactions key To enable evolving NFTs where the NFT monitors a transaction history and changes in response to new transaction metadata, we define a sub-key called “transactions”, which can contain either a string or an array, specifying the tokens or addresses the NFT wishes to receive the transaction history for. These transaction histories will be provided to the NFT via the Javascript API detailed below. We also define a special keyword “own” which can be used to monitor the NFT’s own transaction history. So if we wish to create an “evolvable” NFT that can respond to additions to its own transaction history, the “uses” key within the metadata would look like: ``` "uses": { "transactions": "own" } ``` If you wanted to create an evolving NFT which monitors its own transaction history, as well as that of an external smart contract address, the metadata would look like this: ``` "uses": { "transactions": [ "own", "addr1wywukn5q6lxsa5uymffh2esuk8s8fel7a0tna63rdntgrysv0f3ms" ] } ``` Finally, we also provide the option to receive the transaction history for a specific token other than the NFT itself (generally this is intended to enable import of Oracle data or control data from an external source – although monitoring an address transaction history could also be used for that). When specifying an external token to monitor, you should do so via the token’s fingerprint as in this example: ``` "uses": { "transactions": [ "own", "asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j" ] } ``` #### The tokens key To enable modifier tokens - (that is, a token which you can hold alongside a Smart NFT which changes the Smart NFT's appearance or behaviour in some way); we provide a way for the Smart NFT to monitor the tokens held by a specific address. Similarly to the “transactions” key, the “tokens” key will also accept either a string or array. In this case we define the “own” keyword to mean the tokens held by the same stake key that currently holds the Smart NFT itself. For example, to create an evolvable NFT which also supports modifier tokens, the “uses” block would look like this: ``` "uses": { "transactions": "own", "tokens": "own" } ``` We could also monitor a particular smart contract address, for example if we wanted to see how many tokens were listed for sale on a marketplace. The following example creates an NFT that supports modifier tokens and also monitors the tokens held by a script address: ``` "uses": { "tokens": [ "own", "addr1wywukn5q6lxsa5uymffh2esuk8s8fel7a0tna63rdntgrysv0f3ms" ] } ``` #### The renderer key The idea behind the renderer key is to reduce code duplication in on-chain Javascript by moving the generative code part of the project into a single asset which is minted once in the policy. Each individual NFT within a project is then just a set of input parameters to the generative script - this totally removes the need to fill the metadata of every mint transaction with encoded HTML and Javascript, as is the case with many on-chain Javascript NFTs now. When a Smart NFT is encountered which specifies another asset as the renderer, the site rendering the NFT should look-up the referenced asset and render that - the rendering token will then be responsible for reading the appropriate information via the Javascript API below and changing its appearance and/or behaviour based on that. In its simplest form, the rendering token could simply read the current token fingerprint and use that to seed a random number generator - this would enable a generative project to mint NFTs without even changing anything in the metadata and still have the renderer change its appearance for each one. In practice though, it's probably cooler to put actual traits like "colour scheme" or "movement speed" into the metadata and then have the renderer change its behaviour based on that. Via the Javascript API, the rendering token will always receive the properties of the child token which specified it as its renderer. This means if you wish to use a renderer with a token which also evolves based on its own transaction history, you will need to specify both "renderer" and "transactions" keys within the child token, and within the renderer token you do not need to specify these keys. For example, to create a Smart NFT which is rendered by another token, and is also evolvable based on its own transaction history, the "uses" key would look like this: ``` "uses": { "transactions": "own", "renderer": "asset1frc5wn889lcmj5y943mcn7tl8psk98mc480v3j" } ``` ### The Javascript API When an on-chain Javascript NFT is rendered which specifies any of the metadata options above, the website / dApp / wallet which creates the `