├── templates
    ├── home.hbs
    ├── cip.hbs
    ├── table-of-contents.hbs
    ├── cips.hbs
    └── main.hbs
├── .gitignore
├── CIP-0001
    ├── CIP_Flow.png
    └── README.md
├── BiweeklyMeetings
    ├── sequence_diagram.png
    ├── 09-08-2020.md
    ├── 08-04-2020.md
    ├── 07-01-2020.md
    ├── 08-25-2020.md
    ├── 08-11-2020.md
    ├── 10-20-2020.md
    ├── 10-06-2020.md
    ├── 07-15-2020.md
    ├── 09-22-2020.md
    ├── 11-17-2020.md
    ├── 11-03-2020.md
    ├── 12-08-2020.md
    └── 01-26-2021.md
├── scripts
    ├── serve.js
    └── build.js
├── package.json
├── CIP-0010
    ├── registry.json
    ├── registry.schema.json
    └── CIP-0010.md
├── CIP-0003
    ├── Byron.md
    ├── Icarus.md
    ├── Ledger.md
    └── CIP-0003.md
├── CIP-0012
    ├── schema.json
    └── CIP-0012.md
├── CIP-0011
    └── CIP-0011.md
├── CIP-1852
    └── CIP-1852.md
├── cip-template.md
├── README.md
├── CIP-1853
    └── CIP-1853.md
├── CIP-0007
    ├── rewards.php
    └── CIP-0007.md
├── CIP-0015
    └── CIP-0015.md
├── CIP-0013
    └── CIP-0013.md
├── assets
    ├── images
    │   └── logo.svg
    └── css
    │   └── styles.css
├── CIP-0004
    └── CIP-0004.md
└── CIP-0005
    ├── CIP-0005.md
    └── LICENSE


/templates/home.hbs:
--------------------------------------------------------------------------------
1 | {{#> main }}
2 | {{{readme.html}}}
3 | {{/main}}


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | /public
2 | /node_modules
3 | 
4 | # Mac files
5 | .DS_Store


--------------------------------------------------------------------------------
/CIP-0001/CIP_Flow.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fivebinaries/CIPs/master/CIP-0001/CIP_Flow.png


--------------------------------------------------------------------------------
/BiweeklyMeetings/sequence_diagram.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/fivebinaries/CIPs/master/BiweeklyMeetings/sequence_diagram.png


--------------------------------------------------------------------------------
/CIP-0001/README.md:
--------------------------------------------------------------------------------
1 | # Cardano Improvement Proposal 1 
2 | 
3 | 
4 | This directory contains all files pertaining to **CIP 1 - "CIP process"**  
5 | 
6 | Please refer to [CIP-0001.md](./CIP-0001.md). 
7 |   
8 | 


--------------------------------------------------------------------------------
/templates/cip.hbs:
--------------------------------------------------------------------------------
1 | {{#> main }}
2 | <h1>CIP {{cip.data.CIP}} - {{cip.data.Title}}</h1>
3 | <div id='toc_container'>
4 |   <p class='toc_title'>Contents</p>
5 |   {{> table-of-contents items=cip.tableOfContents}}
6 | </div>
7 | {{{cip.html}}}
8 | {{/main}}


--------------------------------------------------------------------------------
/scripts/serve.js:
--------------------------------------------------------------------------------
1 | const path = require('path')
2 | const express = require('express')
3 | const app = express()
4 | 
5 | app.use(express.static(path.join(__dirname, '..', 'public')))
6 | app.listen(5000, 'localhost')
7 | console.log('listening on http://localhost:5000')
8 | 


--------------------------------------------------------------------------------
/templates/table-of-contents.hbs:
--------------------------------------------------------------------------------
 1 | {{#if items.length}}
 2 |   <ul>
 3 |     {{#each items as |item|}}
 4 |       <li>
 5 |         <a href='#{{item.id}}'>{{item.label}}</a>
 6 |         {{> table-of-contents items=item.children }}
 7 |       </li>
 8 |     {{/each}}
 9 |   </ul>
10 | {{/if}}


--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
 1 | {
 2 |   "name": "quick-and-nasty",
 3 |   "version": "1.0.0",
 4 |   "description": "",
 5 |   "main": "index.js",
 6 |   "scripts": {
 7 |     "test": "echo \"Error: no test specified\" && exit 1",
 8 |     "build": "node ./scripts/build.js",
 9 |     "serve": "node ./scripts/serve.js"
10 |   },
11 |   "author": "",
12 |   "license": "ISC",
13 |   "dependencies": {
14 |     "express": "^4.17.1",
15 |     "gray-matter": "^4.0.2",
16 |     "handlebars": "^4.7.6",
17 |     "handlebars-dateformat": "^1.1.1",
18 |     "moment": "^2.26.0",
19 |     "rimraf": "^3.0.2",
20 |     "showdown": "^1.9.1"
21 |   }
22 | }
23 | 


--------------------------------------------------------------------------------
/templates/cips.hbs:
--------------------------------------------------------------------------------
 1 | {{#> main }}
 2 | <h1>{{type}}</h1>
 3 |     <table>
 4 |       <tr>
 5 |       <th>Number</th>
 6 |       <th>Title</th>
 7 |       <th>Created</th>
 8 |       <th>Authors</th>
 9 |       <th>Status</th>
10 |       </tr>
11 |       {{#each cips as |cip|}}
12 |       <tr>
13 |         <td><a href='/cips/cip{{cip.data.CIP}}'>CIP {{cip.data.CIP}}</a></td>
14 |         <td>{{{cip.data.Title}}}</td>
15 |         <td>{{dateFormat cip.data.Created "DD MMMM YYYY"}}</td>
16 |         <td>
17 |           {{{getAuthors cip.data.Authors}}}
18 |         </td>
19 |         <td>{{cip.data.Status}}</td>
20 |       </tr>
21 |       {{/each}}
22 |     </table>
23 | {{/main}}


--------------------------------------------------------------------------------
/CIP-0010/registry.json:
--------------------------------------------------------------------------------
 1 | [
 2 |   {
 3 |     "transaction_metadatum_label": 1967,
 4 |     "description": "nut.link metadata oracles registry"
 5 |   },
 6 |   {
 7 |     "transaction_metadatum_label": 1968,
 8 |     "description": "nut.link metadata oracles data points"
 9 |   },
10 |   {
11 |     "transaction_metadatum_label": 6770,
12 |     "description": "fortunes.coconutpool.com fortune teller"
13 |   },
14 |   {
15 |     "transaction_metadatum_label": 61284,
16 |     "description": "CIP-0015 - Catalyst registration"
17 |   },
18 |   {
19 |     "transaction_metadatum_label": 61285,
20 |     "description": "CIP-0015 - Catalyst registration"
21 |   },
22 |   {
23 |     "transaction_metadatum_label": 61286,
24 |     "description": "CIP-0015 - Catalyst registration"
25 |   }
26 | ]
27 | 


--------------------------------------------------------------------------------
/templates/main.hbs:
--------------------------------------------------------------------------------
 1 | <!DOCTYPE html>
 2 | <html>
 3 | <head>
 4 |   <link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400&display=swap" rel="stylesheet">
 5 |   <link rel="stylesheet" type="text/css" href="/assets/css/styles.css">
 6 |   <title>{{title}}</title>
 7 | </head>
 8 | <body>
 9 |   <header>
10 |     <a href="/" class="brand">
11 |       <img class="logo" src="/assets/images/logo.svg" />
12 |       <h1>Cardano Improvement Proposals</h1>
13 |     </a>
14 |     <ul>
15 |       {{#each headerData as |headerLink|}}
16 |         <li><a href='{{headerLink.path}}'><button>{{headerLink.label}}</button></a></li>
17 |       {{/each}}
18 |     </ul>
19 |   </header>
20 |   <hr />
21 |   <div class="content">
22 |     {{> @partial-block }}
23 |   </div>
24 |   <hr />
25 | </body>
26 | </html>


--------------------------------------------------------------------------------
/CIP-0003/Byron.md:
--------------------------------------------------------------------------------
 1 | # Byron key format
 2 | 
 3 | - **Deprecated**: yes
 4 | - **Summary**: used by old versions of Daedalus to generate addresses starting with `Ddz`.
 5 | 
 6 | ## Code
 7 | 
 8 | ```js
 9 | function generateMasterKey(seed) {
10 |     return hashRepeatedly(seed, 1);
11 | }
12 | 
13 | function hashRepeatedly(key, i) {
14 |     (iL, iR) = HMAC
15 |         ( hash=SHA512
16 |         , key=key
17 |         , message="Root Seed Chain " + UTF8NFKD(i)
18 |         );
19 | 
20 |     let prv = tweakBits(SHA512(iL));
21 | 
22 |     if (prv[31] & 0b0010_0000) {
23 |         return hashRepeatedly(key, i+1);
24 |     }
25 | 
26 |     return (prv + iR);
27 | }
28 | 
29 | function tweakBits(data) {
30 |     // * clear the lowest 3 bits
31 |     // * clear the highest bit
32 |     // * set the highest 2nd bit
33 |     data[0]  &= 0b1111_1000;
34 |     data[31] &= 0b0111_1111;
35 |     data[31] |= 0b0100_0000;
36 | 
37 |     return data;
38 | }
39 | ```
40 | ## Test vectors
41 | 
42 | <details>
43 |   <summary>Requires no iteration</summary>
44 | 
45 |   recovery phrase
46 |   ```
47 |   roast crime bounce convince core happy pitch safe brush exit basic among
48 |   ```
49 | 
50 |   master key
51 |   ```
52 |   60f6e2b12f4c51ed2a42163935fd95a6c39126e88571fe5ffd0332a4924e5e5e9ceda72e3e526a625ea86d16151957d45747fff0f8fcd00e394b132155dfdfc2918019cda35f1df96dd5a798da4c40a2f382358496e6468e4e276db5ec35235f
53 |   ```
54 | </details>
55 | 
56 | ---
57 | 
58 | <details>
59 |   <summary>Requires 4 iterations</summary>
60 | 
61 |   recovery phrase
62 |   ```
63 |   legend dismiss verify kit faint hurdle orange wine panther question knife lion
64 |   ```
65 | 
66 |   master key
67 |   ```
68 |   c89fe21ec722ee174be77d7f91683dcfd307055b04613f064835bf37c58f6a5f362a4ce30a325527ff66b6fbaa43e57c1bf14edac749be3d75819e7759e9e6c82b264afa7c1fd5b3cd51be3053ccbdb0224f82f7d1c7023a96ce97cb4efca945
69 |   ```
70 | </details>
71 | 


--------------------------------------------------------------------------------
/CIP-0003/Icarus.md:
--------------------------------------------------------------------------------
 1 | # Icarus key format
 2 | 
 3 | - **Deprecated**: no
 4 | - **Summary**: Used by Yoroi during the Byron-era (with Byron-style addresses starting with Ae2). Currently used for all Shelley-era wallets.
 5 | 
 6 | *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.
 7 | 
 8 | ## Code
 9 | 
10 | ```js
11 | function generateMasterKey(seed, password) {
12 |     let data = PBKDF2
13 |         ( kdf=HMAC-SHA512
14 |         , iter=4096
15 |         , salt=seed
16 |         , password=password
17 |         , outputLen=96
18 |         );
19 | 
20 |     return tweakBits(data);
21 | }
22 | 
23 | function tweakBits(data) {
24 |     // on the ed25519 scalar leftmost 32 bytes:
25 |     // * clear the lowest 3 bits
26 |     // * clear the highest bit
27 |     // * clear the 3rd highest bit
28 |     // * set the highest 2nd bit
29 |     data[0]  &= 0b1111_1000;
30 |     data[31] &= 0b0001_1111;
31 |     data[31] |= 0b0100_0000;
32 | 
33 |     return data;
34 | }
35 | ```
36 | ## Test vectors
37 | 
38 | <details>
39 |   <summary>No passphrase</summary>
40 | 
41 |   recovery phrase
42 |   ```
43 |   eight country switch draw meat scout mystery blade tip drift useless good keep usage title
44 |   ```
45 | 
46 |   master key
47 |   ```
48 |   c065afd2832cd8b087c4d9ab7011f481ee1e0721e78ea5dd609f3ab3f156d245d176bd8fd4ec60b4731c3918a2a72a0226c0cd119ec35b47e4d55884667f552a23f7fdcd4a10c6cd2c7393ac61d877873e248f417634aa3d812af327ffe9d620
49 |   ```
50 | </details>
51 | 
52 | ---
53 | 
54 | <details>
55 |   <summary>With passphrase</summary>
56 | 
57 |   recovery phrase
58 |   ```
59 |   eight country switch draw meat scout mystery blade tip drift useless good keep usage title
60 |   ```
61 | 
62 |   passphrase
63 |   ```
64 |   foo (as utf8 bytes)
65 |   ```
66 | 
67 |   master key
68 |   ```
69 |   70531039904019351e1afb361cd1b312a4d0565d4ff9f8062d38acf4b15cce41d7b5738d9c893feea55512a3004acb0d222c35d3e3d5cde943a15a9824cbac59443cf67e589614076ba01e354b1a432e0e6db3b59e37fc56b5fb0222970a010e
70 |   ```
71 | </details>
72 | 
73 | ## Trezor
74 | 
75 | When used < 24 words, the algorithm is the same as **Icarus**
76 | 
77 | When using 24 words, **TODO**
78 | 
79 | *Note*: Trezor also allows users to set an additional [passphrase](https://wiki.trezor.io/Passphrase) that works exactly the same as Icarus passphrase
80 | 


--------------------------------------------------------------------------------
/CIP-0010/registry.schema.json:
--------------------------------------------------------------------------------
 1 | {
 2 |     "$schema": "http://json-schema.org/draft-07/schema",
 3 |     "$id": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0010/CIP-0010.md",
 4 |     "type": "array",
 5 |     "title": "Transaction Metadata Label Registry",
 6 |     "description": "JSON schema for transaction metadata label registry",
 7 |     "default": [],
 8 |     "examples": [
 9 |         [
10 |             {
11 |                 "transaction_metadatum_label": 1967,
12 |                 "description": "nut.link metadata oracles registry"
13 |             },
14 |             {
15 |                 "transaction_metadatum_label": 1968,
16 |                 "description": "nut.link metadata oracles data points"
17 |             }
18 |         ]
19 |     ],
20 |     "additionalItems": false,
21 |     "items": {
22 |         "$id": "#/items",
23 |         "anyOf": [
24 |             {
25 |                 "$id": "#/items/anyOf/0",
26 |                 "type": "object",
27 |                 "title": "The first anyOf schema",
28 |                 "description": "An entry in the transaction metadata label registry",
29 |                 "default": {},
30 |                 "examples": [
31 |                     {
32 |                         "transaction_metadatum_label": 1967,
33 |                         "description": "nut.link metadata oracles registry"
34 |                     }
35 |                 ],
36 |                 "required": [
37 |                     "transaction_metadatum_label",
38 |                     "description"
39 |                 ],
40 |                 "properties": {
41 |                     "transaction_metadatum_label": {
42 |                         "$id": "#/items/anyOf/0/properties/transaction_metadatum_label",
43 |                         "type": "integer",
44 |                         "title": "The transaction_metadatum_label number",
45 |                         "default": 0,
46 |                         "examples": [
47 |                             1967
48 |                         ]
49 |                     },
50 |                     "description": {
51 |                         "$id": "#/items/anyOf/0/properties/description",
52 |                         "type": "string",
53 |                         "title": "The metadatum label description",
54 |                         "default": "",
55 |                         "examples": [
56 |                             "nut.link metadata oracles registry"
57 |                         ]
58 |                     }
59 |                 },
60 |                 "additionalProperties": true
61 |             }
62 |         ]
63 |     }
64 | }


--------------------------------------------------------------------------------
/CIP-0010/CIP-0010.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 10
 3 | Title: Transaction Metadata Label Registry
 4 | Authors: Sebastien Guillemot <sebastien@emurgo.io>
 5 | Comments-URI: https://forum.cardano.org/t/cip10-transaction-metadata-label-registry/41746
 6 | Status: Draft
 7 | Type: Standards
 8 | Created: 2020-10-31
 9 | License: CC-BY-4.0
10 | ---
11 | 
12 | ## Abstract
13 | 
14 | 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.
15 | 
16 | ## Terminology
17 | 
18 | 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
19 | 
20 | ```
21 | transaction_metadatum =
22 |     { * transaction_metadatum => transaction_metadatum }
23 |   / [ * transaction_metadatum ]
24 |   / int
25 |   / bytes .size (0..64)
26 |   / text .size (0..64)
27 | 
28 | transaction_metadatum_label = uint
29 | 
30 | transaction_metadata =
31 |   { * transaction_metadatum_label => transaction_metadatum }
32 | ```
33 | 
34 | ## Motivation
35 | 
36 | 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:
37 | 
38 | 1) Fast lookup for nodes to query all transactions containing metadata that uses a specific key
39 | 2) Allows a single transaction to include multiple metadata entries for different standards
40 | 
41 | Creating a registry for `transaction_metadatum_label` values has the following benefit:
42 | 
43 | 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
44 | 2) It makes it easy to avoid collisions with other standards that use transaction metadata
45 | 
46 | ## Specification
47 | 
48 | These are the reserved `transaction_metadatum_label` values
49 | 
50 | `transaction_metadatum_label` | description
51 | ----------------------------  | -----------------------
52 | 0 - 15                        | reserved\*
53 | 65536 - 131071                | reserved - private use
54 | 
55 | For the registry itself, please see [registry.json](./registry.json) in the machine-readable format. Please open your pull request against
56 | this file.
57 | 
58 | \* It's best to avoid using `0` or any a similar number like `1` that other people are very likely to use. Prefer instead to generate a random number
59 | 
60 | ## Copyright
61 | 
62 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
63 | 


--------------------------------------------------------------------------------
/CIP-0012/schema.json:
--------------------------------------------------------------------------------
 1 | {
 2 |   "$schema": "http://json-schema.org/draft-07/schema",
 3 |   "$id": "https://github.com/cardano-foundation/CIPs/blob/master/CIP-0012/CIP-0012.md",
 4 |   "type": "object",
 5 |   "title": "CIP12",
 6 |   "description": "Transaction metadata schema for CIP12",
 7 |   "patternProperties": {
 8 |     "^199{0,1}$": {
 9 |       "type": "array",
10 |       "items": [ {
11 |           "type": "object",
12 |           "patternProperties": {
13 |             "^[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*$": {
14 |                 "type": "object",
15 |                 "required": [
16 |                     "title",
17 |                     "content"
18 |                 ],
19 |                 "properties": {
20 |                     "title": {
21 |                         "$id": "#/properties/title",
22 |                         "type": "string",
23 |                         "title": "Title",
24 |                         "description": "Title of the communication.",
25 |                         "maxLength": 64,
26 |                         "examples": [
27 |                             "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do"
28 |                         ]
29 |                     },
30 |                     "content": {
31 |                         "$id": "#/properties/content",
32 |                         "type": "array",
33 |                         "title": "Content",
34 |                         "description": "Content of the communication in chunks",
35 |                         "items": [
36 |                           {
37 |                             "type": "string",
38 |                             "maxLength": 64
39 |                           }
40 |                         ],
41 |                         "examples": [
42 |                             [
43 |                               "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do ",
44 |                               "eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e",
45 |                               "nim ad minim veniam, quis nostrud exercitation ullamco laboris."
46 |                             ]
47 |                         ]
48 |                     },
49 |                     "valid": {
50 |                       "$id": "#/properties/valid",
51 |                       "type": "integer",
52 |                       "title": "Validity",
53 |                       "description": "Slot number when the communication becomes valid",
54 |                       "examples": [
55 |                         10669033
56 |                       ]
57 |                     },
58 |                     "expire": {
59 |                         "$id": "#/properties/expire",
60 |                         "type": "integer",
61 |                         "title": "Expiration",
62 |                         "description": "Slot number when the communication expires",
63 |                         "examples": [
64 |                           10669033
65 |                         ]
66 |                     }
67 |                 },
68 |                 "additionalProperties": false
69 |             }
70 |           }
71 |       } ]
72 |     }
73 |   }
74 | }


--------------------------------------------------------------------------------
/CIP-0003/Ledger.md:
--------------------------------------------------------------------------------
  1 | # Ledger key format
  2 | 
  3 | - **Deprecated**: no
  4 | - **Summary**: Used by Ledger hardware wallets
  5 | 
  6 | *Note*: Ledger also allows users to set an additional [passphrase](https://support.ledger.com/hc/en-us/articles/115005214529-Advanced-passphrase-security)
  7 | 
  8 | ## Code
  9 | 
 10 | ```js
 11 | function generateMasterKey(seed, password) {
 12 |     let data = PBKDF2
 13 |         ( kdf=HMAC-SHA512
 14 |         , iter=2048
 15 |         , salt="mnemonic" + UTF8NFKD(password)
 16 |         , password=UTF8NFKD(spaceSeparated(toMnemonic(seed)))
 17 |         , outputLen=64
 18 |         );
 19 | 
 20 |     let cc = HMAC
 21 |         ( hash=SHA256
 22 |         , key="ed25519 seed"
 23 |         , message=UTF8NFKD(1) + seed
 24 |         );
 25 | 
 26 |     let (iL, iR) = hashRepeatedly(data);
 27 | 
 28 |     return (tweakBits(iL) + iR + cc);
 29 | }
 30 | 
 31 | function hashRepeatedly(message) {
 32 |     let (iL, iR) = HMAC
 33 |         ( hash=SHA512
 34 |         , key="ed25519 seed"
 35 |         , message=message
 36 |         );
 37 | 
 38 |     if (iL[31] & 0b0010_0000) { 
 39 |         return hashRepeatedly(iL + iR);
 40 |     }
 41 | 
 42 |     return (iL, iR);
 43 | }
 44 | 
 45 | function tweakBits(data) {
 46 |     // * clear the lowest 3 bits
 47 |     // * clear the highest bit
 48 |     // * set the highest 2nd bit
 49 |     data[0]  &= 0b1111_1000;
 50 |     data[31] &= 0b0111_1111;
 51 |     data[31] |= 0b0100_0000;
 52 | 
 53 |     return data;
 54 | }
 55 | ```
 56 | 
 57 | ## Test vectors
 58 | 
 59 | <details>
 60 |   <summary>No passphrase no iterations</summary>
 61 | 
 62 |   recovery phrase
 63 |   ```
 64 |   recall grace sport punch exhibit mad harbor stand obey short width stem awkward used stairs wool ugly trap season stove worth toward congress jaguar
 65 |   ```
 66 | 
 67 |   master key
 68 |   ```
 69 |   a08cf85b564ecf3b947d8d4321fb96d70ee7bb760877e371899b14e2ccf88658104b884682b57efd97decbb318a45c05a527b9cc5c2f64f7352935a049ceea60680d52308194ccef2a18e6812b452a5815fbd7f5babc083856919aaf668fe7e4
 70 |   ```
 71 | </details>
 72 | 
 73 | ---
 74 | 
 75 | <details>
 76 |   <summary>No passphrase with iterations</summary>
 77 | 
 78 |   recovery phrase
 79 |   ```
 80 |   correct cherry mammal bubble want mandate polar hazard crater better craft exotic choice fun tourist census gap lottery neglect address glow carry old business
 81 |   ```
 82 | 
 83 |   master key
 84 |   ```
 85 |   1091f9fd9d2febbb74f08798490d5a5727eacb9aa0316c9eeecf1ff2cb5d8e55bc21db1a20a1d2df9260b49090c35476d25ecefa391baf3231e56699974bdd46652f8e7dd4f2a66032ed48bfdffa4327d371432917ad13909af5c47d0d356beb
 86 |   ```
 87 | </details>
 88 | 
 89 | ---
 90 | 
 91 | <details>
 92 |   <summary>With passphrase</summary>
 93 | 
 94 |   recovery phrase
 95 |   ```
 96 |   abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon art
 97 |   ```
 98 | 
 99 |   passphrase
100 |   ```
101 |   foo (as utf8 bytes)
102 |   ```
103 | 
104 |   master key
105 |   ```
106 |   f053a1e752de5c26197b60f032a4809f08bb3e5d90484fe42024be31efcba7578d914d3ff992e21652fee6a4d99f6091006938fac2c0c0f9d2de0ba64b754e92a4f3723f23472077aa4cd4dd8a8a175dba07ea1852dad1cf268c61a2679c3890
107 |   ```
108 | </details>
109 | 


--------------------------------------------------------------------------------
/CIP-0011/CIP-0011.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 11
 3 | Title: Staking key chain for HD wallets
 4 | Authors: Sebastien Guillemot <sebastien@emurgo.io>, Matthias Benkort <matthias.benkort@iohk.io>
 5 | Comments-URI: https://forum.cardano.org/t/staking-key-chain-for-hd-wallets/41857
 6 | Status: Draft
 7 | Type: Standards
 8 | Created: 2020-11-04
 9 | License: CC-BY-4.0
10 | ---
11 | 
12 | ## Abstract
13 | 
14 | 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 [CIP1852](../CIP-1852)
15 | 
16 | ## Terminology
17 | 
18 | ### Meaning of *account*
19 | 
20 | The term "account" is unfortunately an overloaded term so we clarify all its uses here
21 | 
22 | #### 1) "Account" as a BIP44 derivation level
23 | 
24 | BIP44 uses the term "account" as one derivation level to mean the following
25 | 
26 | > This level splits the key space into independent user identities, so the wallet never mixes the coins across different accounts.
27 | To differentiate this from other usage, we sometimes refer to it as an `account'` (the bip32 notation) or a BIP44 Account.
28 | 
29 | #### 2) "Account" as a transaction model
30 | 
31 | 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.
32 | 
33 | ## Motivation
34 | 
35 | 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.
36 | 
37 | ## Specification
38 | 
39 | Recall that [CIP1852](../CIP-1852) specifies the following derivation path
40 | 
41 | ```
42 | m / purpose' / coin_type' / account' / chain / address_index
43 | ```
44 | 
45 | 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*
46 | 
47 | ### *address_index* value
48 | 
49 | We RECOMMEND wallets only use `address_index=0` for compatibility with existing software. This also avoids the need for staking key discovery.
50 | 
51 | 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.
52 | 
53 | *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.
54 | 
55 | ## Test vectors
56 | 
57 | recovery phrase
58 | ```
59 | prevent company field green slot measure chief hero apple task eagle sunset endorse dress seed
60 | ```
61 | 
62 | private key (including chaincode) for `m / 1852' / 1815' / 0' / 2 / 0`
63 | ```
64 | b8ab42f1aacbcdb3ae858e3a3df88142b3ed27a2d3f432024e0d943fc1e597442d57545d84c8db2820b11509d944093bc605350e60c533b8886a405bd59eed6dcf356648fe9e9219d83e989c8ff5b5b337e2897b6554c1ab4e636de791fe5427
65 | ```
66 | 
67 | reward address (with `network_id=1`)
68 | ```
69 | stake1uy8ykk8dzmeqxm05znz65nhr80m0k3gxnjvdngf8azh6sjc6hyh36
70 | ```
71 | 
72 | ## Copyright
73 | 
74 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)


--------------------------------------------------------------------------------
/CIP-1852/CIP-1852.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 1852
 3 | Title: HD (Hierarchy for Deterministic) Wallets for Cardano
 4 | Authors: Sebastien Guillemot <sebastien@emurgo.io>, Matthias Benkort <matthias.benkort@iohk.io>
 5 | Comments-URI: https://forum.cardano.org/t/cip1852-hd-wallets-for-cardano/41740
 6 | Status: Draft
 7 | Type: Standards
 8 | Created: 2019-10-28
 9 | License: CC-BY-4.0
10 | ---
11 | 
12 | ## Abstract
13 | 
14 | Cardano extends the [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) by adding new chains used for different purposes. This document outlines how key derivation is done and acts as a registry for different chains used by Cardano wallets.
15 | 
16 | ## Terminology
17 | 
18 | ### Derivation style
19 | 
20 | Cardano does not use [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) but actually uses [BIP32-Ed25519](https://raw.githubusercontent.com/input-output-hk/adrestia/master/user-guide/static/Ed25519_BIP.pdf). The `-Ed25519` suffix is often dropped in practice (ex: we say the Byron release of Cardano supports [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) but in reality this is BIP44-Ed25519).
21 | 
22 | The Byron implementation of Cardano uses `purpose = 44'` (note: this was already a slight abuse of notation because Cardano implements BIP44-Ed25519 and not standard BIP44).
23 | 
24 | There are two (incompatible) implementations of BIP32-Ed25519 in Cardano:
25 | 
26 | 1) HD Random (notably used initially in Daedalus)
27 | 2) HD Sequential (notably used initially in Icarus)
28 | 
29 | The difference is explained in more detail in [CIP3](../CIP-0003)
30 | 
31 | ## Motivation
32 | 
33 | For Cardano, we use a new purpose field `1852'` instead of `44'` like in BIP44. There are three main reasons for this:
34 | 
35 | 1) During the Byron-era, `44'` was used. Since Byron wallets use a different algorithm for generating addresses from public keys, using a different purpose type allows software to easily know which address generation algorithm given just the derivation path (ex: given `m / 44' / 1815' / 0' / 0 / 0`, wallet software would know to handle this as a Byron-era wallet and not a Shelley-era wallet).
36 | 2) Using a new purpose helps bring attention to the fact Cardano is using `BIP32-Ed25519` and not standard `BIP32`.
37 | 3) Using a new purpose allows us to extend this registry to include more Cardano-specific functionality in the future
38 | 
39 | `1852` was chosen as it is the year of death of Ada Lovelace (following the fact that the `coin_type` value for Cardano is `1815` for her year of birth)
40 | 
41 | ## Specification
42 | 
43 | Using `1852'` as the purpose field, we defined the following derivation path
44 | 
45 | ```
46 | m / purpose' / coin_type' / account' / chain / address_index
47 | ```
48 | 
49 | Example: `m / 1852' / 1815' / 0' / 0 / 0`
50 | 
51 | Here, `chain` can be the following
52 | 
53 | | Name           | Value | Description
54 | |----------------|-------|-------------
55 | | External chain | `0`   | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
56 | | Internal chain | `1`   | Same as defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)
57 | | Staking Key    | `2`   | See [CIP11](../CIP-0011)
58 | 
59 | Wallets **MUST** implement this new scheme using the master node derivation algorithm from Icarus with sequential addressing (see [CIP3](../CIP-0003) for more information)
60 | 
61 | ## Copyright
62 | 
63 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
64 | 


--------------------------------------------------------------------------------
/cip-template.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: <CIP number, or "?" before being assigned>  
 3 | Title: <CIP title; maximum 44 characters>  
 4 | Authors: <list of authors' real names and email address>  
 5 | Discussions-To: <URL or email address>  
 6 | Comments-Summary: <summary tone>  
 7 | Comments-URI: <links to wiki page for comments>  
 8 | Status: <Draft | Proposed | On Hold | Rejected | Active | Obsolete>  
 9 | Type: <Standards Track | Informational | Process>  
10 | Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>  
11 | * License: <abbreviation for approved license(s)>  
12 | * License-Code: <abbreviation for code under different approved license(s)>  
13 | * Post-History: <dates of postings to Cardano Dev Forum, or link to thread>  
14 | * Requires: <CIP number(s)>  
15 | * Replaces: <CIP number>  
16 | Superseded-By: <CIP number>
17 | ---
18 | This is the suggested template for new CIPs.
19 |   
20 | Note that a CIP number will be assigned by an editor. When opening a pull request to submit your CIP, please use an abbreviated title in the filename, cip-johndoe-banktheunbanked.md.
21 | 
22 | The title should be 44 characters or less.
23 | 
24 | ## Preamble
25 | 
26 | RFC 822 style headers containing metadata about the CIP, including the CIP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.
27 | 
28 | ## Simple Summary
29 | 
30 | If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the CIP.
31 | 
32 | ## Abstract
33 | 
34 | A short (~200 word) description of the technical issue being addressed.
35 | 
36 | ## Motivation
37 | 
38 | The motivation is critical for CIPs that want to change the Cardano protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the CIP solves. CIP submissions without sufficient motivation may be rejected outright.
39 | 
40 | ## Specification
41 | 
42 | The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations.
43 | 
44 | ## Rationale
45 | 
46 | The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during the discussion.
47 | 
48 |   
49 | 
50 | ## Backward Compatibility
51 | 
52 | All CIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The GIP must explain how the author proposes to deal with these incompatibilities. GIP submissions without a sufficient backward compatibility treatise may be rejected outright.
53 | 
54 | ## Test Cases
55 | 
56 | Test cases for implementation are mandatory for CIPs that are affecting consensus changes. Other CIPs can choose to include links to test cases if applicable.
57 | 
58 | ## Implementations
59 | 
60 | The implementations must be completed before any CIP is given status “Active”, but it need not be completed before the CIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.
61 | 
62 | ## Copyright
63 | 
64 |   
65 | 
66 | This CIP is licensed under Apache-2.0
67 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # Cardano Improvement Proposals (CIPs)
 2 | 
 3 | Cardano Improvement Proposals (CIPs) describe standards, processes; or provide general guidelines or information to the Cardano Community. It is a formal, technical communication process that exists off-chain. 
 4 | The current process is described in details in [CIP1 - "CIP Process"](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/CIP-0001.md).  
 5 | 
 6 | ### Current CIPs (as of 02/12/21) 
 7 | 
 8 | |#              |Title            | Status               |
 9 | | ----------------- |:----------------|:-------------------- |
10 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
11 | | 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
12 | | 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |
13 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
14 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
15 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
16 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
17 | | 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |
18 | | 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |
19 | | 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |
20 | | 12                 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |
21 | | 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |
22 | | 15                 | [Catalyst Registration Transaction](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0015)                | Draft   |
23 | | 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  
24 | | 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |   
25 | 
26 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
27 | 
28 | 
29 | ### CIP creation process as a Sequence Diagram  
30 | _"Alice has a Cardano idea she'd like to build more formally":_
31 | ![Mary interacting with community and editors for a Cardano Proposal](./BiweeklyMeetings/sequence_diagram.png?raw=true "sequence_diagram.png")
32 | 
33 | Extend or discuss ‘ideas’ in the [Developer Forums](https://forum.cardano.org/c/developers/cips/122), Cardano’s Official [Developer Telegram Group](https://t.me/CardanoDevelopersOfficial) or in #developers in Cardano Ambassadors Slack.  
34 | CIP 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.  
35 | 
36 | 


--------------------------------------------------------------------------------
/CIP-1853/CIP-1853.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 1853
 3 | Title: HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano
 4 | Authors: Rafael Korbas <rafael.korbas@vacuumlabs.com>
 5 | Comments-URI: https://forum.cardano.org/t/stake-pool-cold-keys-hd-derivation/43360
 6 | Status: Draft
 7 | Type: Standards
 8 | Created: 2020-12-14
 9 | License: CC-BY-4.0
10 | ---
11 | 
12 | ## Abstract
13 | 
14 | [CIP-1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/CIP-1852.md) establishes how Shelley-era hierarchical deterministic (HD) wallets should derive their keys. This document is a follow-up of this CIP specifying how stake pool cold keys should be derived.
15 | 
16 | ## Motivation
17 | 
18 | (Hierarchical) deterministic derivation of stake pool cold keys enables their restorability from a seed and most importantly, their management on hardware wallet devices. This in turn mitigates man-in-the middle attacks to which pool operators would otherwise be vulnerable if they managed their stake pool cold keys on a device not specifically hardened against alteration of the data to be signed/serialized without operator's explicit consent.
19 | 
20 | ## Specification
21 | 
22 | Using `1853'` as the purpose field, we define the following derivation path structure for stake pool cold keys.
23 | 
24 | ```
25 | m / purpose' / coin_type' / usecase' / cold_key_index'
26 | ```
27 | 
28 | Example: `m / 1853' / 1815' / 0' / 0'`
29 | 
30 | Here the `usecase` is currently fixed to `0'`.
31 | 
32 | Given that stake pool cold keys are cryptographically the same as wallet keys already covered in CIP-1852, the master node and subsequent child keys derivation **MUST** be implemented in the same way as specified for wallets in CIP-1852.
33 | 
34 | ## Rationale
35 | 
36 | ### Why introducing a new purpose?
37 | 
38 | Stake pools are not wallets and the core concept of "accounts" is not applicable to them, nor are they supposed to be related to a user's wallet in any meaningful way. Therefore treating stake pool cold keys as another "chain" within CIP-1852 specification would rather be a deviation from CIP-1852 than its logical extension. Hence we establish a separate purpose and path structure for stake pool cold keys, having their specifics and differences from standard "wallet" keys in mind.
39 | 
40 | ### Why keeping `coin_type` in the path?
41 | 
42 | `coin_type` is kept in order to remain consistent with the "parent" CIP-1852 and also to leave space for the possibility that some Cardano hard-fork/clone in the future would reuse this specification to derive their own stake pool cold keys.
43 | 
44 | ### `usecase` field
45 | 
46 | Similarly as we have the `chain` path component in CIP-1852 paths for different types of wallet keys, it's plausible that in the future, there could be multiple varieties of stake pools. One such example of a possible future extension of this CIP could be pools managed by a group of operators instead of a single operator, for which a separate set of stake pool cold keys, driven by this parameter, could make sense both from logical and security perspective.
47 | 
48 | ### Hardened derivation at `cold_key_index`
49 | 
50 | Each stake pool is supposed to be managed separately so there is currently no incentive to connect them via a parent public key.
51 | 
52 | ### Hardened derivation at `usecase`
53 | 
54 | We chose hardened derivation at the usecase index as there is no incentive to mix the stake pool cold keys with other potential usecases and if there was such incentive, it would most likely be more appropriate to create a separate usecase/purpose for that.
55 | 
56 | ## Copyright
57 | 
58 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
59 | 


--------------------------------------------------------------------------------
/CIP-0003/CIP-0003.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 3
 3 | Title: Wallet key generation
 4 | Authors: Matthias Benkort <matthias.benkort@iohk.io>, Sebastien Guillemot <sebastien@emurgo.io>
 5 | Comments-Summary: No comments yet.
 6 | Comments-URI: https://github.com/cardano-foundation/CIPs/wiki/Comments:CIP-0003
 7 | Status: Draft
 8 | Type: Standards
 9 | Created: 2020-05-07
10 | License: CC-BY-4.0
11 | ---
12 | 
13 | ## Abstract
14 | 
15 | 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).
16 | 
17 | This document outlines the various mapping algorithms used in the Cardano ecosystem.
18 | 
19 | ## Motivation
20 | 
21 | 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)
22 | 
23 | To this end, this document outlines all the relevant key generation algorithms used in the Cardano ecosystem.
24 | 
25 | ## Specification
26 | 
27 | ### Recovery Phrase (mnemonic) Generation
28 | 
29 | 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).
30 | 
31 | ### Hierarchical Deterministic Wallets
32 | 
33 | 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/master/user-guide/static/Ed25519_BIP.pdf). A reference implementation can be found [here](https://docs.rs/ed25519-bip32/)
34 | 
35 | ### Master Key Generation
36 | 
37 | The master key generation is the mean by which on turns an initial entropy into a secure cryptographic key.
38 | 
39 | More specifically, the generation is a function from an initial seed to an extended private key (abbrev. XPrv) composed of:
40 | 
41 | - 64 bytes: an extended Ed25519 secret key composed of:
42 |   - 32 bytes: Ed25519 curve scalar from which few bits have been tweaked according to ED25519-BIP32
43 |   - 32 bytes: Ed25519 binary blob used as IV for signing
44 | - 32 bytes: chain code for allowing secure child key derivation
45 | 
46 | #### History
47 | 
48 | Throughout the years, Cardano has used different styles of master key generation:
49 | 
50 | |  Name                         |  Used by         |  Address prefix in Byron |  Is deprecated? | Is Recommended? |
51 | |-------------------------------|------------------|--------------------------|-----------------|-----------------|
52 | |  [Byron](./Byron.md)          |  Daedalus        |  Ddz                     |  Yes            | No              |
53 | |  [Icarus](./Icarus.md)        |  Yoroi, Daedalus |  Ae2                     |  No             | Yes             |
54 | |  [Icarus-Trezor](./Icarus.md) |  Trezor          |  Ae2                     |  No             | No              |
55 | |  [Ledger](./Ledger.md)        |  Ledger          |  Ae2                     |  No             | No              |
56 | 
57 | # Rationale
58 | 
59 | This CIP is merely to document the existing standards and not to provide rationales for the various methods used.
60 | 
61 | However, you can learn more at the following links:
62 | 
63 | - [Adrestia documentation](https://input-output-hk.github.io/adrestia/docs/key-concepts/hierarchical-deterministic-wallets/)
64 | - [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md)
65 | - [SLIP-0023](https://github.com/satoshilabs/slips/blob/master/slip-0023.md)
66 | 
67 | ## Copyright
68 | 
69 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
70 | 


--------------------------------------------------------------------------------
/CIP-0007/rewards.php:
--------------------------------------------------------------------------------
 1 | <?php
 2 | 
 3 | $argc = count($argv);
 4 | 
 5 | if ($argc == 1) {
 6 |   // The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube root, 4 = fourth root, etc.
 7 |   $curve_roots = array(2, 3, 4);
 8 | 
 9 |   // Divisor of saturation that calculates the pledge where the curve crosses the line
10 |   $crossover_factors = array(10, 20, 50);
11 | } else if ($argc == 3) {
12 |   $curve_roots = array($argv[1]);
13 |   $crossover_factors = array($argv[2]);
14 | } else {
15 |   echo "Usage: php -f " . $argv[0] . " <curve_root> <crossover_factor>" . PHP_EOL;
16 |   echo "  curve_root:  The n-root curve exponent. 1 = linear, 2 = square root, 3 = cube root, etc." . PHP_EOL;
17 |   echo "               An integer greater than 0." . PHP_EOL;
18 |   echo "  crossover_factor: Divisor of saturation that calculates the pledge where the curve crosses the line." . PHP_EOL;
19 |   echo "                    A real number greater than or equal to 1." . PHP_EOL;
20 |   exit;
21 | }
22 | 
23 | // Assumptions
24 | $reserve = 14000000000;
25 | $total_stake = 31700000000;
26 | $fees = 0;
27 | 
28 | echo "Assumptions" . PHP_EOL;
29 | echo "Reserve: " . round($reserve / 1000000000, 1) . "b" . PHP_EOL;
30 | echo "Total stake: " . round($total_stake / 1000000000, 1) . "b" . PHP_EOL;
31 | echo "Tx fees: " . $fees . PHP_EOL;
32 | echo "Fully Saturated Pool" . PHP_EOL;
33 | 
34 | // Protocol parameters
35 | $k = 150;
36 | $rho = 0.0022;
37 | $a0 = 0.3;
38 | $tau = .05;
39 | 
40 | // Calculated values
41 | $R = (($reserve * $rho) + $fees) * (1 - $tau);
42 | $z0 = 1 / $k;
43 | $o = $z0; // for fully saturated pool
44 | $saturation = round($total_stake / $k);
45 | 
46 | echo "Rewards available in epoch: " . round($R / 1000000, 1) . "m" . PHP_EOL;
47 | echo "Pool saturation: " . round($saturation / 1000000, 1) . "m" . PHP_EOL;
48 | echo PHP_EOL;
49 | 
50 | // Pool pledge
51 | $pledges = array(0, 10000, 50000, 100000, 200000, 500000, 1000000, 2000000, 5000000, 10000000, 20000000, 50000000, 100000000, $saturation);
52 | 
53 | // Compare to zero pledge
54 | $comparison_pledge = 0;
55 | $comparison_s = $comparison_pledge / $total_stake;
56 | $comparison_rewards = round(($R / (1 + $a0)) * ($o + ($comparison_s * $a0 * (($o - ($comparison_s * (($z0 - $o) / $z0))) / $z0))));
57 | 
58 | foreach ($curve_roots as $curve_root) {
59 |   foreach ($crossover_factors as $crossover_factor) {
60 |     $crossover = $total_stake / ($k * $crossover_factor);
61 |     echo "Curve root: " . $curve_root . PHP_EOL;
62 |     echo "Crossover factor: " . $crossover_factor . PHP_EOL;
63 |     echo "Crossover: " . round($crossover / 1000000, 1) . "m" . PHP_EOL;
64 |     echo PHP_EOL;
65 | 
66 |     echo "Pledge\tRewards\tBenefit\tAlt Rwd\tAlt Bnft" . PHP_EOL;
67 | 
68 |     foreach ($pledges as $pledge) {
69 |       if ($pledge < 1000000) {
70 |         $pledge_str = round($pledge / 1000, 1) . "k";
71 |       } else {
72 |         $pledge_str = round($pledge / 1000000, 1) . "m";
73 |       }
74 | 
75 |       // Current Formula (same as alternate formula with curve_root = 1)
76 |       $s = $pledge / $total_stake;
77 |       $rewards = round(($R / (1 + $a0)) * ($o + ($s * $a0 * (($o - ($s * (($z0 - $o) / $z0))) / $z0))));
78 |       $benefit = round(((($rewards / $comparison_rewards) - 1) * 100), 2);
79 | 
80 |       $alt_numerator = pow($pledge, (1 / $curve_root)) * pow($crossover, (($curve_root - 1) / $curve_root));
81 |       $alt_s = $alt_numerator / $total_stake;
82 |       $alt_rewards = round(($R / (1 + $a0)) * ($o + ($alt_s * $a0 * (($o - ($alt_s * (($z0 - $o) / $z0))) / $z0))));
83 |       $alt_benefit = round(((($alt_rewards / $comparison_rewards) - 1) * 100), 2);
84 | 
85 |       echo $pledge_str . "\t" . $rewards . "\t" . $benefit . "%\t" . $alt_rewards . "\t" . $alt_benefit . "%" . PHP_EOL;
86 |     }
87 | 
88 |     echo PHP_EOL;
89 |   }
90 | }
91 | 
92 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/09-08-2020.md:
--------------------------------------------------------------------------------
 1 |  **Table of Contents:** 
 2 | 
 3 | - [Summary](#summary)
 4 | - [Editors Meeting Flow](#editors-meeting-flow)
 5 | - [September 08 2020 notes](#september-08-2020-notes)
 6 |   * [Triage](#triage)
 7 |   * [Last Check](#last-check)
 8 |   * [Review](#review)
 9 |       + [Extended Metadata](#Extended-Metadata)
10 |       + [Curve Pledge Benefit](#Curve-Pledge-Benefit)
11 |   * [Discussions](#discussions)
12 |   * [Close](#close)
13 | - [Extra](#extra)
14 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
15 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
16 |   * [Understanding CIPs further](#understanding-cips-further)
17 | 
18 | ## Summary
19 | 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.  
20 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
21 | </sub>
22 | 
23 | ## Editors Meeting Flow
24 | - [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..
25 | - [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)
26 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
27 | PR -> ‘Draft’: Needs format + approval.  
28 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
29 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
30 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
31 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
32 | 
33 | ## September 08 2020 notes
34 | **Attending**: (Duncan, Frederic, ~Matthias~, Sebastien) + Steve(CF) + Shawn, Markus, Mike (PR Authors) 
35 | 
36 | ### Triage
37 | N/A
38 | 
39 | ### Last Check
40 | N/A 
41 | 
42 | ### Review  
43 | 
44 | #### Extended Metadata
45 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
46 | 
47 | #### Curve Pledge Benefit
48 | ([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) 
49 | 
50 | ### Discussions 
51 | N/A - not enough time due to extended reviews.  
52 | 
53 | ### Close
54 | **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site  
55 | 
56 | ---
57 | ## Extra
58 | 
59 | ### Current CIPs in the CIP repository and their status 
60 | 
61 | |#              |Title            | Status               |
62 | | ----------------- |:----------------|:-------------------- |
63 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
64 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
65 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
66 | 
67 | 
68 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
69 | 
70 | 
71 | ### CIP creation process as a Sequence Diagram
72 | 
73 | _"Alice has a Cardano idea she'd like to build more formally":_
74 | 
75 | 
76 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
77 | 
78 | ### Understanding CIPs further
79 | 
80 | 
81 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
82 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
83 | 
84 | 
85 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/08-04-2020.md:
--------------------------------------------------------------------------------
 1 | **Table of Contents:** 
 2 | 
 3 | - [Summary](#summary)
 4 | - [Editors Meeting Flow](#editors-meeting-flow)
 5 | - [Aug 4 2020 notes](#august-4-2020-notes)
 6 |   * [Triage](#triage)
 7 |   * [Last Check](#last-check)
 8 |   * [Review](#review)
 9 |   * [Discussions](#discussions)
10 |   * [Close](#close)
11 | - [Extra](#extra)
12 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
13 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
14 |   * [Understanding CIPs further](#understanding-cips-further)
15 | ## Summary
16 | 
17 | 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.  
18 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
19 | </sub>
20 | 
21 | 
22 | ## Editors Meeting Flow
23 | - [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..
24 | - [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)
25 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
26 | PR -> ‘Draft’: Needs format + approval.  
27 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
28 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
29 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
30 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
31 | 
32 | 
33 | 
34 | ## Aug 4 2020 notes
35 | 
36 | 
37 | **Attending**: (Duncan, Frederic, ~~Matthias~~, ~~Sebastien~~) + Ben (CF)
38 | 
39 | 
40 | 
41 | ### Triage
42 | - Merge pr (copy tweak on CIP1)   
43 | 
44 | ### Last Check
45 | - Merge CIP2 (Draft)   
46 | - Merge CIP5 (Draft)   
47 | 
48 | ### Review  
49 | N/A  
50 | ### Discussions
51 | *(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')* 
52 | - Setup a CIP for protocol parameters (Ask Romain? Kevin / Alex) 
53 | - Review Meeting #2 notes in next meeting to continue threads
54 | - Need to upload some version of the notes in the CIP repository for visibility
55 | - should CIP 2&5 add License file and readme? 
56 | 
57 | ### Close
58 | - **CIP1** copy tweaks merged
59 | - **CIP2** merged as 'Draft'
60 | - **CIP5** merged as 'Draft'
61 | 
62 | (Close) 
63 | 
64 | 
65 | ---
66 | ## Extra
67 | 
68 | ### Current CIPs in the CIP repository and their status 
69 | 
70 | 
71 | |#              |Title            | Status               |
72 | | ----------------- |:----------------|:-------------------- |
73 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
74 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
75 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
76 | 
77 | 
78 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
79 | 
80 | 
81 | ### CIP creation process as a Sequence Diagram
82 | 
83 | _"Alice has a Cardano idea she'd like to build more formally":_
84 | 
85 | 
86 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
87 | 
88 | ### Understanding CIPs further
89 | 
90 | 
91 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
92 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
93 | 


--------------------------------------------------------------------------------
/CIP-0015/CIP-0015.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | CIP: 15
  3 | Title: Catalyst Registration Transaction Metadata Format
  4 | Authors: Sebastien Guillemot <sebastien@emurgo.io>, Rinor Hoxha <rinor.hoxha@iohk.io>, Mikhail Zabaluev <mikhail.zabaluev@iohk.io>
  5 | Comments-URI: https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038
  6 | Status: Draft
  7 | Type: Standards
  8 | Created: 2020-01-05
  9 | License: CC-BY-4.0
 10 | ---
 11 | 
 12 | ## Abstract
 13 | 
 14 | 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.
 15 | 
 16 | ## Motivation
 17 | 
 18 | Cardano uses a sidechain for its treasury system ("Catalyst"). 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".
 19 | 
 20 | 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.
 21 | 
 22 | We therefore need a registration transaction that serves three purposes:
 23 | 
 24 | 1. Registers a "voting key" to be included in the sidechain
 25 | 2. Associates mainnet ADA to this voting key
 26 | 3. Declare an address to receive Catalyst rewards
 27 | 
 28 | ## Specification
 29 | 
 30 | ### Voting key format
 31 | 
 32 | A voting key is simply an ED25519 key. How this key is created is up to the wallet.
 33 | 
 34 | ### Associating stake with a voting key
 35 | 
 36 | 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 [CIP8](../CIP-0008/CIP-0008.md)), the resulting data structure is a little excessive for on-chain metadata (which we want to keep small)
 37 | 
 38 | 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.
 39 | 
 40 | ### Registration metadata format
 41 | 
 42 | A Catalyst registration transaction are a regular Cardano transaction with a specific transaction metadata associated with it
 43 | 
 44 | Notably, there should be three entries inside the metadata map:
 45 | 
 46 | Voting key registration
 47 | ```
 48 | 61284: {
 49 |   // voting_key - CBOR byte array
 50 |   1: "0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663",
 51 |   // stake_pub - CBOR byte array
 52 |   2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee",
 53 |   // address - CBOR byte array
 54 |   3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4"
 55 | }
 56 | ```
 57 | 
 58 | Signing the voting public key with the staking private key
 59 | ```
 60 | 61285: {
 61 |   // signature - ED25119 signature CBOR byte array
 62 |   1: "0x8b508822ac89bacb1f9c3a3ef0dc62fd72a0bd3849e2381b17272b68a8f52ea8240dcc855f2264db29a8512bfcd522ab69b982cb011e5f43d0154e72f505f007"
 63 | }
 64 | ```
 65 | 
 66 | This corresponds to the following CDDL definition
 67 | 
 68 | ```
 69 | registration_cbor = {
 70 |   61284: key_registration
 71 | , 61285: registration_signature
 72 | }
 73 | 
 74 | $voting_pub_key /= bytes .size 32
 75 | $staking_pub_key /= bytes .size 32
 76 | $ed25519_signature /= bytes .size 64
 77 | $address /= bytes
 78 | 
 79 | key_registration = {
 80 |   1 : $voting_pub_key
 81 | , 2 : $staking_pub_key
 82 | , 3 : $address
 83 | }
 84 | 
 85 | registration_signature = {
 86 |   1 : $ed25519_signature
 87 | }
 88 | ```
 89 | 
 90 | Here an example using CBOR diagnostic notation
 91 | 
 92 | ```
 93 | {
 94 |   61284: {
 95 |     1: h'8253C95609BC62C0443276FE2A1872B87CB11C06185FFDBB56C7CE8352EEF2A3',
 96 |     2: h'345080C6DDFF7154B4ED4A622558AA0EAABD8CE7E2701C92B6858EA76DCECBCE'
 97 |   },
 98 |   61285: {
 99 |     1: h'7D88F34D778B7A4C76AA53FF5D9506DC5B92D25575B43AF75D66DC05082A2BCFF44FCEDDAB15DBA0C23C56A09A15367A9803E24A388AAFB8498EF72190407B0D'
100 |   }
101 | }
102 | ```
103 | 
104 | ## Changelog
105 | 
106 | Fund 3 added the `address` inside the `key_registration` field.
107 | 
108 | ## Copyright
109 | 
110 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
111 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/07-01-2020.md:
--------------------------------------------------------------------------------
  1 | **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [July 1 2020 notes](#july-1-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |     + [CIP2](#cip2)
 10 |   * [Discussions](#discussions)
 11 |   * [Close](#close)
 12 | - [Extra](#extra)
 13 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 14 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
 15 |   * [Understanding CIPs further](#understanding-cips-further)
 16 | ## Summary
 17 | 
 18 | 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.  
 19 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 20 | </sub>
 21 | 
 22 | 
 23 | ## Editors Meeting Flow
 24 | - [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..
 25 | - [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)
 26 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 27 | PR -> ‘Draft’: Needs format + approval.  
 28 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 29 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 30 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 31 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 32 | 
 33 | 
 34 | 
 35 | ## July 1 2020 notes
 36 | 
 37 | 
 38 | **Attending**: (Duncan, Sebastien, Frederic, Matthias) 
 39 | 
 40 | 
 41 | 
 42 | ### Triage
 43 | - Nothing to review yet!
 44 | ### Last Check
 45 | => **Action**: - merge PR (CIP1 copy tweak)
 46 | ### Review
 47 | #### CIP2 
 48 | > (Discussions already took place in that PR comments!)  
 49 | > A few items to change for the current CIP2 PR   
 50 | > 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) 
 51 | Add a query about if the algorithm is clear in presence of a min UTXO output.. (was it considered for Byron?)
 52 | > Possibly: remove “for Cardano” from the title  
 53 | 
 54 | 
 55 | 
 56 | ### Discussions
 57 | - Side conversations for how the Wallet work for Shelley key derivations (currently on the Adrestia user guide, might be worth moving to the CIP).   
 58 | - Other Qs regarding transaction Metadata (format allows for wide-range)...  
 59 | - (could/should be freeform?)   
 60 | - Describe a way of versioning metadata?   
 61 | - Need some agreement on namespace else it might lead to confusion.  
 62 | - CIP notes should be merged in post meeting in the CIP Repo - will be fleshed out in the coming week.  
 63 | 
 64 | 
 65 | ### Close
 66 | - CIP1 Copy tweak PR - to merge asap.  
 67 | - “Coin Selection Algorithms” PR agreed on, to be merged in as CIP2 ‘Draft’ if no issues next meeting (7/15)  
 68 | - Meeting notes (these) to be added to the CIP repo itself for visibility on process.  
 69 | 
 70 | 
 71 | (Close) 
 72 | 
 73 | 
 74 | ---
 75 | ## Extra
 76 | 
 77 | ### Current CIPs in the CIP repository and their status 
 78 | 
 79 | 
 80 | |#              |Title            | Status               |
 81 | | ----------------- |:----------------|:-------------------- |
 82 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
 83 | 
 84 | 
 85 | 
 86 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
 87 | 
 88 | 
 89 | ### CIP creation process as a Sequence Diagram
 90 | 
 91 | _"Alice has a Cardano idea she'd like to build more formally":_
 92 | 
 93 | 
 94 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
 95 | 
 96 | ### Understanding CIPs further
 97 | 
 98 | 
 99 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
100 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
101 | 


--------------------------------------------------------------------------------
/CIP-0013/CIP-0013.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | CIP: 13
 3 | Title: Cardano URI Scheme
 4 | Authors: Sebastien Guillemot <sebastien@emurgo.io>, Vicente Almonacid <vicente@emurgo.io>
 5 | Comments-URI:
 6 | - https://github.com/Emurgo/EmIPs/pull/2
 7 | - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457
 8 | Status: Draft
 9 | Type: Informational
10 | Created: 2020-10-20
11 | License: CC-BY-4.0
12 | ---
13 | 
14 | # Abstract
15 | 
16 | This proposal describes a basic URI scheme to handle ADA transfers, as well
17 | as possible approaches for a multiplatform implementation.
18 | 
19 | # Motivation
20 | 
21 | 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).
22 | 
23 | 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.
24 | 
25 | # Specification
26 | 
27 | 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:`)
28 | 
29 | Rationale:
30 | - Use `cardano:` over `ada:` as 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 - as opposed to a simple payment system)
31 | - Many wallets support multiple currencies. Following the same standard will ensure higher adoption of our protocol.
32 | 
33 | Example:
34 | ```
35 | <a href="web+cardano:Ae2tdPwUPEZ76BjmWDTS7poTekAvNqBjgfthF92pSLSDVpRVnLP7meaFhVd">Donate</a>
36 | ```
37 | 
38 | ## Considerations
39 | 
40 | 1. 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)
41 | 
42 | 2. Depending on the protocol registration method (see next section), browsers generally enforce a `web+` or `ext+` prefix for non-whitelisted protocols (note: `bitcoin:` was whitelisted). The prefix `ext+` is recommended for extensions, but not mandatory.
43 | 
44 | ## ABNF Grammar (Proposal)
45 | 
46 | This is an initial, simplified protocol definition for fast implementation; it only requires an address and an optional amount parameter. As discussed above, these rules are likely to evolve in time in order to support additional features, including unique capabilities of the Cardano blockchain.
47 | 
48 | ```
49 | cardanourn     = "web+cardano:" cardanoaddress [ "?" amountparam ]
50 | cardanoaddress = *(base58 | bech32)
51 | amountparam    = "amount=" *digit [ "." *digit ]
52 | ```
53 | 
54 | 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.
55 | 
56 | ## Security Considerations
57 | 
58 | 1. 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.
59 | 2. We should be wary of people who disguise “donate” links as actually opening up a phishing website that LOOKS like a wallet.
60 | 
61 | # Rationale
62 | 
63 | ## Why not use Universal links, deep links and other non-protocol-based Solution
64 | 
65 | 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.
66 | 
67 | ## Read More
68 | 
69 | https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
70 | 
71 | https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers
72 | 
73 | https://developer.android.com/training/app-links/deep-linking#adding-filters
74 | 
75 | https://facebook.github.io/react-native/docs/linking.html
76 | 
77 | https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app
78 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/08-25-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [August 25 2020 notes](#august-25-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |       + [CIP2](#cip2)
 10 |       + [CIP5](#cip5)
 11 |   * [Discussions](#discussions)
 12 |   * [Close](#close)
 13 | - [Extra](#extra)
 14 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 15 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
 16 |   * [Understanding CIPs further](#understanding-cips-further)
 17 | ## Summary
 18 | 
 19 | 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.  
 20 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 21 | </sub>
 22 | 
 23 | 
 24 | ## Editors Meeting Flow
 25 | - [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..
 26 | - [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)
 27 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 28 | PR -> ‘Draft’: Needs format + approval.  
 29 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 30 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 31 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 32 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 33 | 
 34 | 
 35 | 
 36 | ## August 25 2020 notes
 37 | 
 38 | 
 39 | **Attending**: (Duncan, Frederic, Matthias, ~~Sebastien~~) + Ben (CF)
 40 | 
 41 | 
 42 | 
 43 | ### Triage
 44 | N/A
 45 | 
 46 | ### Last Check
 47 | Merging in meeting notes to publicize the process itself
 48 | 
 49 | ### Review  
 50 | #### CIP2
 51 | > **Matthias** - This is a lengthy CIP and will benefit from a more thorough review. 
 52 | 
 53 | #### CIP5
 54 | > Discussion around currencies. Cardano does multi-asset by having a bundle. Address and tokens two separate entities.  
 55 | **Matthias** propose to remove addr in prefixes to keep consistency. Remove reference.  
 56 | **Duncan** will get rid of addr_bootstrap because it's confusing (can render a Byron address bip32 style). 
 57 | 
 58 | 
 59 | 
 60 | ### Discussions 
 61 | 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.  
 62 | 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).  
 63 | 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.
 64 | 4. **M**: For CIP structure, would prefer moving to only using the 'Readme.md' file and cutting the 'Cip#.md' file.  
 65 | **F**: Aligned - some delays might come due to auto-generated site. 
 66 | **M**: Not a blocker. Github keeps track of all.
 67 | 
 68 | ### Close
 69 | **TODO** Invite community members to upcoming meeting (**Frederic**)  
 70 | **On Hold** Change Format of CIPs (in CIP 1) (instead CIPx.md)  
 71 | **TODO** Probe IOG for promised parameter CIP (**Frederic**)  
 72 | (Close) 
 73 | 
 74 | ---
 75 | ## Extra
 76 | 
 77 | ### Current CIPs in the CIP repository and their status 
 78 | 
 79 | 
 80 | |#              |Title            | Status               |
 81 | | ----------------- |:----------------|:-------------------- |
 82 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
 83 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
 84 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
 85 | 
 86 | 
 87 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
 88 | 
 89 | 
 90 | ### CIP creation process as a Sequence Diagram
 91 | 
 92 | _"Alice has a Cardano idea she'd like to build more formally":_
 93 | 
 94 | 
 95 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
 96 | 
 97 | ### Understanding CIPs further
 98 | 
 99 | 
100 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
101 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
102 | 


--------------------------------------------------------------------------------
/CIP-0007/CIP-0007.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | CIP: 7
  3 | Title: Curve Pledge Benefit
  4 | Authors: Shawn McMurdo <shawn_mcmurdo@yahoo.com>
  5 | Discussions-To: 
  6 | Comments-Summary: 
  7 | Comments-URI: 
  8 | Status: Draft
  9 | Type: Standards
 10 | Created: 2020-08-11
 11 | License: Apache 2.0
 12 | Post-History: https://forum.cardano.org/t/protocol-parameters-pledge-and-sybil-resistance/35100 and https://github.com/input-output-hk/cardano-node/issues/1518
 13 | ---
 14 | 
 15 | ## Summary
 16 | 
 17 | Use a n-root curve instead of current linear a0 pledge benefit factor in the rewards equation.
 18 | 
 19 | ## Abstract
 20 | 
 21 | 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.
 22 | This also reduces the unfortunate side effect in the current equation that over rewards private pools which provide no additional security benefit.
 23 | 
 24 | ## Motivation
 25 | 
 26 | There are two main reasons for changing the current linear a0 pledge benefit factor in the rewards equation.
 27 | 
 28 | 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.
 29 | 
 30 | 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?
 31 | 
 32 | ## Specification
 33 | 
 34 | This is a modification of the maxPool function defined in section 11.8 Rewards Distribution Calculation of “A Formal Specification of the Cardano Ledger”.
 35 | 
 36 | maxPool = (R / (1 + a0)) * (o + (s * a0 * ((o - (s * ((z0 - o) / z0))) / z0)))
 37 | 
 38 | where:
 39 | R = ((reserve * rho) + fees) * (1 - tau)
 40 | o = min(pool_stake / total_stake, z0) = z0 for fully saturated pool
 41 | s = pledge / total_stake
 42 | z0 = 1 / k
 43 | and the following are current protocol parameters:
 44 | k = 150
 45 | rho = 0.0022
 46 | a0 = 0.3
 47 | tau = .05
 48 | 
 49 | The idea is to replace s in the above equation with an n-root curve expression of pledge rather than the linear pledge value.
 50 | 
 51 | 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.
 52 | Because the a0 pledge benefit is spread over the pledge range from 0 to saturation there is a dependence on k and total_stake.
 53 | 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:
 54 | 
 55 | crossover = total_stake / (k * crossover_factor)
 56 | 
 57 | where crossover_factor is any real number greater than or equal to 1.
 58 | So crossover_factor is essentially a divisor of the pool saturation amount.
 59 | For example, setting crossover_factor to 20 with k = 150 and total_stake = 31 billion gives a crossover of approximately 10.3 million.
 60 | 
 61 | Also, we can parameterize the n-root curve exponent.
 62 | This gives us:
 63 | 
 64 | s = pow(pledge, (1 / curve_root)) * pow(crossover, ((curve_root - 1) / curve_root)) / total_stake
 65 | 
 66 | The curve_root could be set to any integer greater than 0 and when set to 1 produces the current rewards equation.
 67 | The curve_root is n in n-root. For example, 1 = linear, 2 = square root, 3 = cube root, 4 = fourth root, etc.
 68 | 
 69 | 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.
 70 | 
 71 | ## Rationale
 72 | 
 73 | 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.
 74 | 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.
 75 | This modification maintains the general principles of the current rewards equation and does not introduce any hard limits.
 76 | It improves the incentives that were originally designed to make them more meaningful for the majority of pool operators.
 77 | 
 78 | ## Backward Compatibility
 79 | 
 80 | This proposal is backwards compatible with the current reward function by setting the curve_root parameter to 1.
 81 | 
 82 | ## Test Cases
 83 | 
 84 | 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.
 85 | For usage, run "php -f rewards.php help".
 86 | 
 87 | An interesting set of parameters as an example is:
 88 | 
 89 | curve_root = 3
 90 | crossover_factor = 8
 91 | 
 92 | Running "php -f rewards.php 3 8" produces:
 93 | 
 94 | Assumptions
 95 | Reserve: 14b
 96 | Total stake: 31.7b
 97 | Tx fees: 0
 98 | Fully Saturated Pool
 99 | Rewards available in epoch: 29.3m
100 | Pool saturation: 211.3m
101 | 
102 | Curve root: 3
103 | Crossover factor: 8
104 | Crossover: 26.4m
105 | 
106 | Pledge	Rewards	Benefit	Alt Rwd	Alt Bnft
107 | 0k	150051	0%	150051	0%
108 | 10k	150053	0%	150458	0.27%
109 | 50k	150062	0.01%	150747	0.46%
110 | 100k	150073	0.01%	150928	0.58%
111 | 200k	150094	0.03%	151156	0.74%
112 | 500k	150158	0.07%	151551	1%
113 | 1m	150264	0.14%	151941	1.26%
114 | 2m	150477	0.28%	152432	1.59%
115 | 5m	151116	0.71%	153282	2.15%
116 | 10m	152181	1.42%	154122	2.71%
117 | 20m	154311	2.84%	155180	3.42%
118 | 50m	160702	7.1%	157012	4.64%
119 | 100m	171352	14.2%	158821	5.84%
120 | 211.3m	195067	30%	161305	7.5%
121 | 
122 | As you can see this gives meaningful pledge benefit rewards to pools pledging less than 1m ADA.
123 | 
124 | ## Implementations
125 | 
126 | If someone will show me where the current maxPool reward equation is implemented in the code, I could produce an implementation of this change as a pull request.
127 | 
128 | ## Copyright
129 | 
130 | Copyright 2020 Shawn McMurdo
131 | 
132 | This CIP is licensed under the Apache-2.0 license.
133 | 
134 | 


--------------------------------------------------------------------------------
/scripts/build.js:
--------------------------------------------------------------------------------
  1 | const matter = require('gray-matter')
  2 | const fs = require('fs')
  3 | const path = require('path')
  4 | const rimraf = require('rimraf')
  5 | const handlebars = require('handlebars')
  6 | const showdown = require('showdown')
  7 | const converter = new showdown.Converter({ tables: true })
  8 | 
  9 | const publicPath = path.join(__dirname, '..', 'public')
 10 | const templates = {}
 11 | 
 12 | handlebars.registerHelper('dateFormat', require('handlebars-dateformat'));
 13 | 
 14 | handlebars.registerHelper('getAuthors', function(Authors) {
 15 |   return Authors.split(',').map(author => {
 16 |     const [_, name, link] = author.trim().match(/^([^<]+)<?([^>]+)?>?$/) || []
 17 |     let type = 'url'
 18 |     if (link.match(/^[^@]+@[^@]+$/)) {
 19 |       type = 'email'
 20 |     }
 21 |     const authorLink = type === 'email' ? 'mailto:' + link : link
 22 |     const authorName = name.trim()
 23 | 
 24 |     return ' ' + '<a href="' + authorLink + '" alt="' + authorLink + '">' + authorName + '</a>'
 25 |   })
 26 | });
 27 | 
 28 | handlebars.registerHelper("debug", function(optionalValue) {
 29 |   console.log("Current Context");
 30 |   console.log("====================");
 31 |   console.log(this);
 32 | 
 33 |   if (optionalValue) {
 34 |     console.log("Value");
 35 |     console.log("====================");
 36 |     console.log(optionalValue);
 37 |   }
 38 | });
 39 | 
 40 | function getTableOfContents (lines, { children = [], headingType = -1 } = {}) {
 41 |   while (lines.length > 0) {
 42 |     const line = lines.shift()
 43 |     const heading = line.match(/^([#]{1,})\s([^\n]+)$/)
 44 |     if (heading) {
 45 |       const type = heading[1].length === 1 ? 1 : heading[1].length - 1
 46 | 
 47 |       if (type > headingType) {
 48 |         const branch = {
 49 |           label: heading[2],
 50 |           id: heading[2].toLowerCase().replace(/[^a-z0-9]/g, ''),
 51 |           type,
 52 |           children: getTableOfContents(lines, { children: [], headingType: type })
 53 |         }
 54 | 
 55 |         children.push(branch)
 56 |       } else {
 57 |         lines.unshift(line)
 58 |         break
 59 |       }
 60 |     }
 61 |   }
 62 | 
 63 |   return children
 64 | }
 65 | 
 66 | function loadFrontmatter (filePath) {
 67 |   const contents = fs.readFileSync(filePath, { encoding: 'utf8' })
 68 |   const parsed = matter(contents)
 69 |   parsed.html = converter.makeHtml(parsed.content)
 70 |   return parsed
 71 | }
 72 | 
 73 | function copyAsset (fromPath, toPath) {
 74 |   const toPathDirectory = toPath.replace(/^(.*)\/.*?$/, '$1')
 75 |   fs.mkdirSync(path.join(publicPath, toPathDirectory), { recursive: true })
 76 |   fs.copyFileSync(fromPath, path.join(publicPath, toPath))
 77 | }
 78 | 
 79 | function renderHTML (uriPath, template, data) {
 80 |   const hbTemplate = handlebars.compile(templates[template])
 81 |   fs.mkdirSync(path.join(publicPath, uriPath), { recursive: true })
 82 |   fs.writeFileSync(path.join(publicPath, uriPath, 'index.html'), hbTemplate(data), { encoding: 'utf8' })
 83 | }
 84 | 
 85 | const types = { All: [] }
 86 | 
 87 | function slugify (string) {
 88 |   return string.toLowerCase().replace(/\s/g, '-')
 89 | }
 90 | 
 91 | function getCipContents (cip) {
 92 |   // get all the headings from markdown
 93 |   // inside cip.hbs create
 94 | }
 95 | 
 96 | function build () {
 97 |   fs.mkdirSync(publicPath)
 98 |   const cipsDirectory = path.join(__dirname, '..')
 99 |   const cips = fs.readdirSync(cipsDirectory)
100 |   cips.forEach(item => {
101 |     if (!item.match(/^CIP-[\d][\d][\d][\d]{1,}$/)) return
102 |     const assets = fs.readdirSync(path.join(cipsDirectory, item))
103 |     assets.forEach(asset => {
104 |       const assetPath = path.join(cipsDirectory, item, asset)
105 |       if (asset === `${item}.md`) {
106 |         const cip = loadFrontmatter(assetPath)
107 |         cip.tableOfContents = getTableOfContents(cip.content.split('\n'))
108 |         types[cip.data.Type] = types[cip.data.Type] || []
109 |         types[cip.data.Type].push(cip)
110 |         types.All.push(cip)
111 |       } else {
112 |         copyAsset(assetPath, `/cips/${item.toLowerCase()}/${asset}`)
113 |       }
114 |     })
115 |   })
116 | 
117 |   const headerData = []
118 | 
119 | 
120 | 
121 |   Object.keys(types).forEach(type => {
122 |     headerData.push({ label: type, path: `/${slugify(type)}/` })
123 |   })
124 | 
125 |   Object.keys(types).forEach(type => {
126 |     
127 |     renderHTML(`/${slugify(type)}/`, 'cips', {
128 |       headerData,
129 |       cips: types[type],
130 |       type,
131 |       title: type
132 |     })
133 | 
134 |     types[type].forEach(cip => {
135 |       renderHTML(`/cips/cip${cip.data.CIP}/`, 'cip', {
136 |         headerData,
137 |         cip,
138 |         title: cip.Title
139 |       })
140 |     })
141 |   })
142 | 
143 | 
144 |   const readme = loadFrontmatter(path.join(__dirname, '..', 'README.md'))
145 |   renderHTML('/', 'home', {
146 |     headerData,
147 |     readme,
148 |     title: 'CIP Cardano Improvement Proposals'
149 |   })
150 | }
151 | 
152 | function clean () {
153 |   rimraf.sync(publicPath)
154 | }
155 | 
156 | function loadTemplates () {
157 |   const templatedDirectory = path.join(__dirname, '..', 'templates')
158 |   const templateItems = fs.readdirSync(templatedDirectory)
159 |   templateItems.forEach(template => {
160 |     const name = template.replace(/\.hbs$/, '')
161 |     const content = fs.readFileSync(path.join(templatedDirectory, template), { encoding: 'utf8' })
162 |     templates[name] = content
163 |     handlebars.registerPartial(name, content)
164 |   })
165 | }
166 | 
167 | function copyAssets (relativePath = '') {
168 |   let assetsDirectory = path.join(__dirname, '..', 'assets')
169 |   if (relativePath) {
170 |     assetsDirectory = path.join(assetsDirectory, relativePath)
171 |     fs.mkdirSync(assetsDirectory, { recursive: true })
172 |   }
173 | 
174 |   const assets = fs.readdirSync(assetsDirectory)
175 |   assets.forEach(asset => {
176 |     const assetPath = path.join(assetsDirectory, asset)
177 |     if (fs.statSync(assetPath).isDirectory()) {
178 |       copyAssets(path.join(relativePath, asset))
179 |     } else {
180 |       copyAsset(assetPath, path.join('assets', relativePath, asset))
181 |     }
182 |   })
183 | }
184 | 
185 | clean()
186 | loadTemplates()
187 | build()
188 | copyAssets()
189 | 


--------------------------------------------------------------------------------
/CIP-0012/CIP-0012.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | CIP: 12
  3 | Title: On-chain stake pool operator to delegates communication
  4 | Authors: Marek Mahut <marek.mahut@fivebinaries.com>, Sebastien Guillemot <sebastien@emurgo.io>, Ján Hrnko <jan.hrnko@fivebinaries.com>
  5 | Comments-URI: https://forum.cardano.org/t/on-chain-stake-pool-operator-to-delegates-communication/42229
  6 | Status: Draft
  7 | Type: Standards
  8 | Created: 2020-11-07
  9 | License: CC-BY-4.0
 10 | Requires: CIP10
 11 | ---
 12 | 
 13 | ## Abstract
 14 | 
 15 | Standard format for metadata used in an on-chain communication of stake pool owner towards their delegates.
 16 | 
 17 | ## Terminology
 18 | 
 19 | We define two types of communication metadata, which are distinguished by transaction metadata label as defined in the [CIP10 Transaction metadata label registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP10/README.md).
 20 | 
 21 |  * *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.
 22 | 
 23 |  * *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.
 24 | 
 25 | ## Motivation
 26 | 
 27 | The lack of an on-chain communication standard between a stake pool owner and their delegates.
 28 | 
 29 | <!-- Link to CIP6 link once/if merged -->
 30 | 
 31 | Work in progress [CIP6](https://github.com/cardano-foundation/CIPs/pull/15) 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.
 32 | 
 33 | ## Specification
 34 | 
 35 | As per [CIP10 Transaction metadata label registry](https://github.com/cardano-foundation/CIPs/blob/master/CIP10/README.md), we assign:
 36 | 
 37 | * *Message board communication* transaction metadata label `1990`,
 38 | * *Direct delegate communication* transaction metadata label `1991`.
 39 | 
 40 | ## Metadata
 41 | 
 42 | Metadata are written in JSON format and maximum size of metadata around 16KB.
 43 | 
 44 | The root object property is a 3 bytes UTF-8 encoded string representing the ISO 639-3
 45 | language code of the content.
 46 | 
 47 | | key                    | Value                                        | Rules                                      |
 48 | | ---------------------- | -------------------------------------------- | ------------------------------------------ |
 49 | | `title` *(required)*   | Title of the communication                   | 64 bytes UTF-8 encoded string              |
 50 | | `content` *(required)* | Content of the communication                 | An array of 64 bytes UTF-8 encoded strings |
 51 | |                        |                                              |
 52 | | `valid` *(optional)*   | Slot number the communication becomes valid  | Unsigned integer                           |
 53 | | `expires` *(optional)* | Slot number until the communication is valid | Unsigned integer                           |
 54 | 
 55 | ### Metadata JSON schema
 56 | 
 57 | The [schema.json](./schema.json) file defines the metadata.
 58 | 
 59 | ### Metadata example including the transaction metadata label
 60 | 
 61 | ```
 62 | {
 63 |   "1991": [ {
 64 |     "lat": {
 65 |       "title": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do",
 66 |       "content": [
 67 |         "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do ",
 68 |         "eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut e",
 69 |         "nim ad minim veniam, quis nostrud exercitation ullamco laboris n",
 70 |         "isi ut aliquip ex ea commodo consequat. Duis aute irure dolor in",
 71 |         " reprehenderit in voluptate velit esse cillum dolore eu fugiat n",
 72 |         "ulla pariatur. Excepteur sint occaecat cupidatat non proident, s",
 73 |         "unt in culpa qui officia deserunt mollit anim id est laborum."
 74 |       ],
 75 |       "valid": 10661033,
 76 |       "expire": 10669033
 77 |     }
 78 |    },
 79 |    {
 80 |     "eng": {
 81 |       "title": "But I must explain to you how all this mistaken idea",
 82 |       "content": [
 83 |         "But I must explain to you how all this mistaken idea of denounci",
 84 |         "ng of a pleasure and praising pain was born and I will give you ",
 85 |         "a complete account of the system, and expound the actual teachin",
 86 |         "gs of the great explorer of the truth, the master-builder of hum",
 87 |         "an happiness. No one rejects, dislikes, or avoids pleasure itsel",
 88 |         "f, because it is pleasure, but because those who do not know how",
 89 |         " to pursue pleasure rationally encounter consequences."
 90 |       ],
 91 |       "valid": 10661033,
 92 |       "expire": 10669033
 93 |     }
 94 |    }
 95 |   ]
 96 | }
 97 | ```
 98 | 
 99 | ## Rationale
100 | 
101 | 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.
102 | 
103 | The current Cardano protocol parameter for maximum transaction size, that will hold the metadata, is around 16KB.
104 | 
105 | ## Backwards compatibility
106 | 
107 | No backwards compatibility breaking changes are introduced.
108 | 
109 | ## Reference implementation
110 | 
111 | We leave the decisions, such as what and how to display communication messages, up to downstream tools and wallets.
112 | 
113 |  * For simple implementation reference, refer to [CIP12 communication tool examples](https://github.com/fivebinaries/cip-metadata-communication-example)
114 | 
115 | ## Copyright
116 | 
117 | This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)


--------------------------------------------------------------------------------
/BiweeklyMeetings/08-11-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [August 11 2020 notes](#-11-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |       + [CIP5](#cip5)
 10 |       + [CIP4](#cip4)
 11 |       + [CIP3](#cip3)
 12 |   * [Discussions](#discussions)
 13 |   * [Close](#close)
 14 | - [Extra](#extra)
 15 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 16 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
 17 |   * [Understanding CIPs further](#understanding-cips-further)
 18 | ## Summary
 19 | 
 20 | 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.  
 21 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 22 | </sub>
 23 | 
 24 | 
 25 | ## Editors Meeting Flow
 26 | - [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..
 27 | - [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)
 28 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 29 | PR -> ‘Draft’: Needs format + approval.  
 30 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 31 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 32 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 33 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 34 | 
 35 | 
 36 | 
 37 | ## August 11 2020 notes
 38 | 
 39 | 
 40 | **Attending**: (~~Duncan~~, Frederic, Matthias, Sebastien) + Ben (CF)
 41 | 
 42 | 
 43 | 
 44 | ### Triage
 45 | N/A
 46 | 
 47 | ### Last Check
 48 | N/A
 49 | 
 50 | ### Review  
 51 | #### CIP5
 52 | > **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.  
 53 | > **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.   
 54 | > **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.   
 55 | 
 56 | #### CIP4
 57 | > **S** - Needs test vectors - should be quick. The Wallet checksum should be merged, it just got shipped.
 58 | 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.  
 59 | > **M** - I see you changed a lot more since I looked at it - will try to review it and move forward.  
 60 | > **S** - That CIP will also be used by Ergo - it will be a multichain standard functionally (used by Ergo).   
 61 | > **S** - I have a few examples in Emurgo test library - I don’t have the pictures… hope that’s ok.   
 62 | #### CIP3
 63 | > Still need more work before merging into Draft.
 64 | 
 65 | ### Discussions 
 66 | 1. **M** - Change the README to the CIPx file… (change CIP1 content to reflect the structure) -> **Frederic**  
 67 | 2. Proper License files needed for CIP5 & CIP2 -> **M**  
 68 | 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.  
 69 | 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?  
 70 | 5. **Ben** - (Different possible flows for CIP Editorship, to be continued next meeting)  
 71 | 
 72 | ### Close
 73 | **TODO** Add license files to CIP5 & CIP2 (**Matthias**)  
 74 | **TODO** Change Format of CIPs (in CIP 1) to have the structures of CIPs change to readme.md (instead CIPx.md) (**Frederic**)  
 75 | (Close) 
 76 | 
 77 | ---
 78 | ## Extra
 79 | 
 80 | ### Current CIPs in the CIP repository and their status 
 81 | 
 82 | 
 83 | |#              |Title            | Status               |
 84 | | ----------------- |:----------------|:-------------------- |
 85 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
 86 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
 87 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
 88 | 
 89 | 
 90 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
 91 | 
 92 | 
 93 | ### CIP creation process as a Sequence Diagram
 94 | 
 95 | _"Alice has a Cardano idea she'd like to build more formally":_
 96 | 
 97 | 
 98 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
 99 | 
100 | ### Understanding CIPs further
101 | 
102 | 
103 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
104 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
105 | 


--------------------------------------------------------------------------------
/assets/images/logo.svg:
--------------------------------------------------------------------------------
 1 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
 2 | <svg
 3 |    xmlns:dc="http://purl.org/dc/elements/1.1/"
 4 |    xmlns:cc="http://creativecommons.org/ns#"
 5 |    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 6 |    xmlns:svg="http://www.w3.org/2000/svg"
 7 |    xmlns="http://www.w3.org/2000/svg"
 8 |    xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
 9 |    xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
10 |    inkscape:version="1.0 (4035a4f, 2020-05-01)"
11 |    sodipodi:docname="cardano-black.svg"
12 |    xml:space="preserve"
13 |    enable-background="new -39 -39 128 128"
14 |    viewBox="-39 -39 128 128"
15 |    height="128px"
16 |    width="128px"
17 |    y="0px"
18 |    x="0px"
19 |    id="Layer_1"
20 |    version="1.1"><metadata
21 |    id="metadata21"><rdf:RDF><cc:Work
22 |        rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
23 |          rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
24 |    id="defs19" /><sodipodi:namedview
25 |    inkscape:current-layer="g14"
26 |    inkscape:window-maximized="0"
27 |    inkscape:window-y="23"
28 |    inkscape:window-x="0"
29 |    inkscape:cy="64"
30 |    inkscape:cx="16.590174"
31 |    inkscape:zoom="4.0603397"
32 |    showgrid="false"
33 |    id="namedview17"
34 |    inkscape:window-height="762"
35 |    inkscape:window-width="1600"
36 |    inkscape:pageshadow="2"
37 |    inkscape:pageopacity="0"
38 |    guidetolerance="10"
39 |    gridtolerance="10"
40 |    objecttolerance="10"
41 |    borderopacity="1"
42 |    bordercolor="#666666"
43 |    pagecolor="#ffffff" />
44 | <g
45 |    id="g14">
46 | 	<g
47 |    style="fill:#000000;fill-opacity:1"
48 |    id="g12">
49 | 		<path
50 |    style="fill:#000000;fill-opacity:1"
51 |    id="path10"
52 |    d="M15.527,16.675c-3.048,0-5.795-1.691-7.163-4.408C6.378,8.319,7.97,3.492,11.915,1.502    c1.117-0.56,2.361-0.857,3.6-0.857c3.047,0,5.792,1.69,7.166,4.405c1.99,3.948,0.395,8.777-3.55,10.762    C18.015,16.377,16.766,16.675,15.527,16.675 M6.122,33.055c-0.157,0-0.309-0.005-0.464-0.01c-4.406-0.256-7.794-4.051-7.542-8.459    c0.248-4.395,4.015-7.808,8.456-7.547c4.41,0.245,7.793,4.044,7.544,8.456C13.872,29.738,10.357,33.055,6.122,33.055     M15.586,49.392c-1.561,0-3.078-0.454-4.389-1.312c-1.787-1.171-3.016-2.977-3.45-5.067c-0.438-2.092-0.031-4.236,1.141-6.026    c1.489-2.267,3.997-3.624,6.708-3.624c1.561,0,3.083,0.459,4.389,1.315c1.793,1.173,3.018,2.974,3.453,5.07    c0.441,2.092,0.033,4.23-1.144,6.025C20.812,48.039,18.304,49.392,15.586,49.392 M34.486,49.353c-3.043,0-5.786-1.691-7.158-4.408    c-0.966-1.909-1.125-4.08-0.454-6.117c0.667-2.033,2.095-3.68,4.004-4.647c1.112-0.564,2.361-0.858,3.603-0.858    c3.048,0,5.794,1.69,7.162,4.411c1.985,3.945,0.394,8.773-3.553,10.761C36.979,49.054,35.732,49.353,34.486,49.353 M43.902,32.977    c-0.158,0-0.311-0.011-0.465-0.017c-4.415-0.248-7.796-4.048-7.547-8.454c0.251-4.397,4.02-7.809,8.461-7.55    c2.134,0.123,4.097,1.065,5.521,2.665c1.424,1.595,2.143,3.656,2.016,5.792C51.65,29.654,48.139,32.977,43.902,32.977     M34.406,16.638c-1.558,0-3.076-0.452-4.389-1.315c-3.698-2.426-4.729-7.401-2.305-11.098c1.485-2.264,3.994-3.618,6.704-3.618    c1.562,0,3.082,0.454,4.39,1.312c3.696,2.42,4.731,7.399,2.307,11.095C39.624,15.278,37.121,16.638,34.406,16.638 M7.503-13.113    c0.999,1.974,0.201,4.385-1.771,5.375C3.756-6.74,1.349-7.539,0.357-9.506c-0.999-1.978-0.204-4.384,1.771-5.382    C4.099-15.878,6.512-15.089,7.503-13.113 M-16.752,21.094c2.209,0.125,3.896,2.017,3.772,4.225    c-0.124,2.207-2.02,3.897-4.227,3.775c-2.206-0.132-3.891-2.022-3.77-4.229C-20.852,22.659-18.959,20.969-16.752,21.094     M0.743,59.204c1.215-1.848,3.692-2.366,5.542-1.15c1.85,1.209,2.367,3.69,1.152,5.545c-1.211,1.849-3.693,2.36-5.543,1.153    C0.043,63.535-0.468,61.056,0.743,59.204 M42.503,63.11c-0.998-1.971-0.2-4.376,1.767-5.375c1.983-0.992,4.387-0.197,5.379,1.771    c0.999,1.976,0.201,4.386-1.774,5.377C45.904,65.881,43.496,65.088,42.503,63.11 M66.756,28.903    c-2.213-0.126-3.895-2.018-3.771-4.224c0.125-2.212,2.016-3.899,4.226-3.772c2.206,0.123,3.898,2.015,3.774,4.227    C70.863,27.344,68.962,29.028,66.756,28.903 M49.264-9.209c-1.21,1.85-3.692,2.366-5.543,1.154    c-1.852-1.21-2.366-3.693-1.151-5.543c1.212-1.852,3.694-2.366,5.54-1.155C49.956-13.539,50.476-11.059,49.264-9.209     M-1.252-25.396c0.646,1.278,0.126,2.838-1.146,3.479c-1.279,0.645-2.835,0.134-3.48-1.148c-0.645-1.275-0.129-2.838,1.146-3.478    C-3.453-27.184-1.896-26.672-1.252-25.396 M-31.77,22.538c1.429,0.082,2.523,1.305,2.44,2.731    c-0.084,1.427-1.307,2.526-2.731,2.436c-1.43-0.073-2.524-1.305-2.439-2.728C-34.419,23.549-33.197,22.46-31.77,22.538     M-5.515,72.932c0.785-1.196,2.394-1.532,3.591-0.742c1.195,0.784,1.528,2.387,0.741,3.589c-0.78,1.19-2.39,1.528-3.585,0.745    C-5.966,75.735-6.299,74.128-5.515,72.932 M51.258,75.397c-0.643-1.282-0.129-2.842,1.147-3.48    c1.279-0.644,2.837-0.134,3.477,1.146c0.649,1.278,0.129,2.836-1.145,3.475C53.457,77.186,51.901,76.671,51.258,75.397     M81.772,27.465c-1.429-0.082-2.525-1.309-2.443-2.737c0.085-1.433,1.305-2.523,2.738-2.439c1.426,0.075,2.521,1.306,2.433,2.733    C84.423,26.448,83.197,27.541,81.772,27.465 M55.522-22.936c-0.79,1.198-2.398,1.533-3.589,0.747    c-1.196-0.787-1.529-2.39-0.748-3.588c0.787-1.195,2.393-1.53,3.587-0.741C55.969-25.736,56.304-24.131,55.522-22.936     M-0.468,4.95c2.174,1.422,2.782,4.343,1.354,6.518c-1.422,2.176-4.345,2.787-6.523,1.354c-2.176-1.422-2.782-4.34-1.354-6.52    C-5.562,4.131-2.643,3.52-0.468,4.95 M-5.1,37.032c2.323-1.173,5.156-0.234,6.328,2.087c1.168,2.32,0.235,5.154-2.088,6.326    c-2.32,1.171-5.157,0.232-6.325-2.085C-8.356,41.036-7.424,38.202-5.1,37.032 M20.03,57.084c0.148-2.596,2.376-4.582,4.97-4.439    c2.602,0.148,4.585,2.377,4.437,4.971c-0.146,2.599-2.371,4.587-4.973,4.438C21.868,61.903,19.883,59.68,20.03,57.084     M50.476,45.056c-2.174-1.433-2.78-4.348-1.36-6.525c1.427-2.171,4.347-2.776,6.52-1.354c2.177,1.424,2.782,4.345,1.358,6.519    C55.57,45.874,52.648,46.476,50.476,45.056 M55.105,12.967c-2.324,1.171-5.155,0.239-6.325-2.084    c-1.17-2.321-0.24-5.154,2.084-6.323c2.326-1.174,5.16-0.238,6.335,2.085C58.363,8.966,57.429,11.8,55.105,12.967 M29.641-7.083    C29.492-4.49,27.263-2.5,24.662-2.649c-2.596-0.147-4.583-2.371-4.436-4.97c0.149-2.599,2.371-4.583,4.967-4.438    C27.797-11.908,29.785-9.686,29.641-7.083 M-18.01-3.5c1.525,0.995,1.946,3.042,0.948,4.564c-0.997,1.523-3.04,1.95-4.564,0.947    c-1.523-0.999-1.949-3.045-0.948-4.564C-21.575-4.074-19.532-4.504-18.01-3.5 M-21.188,47.997c1.631-0.821,3.61-0.17,4.43,1.461    c0.819,1.623,0.165,3.606-1.463,4.428c-1.625,0.818-3.607,0.169-4.427-1.458C-23.464,50.805-22.813,48.815-21.188,47.997     M21.487,76.499c0.099-1.819,1.66-3.208,3.477-3.103c1.821,0.1,3.207,1.657,3.104,3.475c-0.1,1.823-1.659,3.215-3.477,3.108    C22.769,79.877,21.382,78.318,21.487,76.499 M68.008,53.501c-1.519-0.996-1.944-3.045-0.945-4.563    c0.998-1.521,3.042-1.952,4.565-0.951c1.519,0.998,1.944,3.045,0.948,4.563C71.578,54.073,69.534,54.501,68.008,53.501     M71.192,2.005c-1.626,0.816-3.612,0.163-4.432-1.466c-0.818-1.625-0.166-3.604,1.463-4.425c1.625-0.819,3.608-0.168,4.427,1.458    C73.469-0.799,72.814,1.185,71.192,2.005 M28.182-26.5c-0.103,1.82-1.661,3.208-3.482,3.104c-1.815-0.103-3.207-1.66-3.104-3.478    c0.104-1.822,1.66-3.212,3.479-3.106C26.896-29.877,28.288-28.316,28.182-26.5"
53 |    fill="#FFFFFF" />
54 | 	</g>
55 | </g>
56 | </svg>
57 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/10-20-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [October 20 2020 notes](#october-20-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |       + [Extended Metadata](#Extended-Metadata)
  9 |       + [Wallet Checksums](#Wallet-Checksums)
 10 |   * [Review](#review)
 11 |       + [Message Signing](#Message-Signing)
 12 |   * [Discussions](#discussions)
 13 |   * [Close](#close)
 14 | - [Extra](#extra)
 15 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 16 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 17 |   * [Understanding CIPs further](#understanding-cips-further)
 18 | ## Summary
 19 | 
 20 | 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.  
 21 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 22 | </sub>
 23 | 
 24 | 
 25 | ## Editors Meeting Flow
 26 | - [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..
 27 | - [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)
 28 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 29 | PR -> ‘Draft’: Needs format + approval.  
 30 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 31 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 32 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 33 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 34 | 
 35 | 
 36 | 
 37 | ## October 20 2020 notes
 38 | 
 39 | 
 40 | **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO)
 41 | 
 42 | 
 43 | ### Triage
 44 | N/A
 45 | 
 46 | ### Last Check  
 47 | 
 48 | #### Extended Metadata  
 49 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   
 50 | 
 51 | **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.  
 52 | **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.  
 53 | **Sebastien** We're waiting for info on explorers.  
 54 | **Duncan** As long as the authors are still engaged, that's fine.  
 55 | **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.  
 56 | **Frederic** Will Follow on. Ping them directly or invite them + authors.  
 57 | => **On Hold**  
 58 | 
 59 | 
 60 | #### Wallet Checksum  
 61 | ([PR](https://github.com/cardano-foundation/CIPs/pull/4)  - potential CIP4)  
 62 | 
 63 | **Frederic** all good to go - (no objections).   
 64 | 
 65 | 
 66 | 
 67 | ### Review  
 68 | 
 69 | #### Message Signing  
 70 | ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8)  
 71 | **Duncan** Good feedback from IOG.   
 72 | **Sebastien** Voltaire voting is coming up, I would like for it to be merged now (as it was discussed on the last call).  
 73 | **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.  
 74 | **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.  
 75 | => **MERGING** now
 76 | 
 77 | 
 78 | 
 79 | 
 80 | ### Discussions 
 81 | 
 82 | **Duncan** Suggest we move CIP5 into "Proposed" state, and require details of the plan while it's in "Proposed" state?  
 83 | **Frederic** "Proposed" must have defined metrics of acceptance/plan to Active.  
 84 | **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.   
 85 | **Duncan** We also need a better chart or table at top-level: a readme would be helpful...  
 86 | **Frederic** the (CIP auto gen site) is being managed by IOG; slow to get issues fixed unfortunately 
 87 | 
 88 | 
 89 | 
 90 | 
 91 | ### Close
 92 |  
 93 | **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)  
 94 | **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  
 95 | **ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) re: comments and updates  
 96 | => Merge **NOW**: [“Wallet Checksum”](https://github.com/cardano-foundation/CIPs/pull/4) to be merged as ‘Draft’ (‘CIP4’)  
 97 | => Merge **NOW**: [“Message Signing”](https://github.com/cardano-foundation/CIPs/pull/27)to be merged as ‘Draft’ (‘CIP8’)   
 98 | 
 99 | 
100 | ---
101 | ## Extra
102 | 
103 | ### Current CIPs in the CIP repository and their status 
104 | 
105 | 
106 | |#              |Title            | Status               |
107 | | ----------------- |:----------------|:-------------------- |
108 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
109 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
110 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
111 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
112 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
113 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
114 | 
115 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
116 | 
117 | 
118 | ### CIP creation process as a Sequence Diagram
119 | 
120 | _"Alice has a Cardano idea she'd like to build more formally":_
121 | 
122 | 
123 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
124 | 
125 | ### Understanding CIPs further
126 | 
127 | 
128 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
129 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
130 | 
131 | 
132 | 
133 | 
134 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/10-06-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [October 06 2020 notes](#october-06-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |       + [Extended Metadata](#Extended-Metadata)
  9 |       + [Curve Pledge Benefit](#Curve-Pledge-Benefit)
 10 |   * [Review](#review)
 11 |       + [Wallet Checksums](#Wallet-Checksums)
 12 |       + [Message Signing](#Message-Signing)
 13 |   * [Discussions](#discussions)
 14 |   * [Close](#close)
 15 | - [Extra](#extra)
 16 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 17 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 18 |   * [Understanding CIPs further](#understanding-cips-further)
 19 | ## Summary
 20 | 
 21 | 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.  
 22 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 23 | </sub>
 24 | 
 25 | 
 26 | ## Editors Meeting Flow
 27 | - [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..
 28 | - [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)
 29 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 30 | PR -> ‘Draft’: Needs format + approval.  
 31 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 32 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 33 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 34 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 35 | 
 36 | 
 37 | 
 38 | ## October 06 2020 notes
 39 | 
 40 | 
 41 | **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy (CF) + Shawn (PR Author) + Nick (Community) 
 42 | 
 43 | 
 44 | ### Triage
 45 | N/A
 46 | 
 47 | ### Last Check  
 48 | 
 49 | #### Extended Metadata
 50 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   
 51 | 
 52 | **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.  
 53 | **Sebastien** - Let’s wait another two weeks for the changes/comments that were expected in the PR to proceed.
 54 | 
 55 | 
 56 | #### Curve Pledge Benefit
 57 | ([PR](https://github.com/cardano-foundation/CIPs/pull/12)  - potential CIP7) 
 58 | 
 59 | **Sebastien** - Still not sure if the proposal' incentives are fully sound but that’s for analysts to discuss.  
 60 | **Matthias/Shawn** - Last CIP Editors meeting we agreed to merge it as a draft, pending some legal clarifications.  
 61 | **Sebastien** - Can be merged as a draft. As formatting goes, ok to merge to advance the conversation.  
 62 | **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.
 63 | 
 64 | ### Review  
 65 | 
 66 | 
 67 | 
 68 | 
 69 | 
 70 | 
 71 | 
 72 | 
 73 | 
 74 | 
 75 | 
 76 | 
 77 | #### Wallet Checksums  
 78 | ([PR](https://github.com/cardano-foundation/CIPs/pull/4) - potential CIP4) 
 79 | 
 80 | **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. 
 81 | 
 82 | 
 83 | #### Message Signing  
 84 | ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP8) 
 85 | 
 86 | **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. 
 87 | 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. 
 88 | 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. 
 89 | Need to check if this approach can be used for Daedalus wallet.
 90 | **Duncan** - May have internal IOHK auditors to review, 2-3 weeks needed for review. 
 91 | 
 92 | 
 93 | ### Discussions 
 94 | **Shawn** - What is the process for items to be put on the CIP Editors meeting agenda?  
 95 | **Duncan** - Any relevant items, depending on capacity - easiest way is reach out to the Editors or flag it in Github.  
 96 | (Discussion re: Pool ranking .. needs to be improved)
 97 | 
 98 | 
 99 | 
100 | 
101 | ### Close
102 |  
103 | **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md)  
104 | “Curve proposal” (‘CIP7’) to be merged as ‘Draft’, legal tweaks to follow.  
105 | “Extended Metadata” (‘CIP6’) flagged for comments and updates next two week.  
106 | “Wallet Checksum” (‘CIP4’) to be merged as ‘Draft’ in 2 weeks. 
107 | 
108 | 
109 | 
110 | ---
111 | ## Extra
112 | 
113 | ### Current CIPs in the CIP repository and their status 
114 | 
115 | 
116 | |#              |Title            | Status               |
117 | | ----------------- |:----------------|:-------------------- |
118 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
119 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
120 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
121 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
122 | 
123 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
124 | 
125 | 
126 | ### CIP creation process as a Sequence Diagram
127 | 
128 | _"Alice has a Cardano idea she'd like to build more formally":_
129 | 
130 | 
131 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
132 | 
133 | ### Understanding CIPs further
134 | 
135 | 
136 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
137 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
138 | 
139 | 
140 | 
141 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/07-15-2020.md:
--------------------------------------------------------------------------------
  1 | **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [July 15 2020 notes](#july-15-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |     + [CIP5](#cip5)
 10 |   * [Discussions](#discussions)
 11 |   * [Close](#close)
 12 | - [Extra](#extra)
 13 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 14 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
 15 |   * [Understanding CIPs further](#understanding-cips-further)
 16 | ## Summary
 17 | 
 18 | 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.  
 19 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 20 | </sub>
 21 | 
 22 | 
 23 | ## Editors Meeting Flow
 24 | - [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..
 25 | - [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)
 26 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 27 | PR -> ‘Draft’: Needs format + approval.  
 28 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 29 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 30 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 31 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 32 | 
 33 | 
 34 | 
 35 | ## July 15 2020 notes
 36 | 
 37 | 
 38 | **Attending**: (Duncan, Sebastien, Frederic, ~~Matthias~~) + Eystein (guest)
 39 | 
 40 | 
 41 | 
 42 | ### Triage
 43 | - Still issues with the multi-review. 
 44 | - Need to add meeting notes to the repo.
 45 | - Merge pr (copy tweak on CIP1). 
 46 | ### Last Check
 47 | => **Action**: - merge pr (CIP2 - “Coin Selection” - DRAFT) 
 48 | ### Review
 49 | #### CIP5 
 50 | >**Sebastian** - Happy with all.  
 51 | 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.  
 52 | >**D**: Reviewing the prefixes right now.  
 53 | >**S**: We have diff prefixes for mainnet and testnet. Which is duplicating the header payload.  
 54 | >**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.  
 55 | >**Eystein** - would be good to have multiple iteration prefixes per testnet  
 56 | >**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.  
 57 | >**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.
 58 | For Haskell-Shelley, we will have the same issue - so most likely those other addr. types will be hidden behind some flags of sorts.   
 59 | >**D**: That’ll likely be up to the wallet itself to figure out which type to use.   
 60 | >**E**: I don’t care if automated - I can see a usecase for both…  
 61 | >**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… 
 62 | 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?
 63 | Because in the end they are all payment addresses.   
 64 | >**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.   
 65 | (..)   
 66 | >**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.
 67 | 3 ways a pmt addr can refer to a stake. And therefore have stake or not:  
 68 | Null (short)  
 69 | Ptr (short)    
 70 | Base (long)  
 71 | >**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.  
 72 | >**D**: There should be a default - it would never as standard mode for users do null staking..  
 73 | >**S**: after the initial release the wallet would show default release.  
 74 | >**D**: Wallet should not confuse users by presenting too many options… If easier to display short addr, should be simplified.  
 75 | >**D**: It’s a disc to have with Matthias - for Seb. (+Darko)  
 76 | Should we lump all Txs under one prefix?   
 77 | >**S** - I am not yet convinced about the addr prefix. But not concerned.   
 78 | >**D**: You don’t have to add the addr. if the wallet takes care of it for you.  
 79 | >**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.   
 80 | >**D**: Not majorly important.   
 81 | 
 82 | ### Discussions
 83 | - Pool operators are thinking about a “Standardizing” CIP. 
 84 | - Opening up meetings visibility to the public.
 85 | - Internal requests to consider CIP exploration re: Address management (for 100ks of i.e. exchanges). 
 86 | - 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). 
 87 | _Eystein had a good talk he did at the Cardano Summit in July - he understands governance / the need for CIPs._ 
 88 | 
 89 | ### Close
 90 | - **CIP5** as Draft OK to merge - will be iterated on.
 91 | - **CIP2** Merged delayed till next meeting to round up last Qs.
 92 | 
 93 | (missing - current minor PR qs - ex: where and how to store meeting notes) 
 94 | (Close) 
 95 | 
 96 | 
 97 | ---
 98 | ## Extra
 99 | 
100 | ### Current CIPs in the CIP repository and their status 
101 | 
102 | 
103 | |#              |Title            | Status               |
104 | | ----------------- |:----------------|:-------------------- |
105 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
106 | 
107 | 
108 | 
109 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
110 | 
111 | 
112 | ### CIP creation process as a Sequence Diagram
113 | 
114 | _"Alice has a Cardano idea she'd like to build more formally":_
115 | 
116 | 
117 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
118 | 
119 | ### Understanding CIPs further
120 | 
121 | 
122 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
123 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
124 | 


--------------------------------------------------------------------------------
/CIP-0004/CIP-0004.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | CIP: 4
  3 | Title: Wallet Checksums
  4 | Authors: Ruslan Dudin <ruslan@emurgo.io>, Sebastien Guillemot <sebastien@emurgo.io>
  5 | Comments-URI: https://forum.cardano.org/t/cip4-wallet-checksum/32819
  6 | Status: Draft
  7 | Type: Standards
  8 | Created: 2019-05-01
  9 | License: Apache-2.0
 10 | ---
 11 | 
 12 | ## Abstract
 13 | 
 14 | We introduce a checksum algorithm to help users verify they are restoring the right wallet before the restoration actually takes place.
 15 | 
 16 | ## Motivation
 17 | 
 18 | 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.
 19 | 
 20 | To solve this, we introduce a checksum that can be computed without having to perform wallet restoration.
 21 | 
 22 | ## Specification
 23 | 
 24 | 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.
 25 | 
 26 | ### Requirements for checksum
 27 | 
 28 | 1) Easily recomputed without access to mnemonic, private key or other similarly sensitive data
 29 | 2) Does not reveal anything about the wallet (irreversible -- cannot tell addresses, private key, etc. from just seeing the checksum)
 30 | 3) Negligible chance of collision
 31 | 4) Easy to memorize for the user
 32 | 5) Can be easily saved both digitally or on paper
 33 | 
 34 | ### Implementation Outline
 35 | 
 36 | 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.
 37 | **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.
 38 | 
 39 | To satisfy (2) and (3), the a hash of the public key is used
 40 | 
 41 | 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).
 42 | 
 43 | ## Rationale & Concrete implementation
 44 | 
 45 | We first provide a template for the code, explain the template and then provide the parameterization we use for Cardano
 46 | 
 47 | ```js
 48 | function calculateChecksum(publicKeyHash: string /* note: lowercase hex representation */) {
 49 |   const hash = hash1(publicKeyHash);
 50 |   const [a, b, c, d] = hash_to_32(hash); // get a 4 byte value from the hash
 51 |   const alpha = `ABCDEJHKLNOPSTXZ`; // take 16 letters from the alphabet that are easy to distinguish
 52 | 
 53 |   // construct the TextPart from a group of letters and a group of numbers
 54 |   const letters = x => `${alpha[Math.floor(x / 16)]}${alpha[x % 16]}`;
 55 |   const numbers = `${((c << 8) + d) % 10000}`.padStart(4, '0');
 56 |   const id = `${letters(a)}${letters(b)}-${numbers}`;
 57 | 
 58 |   return {
 59 |     hash, // used to generate the ImagePart
 60 |     id, // used as the TextPart
 61 |   };
 62 | }
 63 | ```
 64 | 
 65 | ### TextPart rationale
 66 | 
 67 | 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.
 68 | 
 69 | #### Letter part
 70 | 
 71 | For letters, we render the bytes in hex, but replace the alphanumeric used in hex with this letter-only alphabet:
 72 | 
 73 | `A B C D E J H K L N O P S T X Z`
 74 | 
 75 | This alphabet satisfies the following requirements:
 76 | 
 77 | 1) Has exactly 16 letters (one-to-one mapping with 2 bytes in HEX)
 78 | 1) Does not contain characters that look too much like each other
 79 | 1) Minimizes occurrences of undesirable words in [this list](https://www.noswearing.com/fourletterwords.php).
 80 | 
 81 | #### Number part
 82 | 
 83 | 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).
 84 | 
 85 | 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.
 86 | **Note**: resulting number is zero-padded to 4 digits.
 87 | 
 88 | ### ImagePart rationale
 89 | 
 90 | For the image, we take the result of `hash1` and use it as the seed for the [blockies](https://github.com/ethereum/blockies) library.
 91 | 
 92 | This library in particular has the following benefits:
 93 | 
 94 | - Has been audited
 95 | - Used by other blockchains and therefore has common libraries for implementation
 96 | 
 97 | **Note**: This library internally re-hashes its input to a 128-bit entropy string
 98 | 
 99 | ### Hash algorithms used in Byron + ITN
100 | 
101 | 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).
102 | 
103 | For `hash_to_32` we use CRC32. We hash a second time for the following:
104 | 
105 | 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.
106 | 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.
107 | 3) `CRC32` is used in the Byron implementation of Cardano as a checksum for addresses, meaning no additional dependency has to be added.
108 | 
109 | 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)
110 | 
111 | ### Hash algorithms used in Shelley mainnet
112 | 
113 | 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.
114 | 2) For `hash_to_32`, we no longer use `crc32` for the following reasons:
115 | 
116 | - It has multiple competing implementations all called `crc32` (easily to get the wrong implementation library)
117 | - It requires building a lookup table, making it slower than other hashing algorithms for similar safety
118 | - 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.
119 | 
120 | 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.
121 | 
122 | ### When no public key is present
123 | 
124 | 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.
125 | 
126 | ## Reference implementation
127 | 
128 | - [Javascript implementation](https://github.com/Emurgo/CIP4) (contains test vectors)
129 | 
130 | ## Copyright
131 | 
132 | This CIP is licensed under Apache-2.0
133 | 


--------------------------------------------------------------------------------
/CIP-0005/CIP-0005.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | CIP: 5
  3 | Title: Common Bech32 Prefixes
  4 | Authors: Matthias Benkort <matthias.benkort@iohk.io>
  5 | Comments-URI: https://forum.cardano.org/t/cip5-common-bech32-prefixes/35189
  6 | Status: Draft
  7 | Type: Standards
  8 | Created: 2020-05-28
  9 | License: Apache-2.0
 10 | ---
 11 | 
 12 | ## Abstract
 13 | 
 14 | 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.
 15 | 
 16 | ## Motivation
 17 | 
 18 | 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).
 19 | 
 20 | 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.
 21 | 
 22 | ## Specification
 23 | 
 24 | 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.
 25 | 
 26 | #### Keys
 27 | 
 28 | | Prefix       | Meaning                                 | Contents                                               |
 29 | | ---          | ---                                     | ---                                                    |
 30 | | `acct_sk`    | CIP-1852's Account private key          | Ed25519 private key                                    |
 31 | | `acct_vk`    | CIP-1852's Account public key           | Ed25519 public key                                     |
 32 | | `acct_xsk`   | CIP-1852's extended Account private key | Ed25519-bip32 extended private key                     |
 33 | | `acct_xvk`   | CIP-1852's extended Account public key  | Ed25519 public key with chain code                     |
 34 | | `addr_sk`    | Address signing key                     | Ed25519 private key                                    |
 35 | | `addr_vk`    | Address verification key                | Ed25519 public key                                     |
 36 | | `addr_xsk`   | Address extended signing key            | Ed25519-bip32 extended private key                     |
 37 | | `addr_xvk`   | Address extended verification key       | Ed25519 public key with chain code                     |
 38 | | `kes_sk`     | KES signing key                         | KES signing key                                        |
 39 | | `kes_vk`     | KES verification key                    | KES verification key                                   |
 40 | | `pool_sk`    | Pool operator signing key               | Ed25519 private key                                    |
 41 | | `pool_vk`    | Pool operator verification key          | Ed25519 public key                                     |
 42 | | `root_sk`    | CIP-1852's root private key             | Ed25519 private key                                    |
 43 | | `root_vk`    | CIP-1852's root public key              | Ed25519 public key                                     |
 44 | | `root_xsk`   | CIP-1852's extended root private key    | Ed25519-bip32 extended private key                     |
 45 | | `root_xvk`   | CIP-1852's extended root public key     | Ed25519 public key with chain code                     |
 46 | | `script_sk`  | Script signing key                      | Ed25519 private key                                    |
 47 | | `script_vk`  | Script verification key                 | Ed25519 public key                                     |
 48 | | `script_xsk` | Extended script signing key             | Ed25519-bip32 extended private key                     |
 49 | | `script_xvk` | Extended script verification key        | Ed25519 public key with chain code                     |
 50 | | `stake_sk`   | Stake address signing key               | Ed25519 private key                                    |
 51 | | `stake_vk`   | Stake address verification key          | Ed25519 public key                                     |
 52 | | `stake_xsk`  | Extended stake address signing key      | Ed25519-bip32 extended private key                     |
 53 | | `stake_xvk`  | Extended stake address verification key | Ed25519 public key with chain code                     |
 54 | | `vrf_sk`     | VRF signing key                         | VRF signing key                                        |
 55 | | `vrf_vk`     | VRF verification key                    | VRF verification key                                   |
 56 | 
 57 | #### Hashes
 58 | 
 59 | | Prefix       | Meaning                                            | Contents                                               |
 60 | | ---          | ---                                                | ---                                                    |
 61 | | `asset`      | Fingerprint of a native asset for human comparison | See [CIP-0014]                                         |
 62 | | `pool`       | Pool operator verification key hash (pool ID)      | blake2b\_224 digest of an operator verification key    |
 63 | | `script`     | Script hash                                        | blake2b\_224 digest of a serialized transaction script |
 64 | | `addr_vkh`   | Address verification key hash                      | blake2b\_224 digest of a payment verification key      |
 65 | | `script_vkh` | Script verification key hash                       | blake2b\_224 digest of a script verification key       |
 66 | | `stake_vkh`  | Stake address verification key hash                | blake2b\_224 digest of a delegation verification key   |
 67 | | `vrf_vkh`    | VRF verification key hash                          | blake2b\_256 digest of a VRF verification key          |
 68 | 
 69 | 
 70 | #### Miscellaneous 
 71 | 
 72 | | Prefix       | Meaning               | Contents                                                      |
 73 | | ---          | ---                   | ---                                                           |
 74 | | `addr`       | Mainnet address       | Network tag, payment credential and optional stake credential |
 75 | | `addr_test`  | Testnet address       | Network tag, payment credential and optional stake credential |
 76 | | `stake`      | Mainnet stake address | Network tag and stake credential                              |
 77 | | `stake_test` | Testnet stake address | Network tag and stake credential                              |
 78 | 
 79 | 
 80 | ## Rationale
 81 | 
 82 | #### About the `_test` suffix
 83 | 
 84 | 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.
 85 | 
 86 | Therefore, having a clear human-readable indicator regarding the network discrimination is useful.
 87 | 
 88 | #### About `addr`
 89 | 
 90 | Addresses probably are the most user-facing object in the current Cardano eco-system. Being able to clearly identify them
 91 | 
 92 | > :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.`
 93 | 
 94 | #### About `stake`
 95 | 
 96 | 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.
 97 | 
 98 | #### About `sk` & `vk`
 99 | 
100 | Both are rather transparent abbreviations for **s**igning **k**ey and **v**erification **k**ey.
101 | 
102 | #### About `xsk` & `xvk`
103 | 
104 | 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.
105 | 
106 | #### About `vkh`
107 | 
108 | An abbreviation for **v**erification **k**ey **h**ash.
109 | 
110 | Verification key hashes are commonly utilized throughout the Cardano
111 | eco-system. For example, they're used in stake pool registration and
112 | retirement certificates, stake key registration, delegation, and
113 | deregistration certificates, etc. As a result, it seems useful to have a
114 | human-readable prefix by which one can discern the different kinds of
115 | verification key hashes.
116 | 
117 | ## Backwards compatibility
118 | 
119 | 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.
120 | 
121 | ## Reference implementation
122 | 
123 | N/A
124 | 
125 | ## Copyright
126 | 
127 | This CIP is licensed under Apache-2.0.
128 | 
129 | [CIP-0014]: https://github.com/cardano-foundation/CIPs/blob/645243e30b5aae109a70ec2b47af70dcc808bc56/CIP-0014/CIP-0014.md
130 | 


--------------------------------------------------------------------------------
/CIP-0005/LICENSE:
--------------------------------------------------------------------------------
 1 | Apache License
 2 | Version 2.0, January 2004
 3 | http://www.apache.org/licenses/
 4 | 
 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 6 | 
 7 | 1. Definitions.
 8 | 
 9 | "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
10 | 
11 | "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
12 | 
13 | "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
14 | 
15 | "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.
16 | 
17 | "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
18 | 
19 | "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
20 | 
21 | "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
22 | 
23 | "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
24 | 
25 | "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
26 | 
27 | "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
28 | 
29 | 2. Grant of Copyright License.
30 | 
31 | Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
32 | 
33 | 3. Grant of Patent License.
34 | 
35 | Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
36 | 
37 | 4. Redistribution.
38 | 
39 | You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
40 | 
41 |     You must give any other recipients of the Work or Derivative Works a copy of this License; and
42 |     You must cause any modified files to carry prominent notices stating that You changed the files; and
43 |     You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
44 |     If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
45 | 
46 | You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
47 | 
48 | 5. Submission of Contributions.
49 | 
50 | Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
51 | 
52 | 6. Trademarks.
53 | 
54 | This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
55 | 
56 | 7. Disclaimer of Warranty.
57 | 
58 | Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
59 | 
60 | 8. Limitation of Liability.
61 | 
62 | In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
63 | 
64 | 9. Accepting Warranty or Additional Liability.
65 | 
66 | While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
67 | 
68 | END OF TERMS AND CONDITIONS
69 | 
70 | Copyright 2020 - Matthias Benkort <matthias.benkort@iohk.io>
71 | 
72 | Licensed under the Apache License, Version 2.0 (the "License");
73 | you may not use this file except in compliance with the License.
74 | You may obtain a copy of the License at
75 | 
76 |  http://www.apache.org/licenses/LICENSE-2.0
77 | 
78 | Unless required by applicable law or agreed to in writing, software
79 | distributed under the License is distributed on an "AS IS" BASIS,
80 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
81 | See the License for the specific language governing permissions and
82 | limitations under the License.
83 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/09-22-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [September 22 2020 notes](#september-22-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |       + [Curve Pledge Benefit](#Curve-Pledge-Benefit)
 10 |       + [Extended Metadata](#Extended-Metadata)
 11 |   * [Discussions](#discussions)
 12 |   * [Close](#close)
 13 | - [Extra](#extra)
 14 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 15 |   * [CIP creation process as a UML Diagram](#cip-creation-process-as-a-uml-diagram)
 16 |   * [Understanding CIPs further](#understanding-cips-further)
 17 | ## Summary
 18 | 
 19 | 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.  
 20 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 21 | </sub>
 22 | 
 23 | 
 24 | ## Editors Meeting Flow
 25 | - [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..
 26 | - [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)
 27 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 28 | PR -> ‘Draft’: Needs format + approval.  
 29 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 30 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 31 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 32 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 33 | 
 34 | 
 35 | 
 36 | ## September 22 2020 notes
 37 | 
 38 | 
 39 | **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Jeremy(CF) + Shawn, Markus (PR Authors) + Collin (IOG)
 40 | 
 41 | 
 42 | ### Triage
 43 | N/A
 44 | 
 45 | ### Last Check
 46 | N/A 
 47 | 
 48 | ### Review  
 49 | 
 50 | 
 51 | #### Curve Pledge Benefit
 52 | ([PR](https://github.com/cardano-foundation/CIPs/pull/12) - potential CIP7) 
 53 | 
 54 | 
 55 | 
 56 | **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).
 57 | (see graphs in the PR)  
 58 | **Duncan** - Not as simple, incentive folks are exploring all scenarios  
 59 | **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.  
 60 | **Duncan** - This has been raised internally with IOHK researchers already - they weren’t so positive about it, but have been looking at it.  
 61 | **Colin** - They are in the long term equilibrium - but right now the linear isn’t working.  
 62 | **Duncan** - It was mentioned it should probably be skewed in the opposite direction..  
 63 | **Colin** - if you can get the delegation bonus as a big holder, you’re much better off splitting into tiny pools right now  
 64 | **Duncan** - Researchers are aware of that -  which direction it goes non-linear might cause issues.  
 65 | At no point should it be non-rewarding to add more stake to your pool.  
 66 | **Markus** - What about a ‘S’ curve mentioned by Charles?  
 67 | **Colin** - (Showing example graph) = M * (1/p)  + N * p  
 68 | **Markus** - There are some good points or reasons that this can help  
 69 | What are the drawbacks or downsides based on a linear and non-linear approach?  
 70 | **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.  
 71 | ***[Move to MERGE as CIP7]*** (all agree)
 72 | 
 73 | 
 74 | 
 75 | #### Extended Metadata
 76 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)
 77 | 
 78 | 
 79 | **Markus** - Recap on the conversation since last meeting: 
 80 | 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.  
 81 | **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.  
 82 | **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.  
 83 | **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...  
 84 | **Markus** - Need to speak with more pool operators to see the approaches out there. I Will reach out and follow up.  
 85 | **Frederic** - Might be good to have competing views and discuss publicly, Multiple CIPs can propose different implementation proposals.  
 86 | **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.  
 87 | **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  
 88 | **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.  
 89 | **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.  
 90 | 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.  
 91 | **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.  
 92 | **Markus** - Will look at rewriting the existing PR with assistance of ADApools and reframe/rework proposal next.  
 93 | **Frederic** - Can be discussed in comments of the CIP as draft maybe? (would like to bring it in)  
 94 | **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).  
 95 | Focus on mechanism, security towards minimum amount of metadata to prevent issues.  
 96 | Follow the JSON schema and explanation of each field. BIP44 or BIP32 has a template for similar extensions.  
 97 | Future CIPs might want to add additional Metadata fields and should be structured in this way… it’ll provide a template for future discussions.  
 98 | **Frederic** - Wrapping up on the meeting: Review ‘CIP6’ in 2 weeks.  
 99 | ‘Merge of CIP7’ once Legal ok.  
100 | Markus to talk to the community about security and minimal metadata...  
101 | **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..  
102 | 
103 | ### Discussions 
104 | N/A - not enough time due to extended reviews.  
105 | CIP4 to be looked at in async channels and moved to next meeting.
106 | 
107 | 
108 | ### Close
109 | 
110 | **On Hold** Change Format of CIPs (in CIP1) (instead CIPx.md) - awaiting Frontend fix to auto-gen site  
111 | **TODO**  Merge Curve proposal / ‘CIP7’ once legal oks.
112 | 
113 | 
114 | ---
115 | ## Extra
116 | 
117 | ### Current CIPs in the CIP repository and their status 
118 | 
119 | 
120 | |#              |Title            | Status               |
121 | | ----------------- |:----------------|:-------------------- |
122 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
123 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
124 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
125 | 
126 | 
127 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
128 | 
129 | 
130 | ### CIP creation process as a Sequence Diagram
131 | 
132 | _"Alice has a Cardano idea she'd like to build more formally":_
133 | 
134 | 
135 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
136 | 
137 | ### Understanding CIPs further
138 | 
139 | 
140 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
141 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
142 | 
143 | 
144 | 


--------------------------------------------------------------------------------
/assets/css/styles.css:
--------------------------------------------------------------------------------
  1 | :root {
  2 | 	--nc-font-sans: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
  3 | 	--nc-font-mono: Consolas, monaco, 'Ubuntu Mono', 'Liberation Mono', 'Courier New', Courier, monospace;
  4 | 	--nc-tx-1: #000000;
  5 | 	--nc-tx-2: #1A1A1A;
  6 | 	--nc-bg-1: #FFFFFF;
  7 | 	--nc-bg-2: #F6F8FA;
  8 | 	--nc-bg-3: #E5E7EB;
  9 | 	--nc-lk-1: #0070F3;
 10 | 	--nc-lk-2: #0366D6;
 11 | 	--nc-lk-tx: #FFFFFF;
 12 | 	--nc-ac-1: #79FFE1;
 13 |     --nc-ac-tx: #0C4047;
 14 | }
 15 | 
 16 | @media (prefers-color-scheme: light) {
 17 | 	:root {
 18 | 		--nc-tx-1: #000000;
 19 | 		--nc-tx-2: #111111;
 20 | 		--nc-bg-1: #ffffff;
 21 | 		--nc-bg-2: #eeeeee;
 22 | 		--nc-bg-3: #dddddd;
 23 | 		--nc-lk-1: #3291FF;
 24 | 		--nc-lk-2: #0070F3;
 25 | 		--nc-lk-tx: #000000;
 26 | 		--nc-ac-1: #7928CA;
 27 | 		--nc-ac-tx: #000000;
 28 | 	}
 29 | }
 30 | 
 31 | * {
 32 | 	/* Reset margins and padding */
 33 | 	margin: 0;
 34 | 	padding: 0;
 35 | }
 36 | 
 37 | address,
 38 | area,
 39 | article,
 40 | aside,
 41 | audio,
 42 | blockquote,
 43 | datalist,
 44 | details,
 45 | dl,
 46 | fieldset,
 47 | figure,
 48 | form,
 49 | input,
 50 | iframe,
 51 | img,
 52 | meter,
 53 | nav,
 54 | ol,
 55 | optgroup,
 56 | option,
 57 | output,
 58 | p,
 59 | pre,
 60 | progress,
 61 | ruby,
 62 | section,
 63 | table,
 64 | textarea,
 65 | ul,
 66 | video {
 67 | 	/* Margins for most elements */
 68 | 	margin-bottom: 1rem;
 69 | }
 70 | 
 71 | html,input,select,button {
 72 | 	/* Set body font family and some finicky elements */
 73 | 	font-family: var(--nc-font-sans);
 74 | }
 75 | 
 76 | body {
 77 | 	/* Center body in page */
 78 | 	margin: 0 auto;
 79 | 	max-width: 750px;
 80 | 	padding: 2rem;
 81 | 	border-radius: 6px;
 82 | 	overflow-x: hidden;
 83 | 	word-break: break-word;
 84 | 	overflow-wrap: break-word;
 85 | 	background: var(--nc-bg-1);
 86 | 
 87 | 	/* Main body text */
 88 | 	color: var(--nc-tx-2);
 89 | 	font-size: 1.03rem;
 90 | 	line-height: 1.5;
 91 | }
 92 | 
 93 | ::selection {
 94 | 	/* Set background color for selected text */
 95 | 	background: var(--nc-ac-1);
 96 | 	color: var(--nc-ac-tx);
 97 | }
 98 | 
 99 | h1,h2,h3,h4,h5,h6 {
100 | 	line-height: 1;
101 | 	color: var(--nc-tx-1);
102 | 	padding-top: .875rem;
103 | }
104 | 
105 | h1,
106 | h2,
107 | h3 {
108 | 	color: var(--nc-tx-1);
109 | 	padding-bottom: 2px;
110 | 	margin-bottom: 8px;
111 | 	border-bottom: 1px solid var(--nc-bg-2);
112 | }
113 | 
114 | h4,
115 | h5,
116 | h6 {
117 | 	margin-bottom: .3rem;
118 | }
119 | 
120 | h1 {
121 | 	font-size: 2.25rem;
122 | }
123 | 
124 | h2 {
125 | 	font-size: 1.85rem;
126 | }
127 | 
128 | h3 {
129 | 	font-size: 1.55rem;
130 | }
131 | 
132 | h4 {
133 | 	font-size: 1.25rem;
134 | }
135 | 
136 | h5 {
137 | 	font-size: 1rem;
138 | }
139 | 
140 | h6 {
141 | 	font-size: .875rem;
142 | }
143 | 
144 | a {
145 | 	color: var(--nc-lk-1);
146 | }
147 | 
148 | a:hover {
149 | 	color: var(--nc-lk-2);
150 | }
151 | 
152 | abbr:hover {
153 | 	/* Set the '?' cursor while hovering an abbreviation */
154 | 	cursor: help;
155 | }
156 | 
157 | blockquote {
158 | 	padding: 1.5rem;
159 | 	background: var(--nc-bg-2);
160 | 	border-left: 5px solid var(--nc-bg-3);
161 | }
162 | 
163 | abbr {
164 | 	cursor: help;
165 | }
166 | 
167 | blockquote *:last-child {
168 | 	padding-bottom: 0;
169 | 	margin-bottom: 0;
170 | }
171 | 
172 | header {
173 | 	background: var(--nc-bg-2);
174 | 	border-bottom: 1px solid var(--nc-bg-3);
175 | 	padding: 2rem 1.5rem;
176 | 	
177 | 	/* This sets the right and left margins to cancel out the body's margins. It's width is still the same, but the background stretches across the page's width. */
178 | 
179 | 	margin: -2rem calc(0px - (50vw - 50%)) 2rem;
180 | 
181 | 	/* Shorthand for:
182 | 
183 | 	margin-top: -2rem;
184 | 	margin-bottom: 2rem;
185 | 
186 | 	margin-left: calc(0px - (50vw - 50%));
187 | 	margin-right: calc(0px - (50vw - 50%)); */
188 | 	
189 | 	padding-left: calc(50vw - 50%);
190 | 	padding-right: calc(50vw - 50%);
191 | }
192 | 
193 | header h1,
194 | header h2,
195 | header h3 {
196 | 	padding-bottom: 0;
197 | 	border-bottom: 0;
198 | }
199 | 
200 | header > *:first-child {
201 | 	margin-top: 0;
202 | 	padding-top: 0;
203 | }
204 | 
205 | header > *:last-child {
206 | 	margin-bottom: 0;
207 | }
208 | 
209 | a button,
210 | button,
211 | input[type="submit"],
212 | input[type="reset"],
213 | input[type="button"] {
214 | 	font-size: 1rem;
215 | 	display: inline-block;
216 | 	padding: 6px 12px;
217 | 	text-align: center;
218 | 	text-decoration: none;
219 | 	white-space: nowrap;
220 | 	background: var(--nc-lk-1);
221 | 	color: var(--nc-lk-tx);
222 | 	border: 0;
223 | 	border-radius: 4px;
224 | 	box-sizing: border-box;
225 | 	cursor: pointer;
226 | 	color: var(--nc-lk-tx);
227 | }
228 | 
229 | a button[disabled],
230 | button[disabled],
231 | input[type="submit"][disabled],
232 | input[type="reset"][disabled],
233 | input[type="button"][disabled] {
234 | 	cursor: default;
235 | 	opacity: .5;
236 | 
237 | 	/* Set the [X] cursor while hovering a disabled link */
238 | 	cursor: not-allowed;
239 | }
240 | 
241 | .button:focus,
242 | .button:hover,
243 | button:focus,
244 | button:hover,
245 | input[type="submit"]:focus,
246 | input[type="submit"]:hover,
247 | input[type="reset"]:focus,
248 | input[type="reset"]:hover,
249 | input[type="button"]:focus,
250 | input[type="button"]:hover {
251 | 	background: var(--nc-lk-2);
252 | }
253 | 
254 | code,
255 | pre,
256 | kbd,
257 | samp {
258 | 	/* Set the font family for monospaced elements */
259 | 	font-family: var(--nc-font-mono);
260 | }
261 | 
262 | code,
263 | samp,
264 | kbd,
265 | pre {
266 | 	/* The main preformatted style. This is changed slightly across different cases. */
267 | 	background: var(--nc-bg-2);
268 | 	border: 1px solid var(--nc-bg-3);
269 | 	border-radius: 4px;
270 | 	padding: 3px 6px;
271 | 	font-size: 0.9rem;
272 | }
273 | 
274 | kbd {
275 | 	/* Makes the kbd element look like a keyboard key */
276 | 	border-bottom: 3px solid var(--nc-bg-3);
277 | }
278 | 
279 | pre {
280 | 	padding: 1rem 1.4rem;
281 | 	max-width: 100%;
282 | 	overflow: auto;
283 | }
284 | 
285 | pre code {
286 | 	/* When <code> is in a <pre>, reset it's formatting to blend in */
287 | 	background: inherit;
288 | 	font-size: inherit;
289 | 	color: inherit;
290 | 	border: 0;
291 | 	padding: 0;
292 | 	margin: 0;
293 | }
294 | 
295 | code pre {
296 | 	/* When <pre> is in a <code>, reset it's formatting to blend in */
297 | 	display: inline;
298 | 	background: inherit;
299 | 	font-size: inherit;
300 | 	color: inherit;
301 | 	border: 0;
302 | 	padding: 0;
303 | 	margin: 0;
304 | }
305 | 
306 | details {
307 | 	/* Make the <details> look more "clickable" */
308 | 	padding: .6rem 1rem;
309 | 	background: var(--nc-bg-2);
310 | 	border: 1px solid var(--nc-bg-3);
311 | 	border-radius: 4px;
312 | }
313 | 
314 | summary {
315 | 	/* Makes the <summary> look more like a "clickable" link with the pointer cursor */
316 | 	cursor: pointer;
317 | 	font-weight: bold;
318 | }
319 | 
320 | details[open] {
321 | 	/* Adjust the <details> padding while open */
322 | 	padding-bottom: .75rem;
323 | }
324 | 
325 | details[open] summary {
326 | 	/* Adjust the <details> padding while open */
327 | 	margin-bottom: 6px;
328 | }
329 | 
330 | details[open]>*:last-child {
331 | 	/* Resets the bottom margin of the last element in the <details> while <details> is opened. This prevents double margins/paddings. */
332 | 	margin-bottom: 0;
333 | }
334 | 
335 | dt {
336 | 	font-weight: bold;
337 | }
338 | 
339 | dd::before {
340 | 	/* Add an arrow to data table definitions */
341 | 	content: '→ ';
342 | }
343 | 
344 | hr {
345 | 	/* Reset the border of the <hr> separator, then set a better line */
346 | 	border: 0;
347 | 	border-bottom: 1px solid var(--nc-bg-3);
348 | 	margin: 1rem auto;
349 | }
350 | 
351 | fieldset {
352 | 	margin-top: 1rem;
353 | 	padding: 2rem;
354 | 	border: 1px solid var(--nc-bg-3);
355 | 	border-radius: 4px;
356 | }
357 | 
358 | legend {
359 | 	padding: auto .5rem;
360 | }
361 | 
362 | table {
363 | 	/* border-collapse sets the table's elements to share borders, rather than floating as separate "boxes". */
364 | 	border-collapse: collapse;
365 | 	width: 100%
366 | }
367 | 
368 | td,
369 | th {
370 | 	border: 1px solid var(--nc-bg-3);
371 | 	text-align: left;
372 |   padding: .5rem;
373 |   word-break: normal;
374 | }
375 | 
376 | th {
377 |   background: var(--nc-bg-2);
378 |   white-space: nowrap;
379 | }
380 | 
381 | tr:nth-child(even) {
382 | 	/* Set every other cell slightly darker. Improves readability. */
383 | 	background: var(--nc-bg-2);
384 | }
385 | 
386 | table caption {
387 | 	font-weight: bold;
388 | 	margin-bottom: .5rem;
389 | }
390 | 
391 | textarea {
392 | 	/* Don't let the <textarea> extend off the screen naturally or when dragged by the user */
393 | 	max-width: 100%;
394 | }
395 | 
396 | ol,
397 | ul {
398 | 	/* Replace the browser default padding */
399 | 	padding-left: 2rem;
400 | }
401 | 
402 | li {
403 | 	margin-top: .4rem;
404 | }
405 | 
406 | ul ul,
407 | ol ul,
408 | ul ol,
409 | ol ol {
410 | 	margin-bottom: 0;
411 | }
412 | 
413 | mark {
414 | 	padding: 3px 6px;
415 | 	background: var(--nc-ac-1);
416 | 	color: var(--nc-ac-tx);
417 | }
418 | 
419 | textarea,
420 | select,
421 | input {
422 | 	padding: 6px 12px;
423 | 	margin-bottom: .5rem;
424 | 	background: var(--nc-bg-2);
425 | 	color: var(--nc-tx-2);
426 | 	border: 1px solid var(--nc-bg-3);
427 | 	border-radius: 4px;
428 | 	box-shadow: none;
429 | 	box-sizing: border-box;
430 | }
431 | 
432 | img {
433 | 	max-width: 100%;
434 | }
435 | 
436 | .brand {
437 |   display: flex;
438 |   text-decoration: none;
439 | }
440 | .logo {
441 |   width: 4rem;
442 |   margin-right: 0.5rem;
443 | }
444 | body {
445 |   font-family: 'Open Sans', sans-serif;
446 | }
447 | 
448 | header ul {
449 |   list-style: none;
450 | 
451 | }
452 | header ul li {
453 |   display: inline;
454 |   padding: 1rem;
455 |   font-size: 1.4rem;
456 | }
457 | 
458 | @media (max-width: 768px) {
459 |   header, footer {
460 |     padding: 0.2rem
461 |   }
462 |   .content {
463 |     padding: 0.5rem;
464 |   }
465 | }
466 | 
467 | #toc_container {
468 |   background: #f9f9f9 none repeat scroll 0 0;
469 |   border: 1px solid #aaa;
470 | }
471 | 
472 | .toc_title {
473 |   font-weight: 700;
474 | 	text-align: left;
475 | 	margin-left:1rem;
476 | }


--------------------------------------------------------------------------------
/BiweeklyMeetings/11-17-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [November 17 2020 notes](#november-17-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |       + [Wallet key generation](#Wallet-key-generation)
  9 |   * [Review](#review)
 10 |       + [Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)
 11 |       + [Extended Metadata](#Extended-Metadata)
 12 |       + [Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)
 13 |       + [HD Wallet for Cardano](#HD-Wallet-for-Cardano)
 14 |       + [Cardano URI Scheme](#Cardano-URI-Scheme)
 15 |   * [Discussions](#discussions)
 16 |   * [Close](#close)
 17 | - [Extra](#extra)
 18 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 19 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 20 |   * [Understanding CIPs further](#understanding-cips-further)
 21 | ## Summary
 22 | 
 23 | 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.  
 24 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 25 | </sub>
 26 | 
 27 | 
 28 | ## Editors Meeting Flow
 29 | - [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..
 30 | - [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)
 31 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 32 | PR -> ‘Draft’: Needs format + approval.  
 33 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 34 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 35 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 36 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 37 | 
 38 | 
 39 | ## November 17 2020 notes  
 40 | **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Colin, Lars (IO) + Marek, Federico (community)
 41 | 
 42 | ### Triage  
 43 | N/A
 44 | 
 45 | ### Last Check  
 46 | #### Wallet key generation  
 47 | ([PR](https://github.com/cardano-foundation/CIPs/pull/3) - potential CIP3)  
 48 | **S** - minor column changes being added. Merge Once reviewed by Matthias. 
 49 | => Merge as soon as reviewed  
 50 | 
 51 | ### Review  
 52 | 
 53 | #### Treasury Fraction on actual distributed rewards  
 54 | ([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)  
 55 | **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. 
 56 | 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.  
 57 | **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.  
 58 | **Sebastien** - Do you specify a percentage in here?  
 59 | **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.  
 60 | **S** so next steps is to merge this PR then go to IOHK to look at percent
 61 | **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... 
 62 | (Back and forth about Monetary expansion setup)  
 63 | **F** - Tau levvy is applied on reward pot before calculating rewards (+Frederic +Lars)
 64 | (Looking at [ledger specs](https://hydra.iohk.io/job/Cardano/cardano-ledger-specs/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec))  
 65 | **L** - Page 62. Middle of the page. Jarod ideally the good person to ask (or Philipp).  
 66 | **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.  
 67 | **D** - Probably correct in the mathematics but not the prose.  
 68 | **L** - It says october 2019 which seems old?  
 69 | **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.  
 70 | **F** - The discussion is about the unclaimed rewards, for varied reasons. We want to minimize the multi-treasury taxation. 
 71 | **S** - Two pts. double taxation. convo can happen offline. Changing Tau is not a HF event.  
 72 | **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.   
 73 | (=> To be followed up on structure-wise next meeting, pending added clarifications)
 74 | 
 75 | 
 76 | 
 77 | #### Extended Metadata  
 78 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   
 79 | **Frederic** - Some conversation happened in PR but missing answers/followup  
 80 | **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.  
 81 | **F** - I'm with Matthias, would want to move this and let conversation continue as Draft.  
 82 | **D** - It's distracting to have contingent conversations about content, easier to start with a detailed mechanism. Then we can add to it incrementally.
 83 | **S** - Pushing out to next meeting.  
 84 | => Follow-up next meeting.  
 85 | 
 86 | 
 87 | 
 88 | #### Staking Key Chain for HD Wallets  
 89 | ([PR](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP)  
 90 | **S** - This is one of the two CIPs I split 1852 in. This one specifies the key/derivation path.  
 91 | **M** - Haven't reviewed. will do until next meeting.  
 92 | => Merge in two weeks pending Matthias review  
 93 | 
 94 | 
 95 | #### HD Wallet for Cardano  
 96 | ([PR](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP1852)   
 97 | **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.  
 98 | => Merge in two weeks pending Matthias review  
 99 | 
100 | 
101 | #### Cardano URI Scheme  
102 | ([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)   
103 | **S** - Could be merged ... but nobody has had time to review yet.  
104 | => Move to next meeting  
105 | 
106 | 
107 | ### Discussions  
108 | **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).  
109 | 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.  
110 | 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.
111 | 
112 | 
113 | ### Close  
114 | **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  
115 | **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.  
116 | **ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider  
117 | => Merge in two weeks: [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (potential ‘CIP1852’)  
118 | => Merge in two weeks: [“Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (potential ‘CIP’)  
119 | => Merge **NOW**: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)   
120 | 
121 | ---
122 | ## Extra
123 | 
124 | ### Current CIPs in the CIP repository and their status  
125 | 
126 | |#              |Title            | Status               |
127 | | ----------------- |:----------------|:-------------------- |
128 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
129 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
130 | | 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |
131 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
132 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
133 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
134 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
135 | | 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |
136 | 
137 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
138 | 
139 | 
140 | ### CIP creation process as a Sequence Diagram  
141 | _"Alice has a Cardano idea she'd like to build more formally":_
142 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
143 | 
144 | ### Understanding CIPs further
145 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
146 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
147 | 
148 | 
149 | 
150 | 
151 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/11-03-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [November 3 2020 notes](#november-3-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |   * [Review](#review)
  9 |       + [Extended Metadata](#Extended-Metadata)
 10 |       + [Wallet key generation](#Wallet-key-generation)
 11 |       + [HD Wallet for Cardano](#HD-Wallet-for-Cardano)
 12 |       + [Transaction Metadata Registry](#Transaction-Metadata-Registry)
 13 |       + [Cardano URI Scheme](#Cardano-URI-Scheme)
 14 |       + [ Treasury Fraction on actual distributed rewards](#Treasury-Fraction-on-actual-distributed-rewards)            
 15 |   * [Discussions](#discussions)
 16 |   * [Close](#close)
 17 | - [Extra](#extra)
 18 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 19 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 20 |   * [Understanding CIPs further](#understanding-cips-further)
 21 | ## Summary
 22 | 
 23 | 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.  
 24 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 25 | </sub>
 26 | 
 27 | 
 28 | ## Editors Meeting Flow
 29 | - [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..
 30 | - [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)
 31 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 32 | PR -> ‘Draft’: Needs format + approval.  
 33 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 34 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 35 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 36 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 37 | 
 38 | 
 39 | 
 40 | ## November 3 2020 notes  
 41 | **Attending**: (Duncan, Frederic, Matthias, Sebastien) + Ben (IO) + Markus (community)
 42 | 
 43 | ### Triage  
 44 | N/A
 45 | 
 46 | ### Last Check  
 47 | N/A
 48 | 
 49 | ### Review  
 50 | 
 51 | #### Extended Metadata  
 52 | ([PR](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP6)   
 53 | **F** - Last we looked at this CIP, the ask was for comments/feedback from major pools. Cardanians replied two weeks ago.   
 54 | **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.  
 55 | **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.  
 56 | **D** - Are you talking about a first level metadata contains a keyhash and a URL (to the secondary metadata level)?  
 57 | **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).  
 58 | **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.  
 59 | **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.  
 60 | **D** - Ordinary ed25519 key is the simplest thing to do.  
 61 | **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.  
 62 | **D** - Focus on the details of the mechanism, but also what the exact format of the witness/signature.  
 63 | **M** - I'll try it out and seek your feedback in the PR through comments.  
 64 | **Matthias** - For signature, go with simplest: if that's embedded, or on the side.. We don't want to complicate things.  
 65 | **M** - From operative pt of view, if SPO wants to integrate, it should be straightforward.  
 66 | **D** - Two files ok?   
 67 | **M** - yes - because when ext-metadata file is updated then would need to do other file (signature).   
 68 | **D** - The CLI would validate the json and generate the signature for you... But still two files you host.  
 69 | **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.  
 70 | **D** - ok maybe two URL.  
 71 | => On Hold, Markus to add comments to which Duncan will follow up in the PR regarding scheme.  
 72 | 
 73 | #### Wallet key generation  
 74 | ([PR](https://github.com/cardano-foundation/CIPs/pull/3)  - potential CIP3)  
 75 | **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.  
 76 | **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..   
 77 | **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").  
 78 | **D** - Fine if you both approve this.  
 79 | **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).   
 80 | => Merge in two weeks  
 81 | 
 82 | 
 83 | #### HD Wallet for Cardano  
 84 | ([PR](https://github.com/cardano-foundation/CIPs/pull/27) - potential CIP1852)  
 85 | **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"...   
 86 | **M** - We just started calling it "Roles". We also use it for the multisig key. I would push we publish this CIP very soon.  
 87 | **D** - I think that's most sensible terminology..  
 88 | **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...  
 89 | **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?  
 90 | **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.  
 91 | **S** - I'll split this CIP in two parts then (a CIP for allocating numbers and a separate CIP for the specific role itself)  
 92 | => ON hold, Sebastien to split into two  
 93 | 
 94 | 
 95 | #### Transaction Metadata Registry  
 96 | ([PR](https://github.com/cardano-foundation/CIPs/pull/34) - potential CIP10)  
 97 | **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.  
 98 | **S** - The SPOCRA ppl already started metadata and have 200-300 Tx on mainnet. They will probably be the first to allocate numbers...  
 99 | **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.  
100 | => Merge **NOW** (as other CIPs will depend on this / need the draft).  
101 | 
102 | #### Cardano URI Scheme  
103 | ([PR](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)  
104 | **S** - We will need to change and merge two CIPs together. Moving on.  
105 | 
106 | #### Treasury Fraction on actual distributed rewards  
107 | ([PR](https://github.com/cardano-foundation/CIPs/pull/35) - potential CIP)  
108 | **S** - This was on the agenda so we can get Duncan's take on who should be involved.  
109 | **D** - Lars Brunje. He'll direct through the right teams review and provide feedback.  
110 | 
111 | 
112 | 
113 | ### Discussions  
114 | **F** - Crowdcast issues. Will follow-up and attempt to resolve for next meeting.  
115 | 
116 | 
117 | 
118 | ### Close  
119 | **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  
120 | **ON Hold** [“Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (potential ‘CIP6’) - extend conversation in PR.  
121 | **ON Hold** [“HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/27) (potential ‘CIP1852’) - to be split into two PRs by Sebastien  
122 | **ON Hold** [“Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - Requesting feedback and review from scientists  
123 | => Merge in two weeks: [“Wallet key generation”](https://github.com/cardano-foundation/CIPs/pull/3) to be merged as ‘Draft’ (‘CIP3’)    
124 | => Merge **NOW**: [“Metadata Registry”](https://github.com/cardano-foundation/CIPs/pull/34)to be merged as ‘Draft’ (‘CIP10’)   
125 | 
126 | ---
127 | ## Extra
128 | 
129 | ### Current CIPs in the CIP repository and their status  
130 | 
131 | |#              |Title            | Status               |
132 | | ----------------- |:----------------|:-------------------- |
133 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
134 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
135 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
136 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
137 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
138 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
139 | | 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |
140 | 
141 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
142 | 
143 | 
144 | ### CIP creation process as a Sequence Diagram  
145 | _"Alice has a Cardano idea she'd like to build more formally":_
146 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
147 | 
148 | ### Understanding CIPs further
149 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
150 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
151 | 
152 | 
153 | 
154 | 
155 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/12-08-2020.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [December 8 2020 notes](#december-8-2020-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |       + [PR37 - Staking Key Chain for HD Wallets](#Staking-Key-Chain-for-HD-Wallets)
  9 |       + [PR33 - HD Wallets for Cardano](#HD-Wallets-for-Cardano)
 10 |   * [Review](#review)
 11 |       + [PR30 - Cardano URI Scheme](#Cardano-URI-Scheme)
 12 |       + [PR45 - Cardano Protocol Parameters](#Cardano-Protocol-Parameters)
 13 |       + [PR44 - On-chain stake pool operator to delegates communication](#On-chain-stake-pool-operator-to-delegates-communication)
 14 |       + [PR15 - Extended Metadata](#Extended-Metadata)
 15 |   * [Discussions](#discussions)
 16 |   * [Close](#close)
 17 | - [Extra](#extra)
 18 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 19 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 20 |   * [Understanding CIPs further](#understanding-cips-further)
 21 | ## Summary
 22 | 
 23 | 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.  
 24 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 25 | </sub>
 26 | 
 27 | 
 28 | ## Editors Meeting Flow
 29 | - [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..
 30 | - [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)
 31 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 32 | PR -> ‘Draft’: Needs format + approval.  
 33 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 34 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 35 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 36 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 37 | 
 38 | 
 39 | ## December 8 2020 notes 
 40 | **Attending Editors**: (Duncan, Frederic, Matthias, Sebastien). 
 41 | 
 42 | ### Triage  
 43 | N/A
 44 | 
 45 | ### Last Check  
 46 | #### Staking Key Chain for HD Wallets  
 47 | ([PR37](https://github.com/cardano-foundation/CIPs/pull/37) - potential CIP-0011)  
 48 | **Matthias** - Good to merge and proceed.  
 49 | => **MERGING** now  
 50 | 
 51 | #### HD Wallets for Cardano  
 52 | ([PR33](https://github.com/cardano-foundation/CIPs/pull/33) - potential CIP-1852)  
 53 | **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)..  
 54 | => **MERGING** now  
 55 | 
 56 | ### Review  
 57 | 
 58 | #### Cardano URI Scheme  
 59 | ([PR30](https://github.com/cardano-foundation/CIPs/pull/30) - potential CIP)   
 60 | **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.  
 61 | **F** - Could we merge their PR rather than this?  
 62 | **S** - This one is ready to go, would be fine as-is.    
 63 | **M** - Going through it... There is no existing implementation of that is there..?  
 64 | **S** - Yes there is, Yoroi/Extension - the code is opensource  
 65 | **M** - Format is good, Grammar fine, we could add it in. Addresses are said to be base58 - we want to add Bech32 in there.  
 66 | => Merge in two weeks  
 67 | 
 68 | #### Cardano Protocol Parameters  
 69 | ([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP)   
 70 | **F** - Pushed by IOHK's Kevin Hammond, this is looking at the intial Protocol parameters as pushed in the genesis file.  
 71 | **M** - For Mainnet.  
 72 | **S** - Makes sense - concerned the actual OnChain version drifts from this CIP but could deal with that.  
 73 | **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.  
 74 | **S** - If we can auto-generate this, that would be ideal.  
 75 | **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.  
 76 | **S** - What next?  
 77 | **M** - Would require changes: disclaimer, link to genesis file...  
 78 | **F** - Doesn't the genesis file reflect the actual parameters as-is?  
 79 | **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.  
 80 | **F** - Adding this in this PR sounds useful.  
 81 | **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.  
 82 | **S** - I assumed this CIP was if people would want to propose parameters changes - if we want to make this we want to change.  
 83 | **Marek** - for this particular CIP I see this as for the *intial* parameters, not sure if this deals with *changing* the parameters.  
 84 | **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.  
 85 | **S** - Prefer this CIP be modified for each changes, and then when a new genesis block is added we flag it here.  
 86 | **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.   
 87 | **Matthias** - Do you mean one CIP per Hardfork?  
 88 | **Markus** - At least for every HardFork, maybe for protocol updates.   
 89 | **D** - This only contains updateable characters.  
 90 | **Matthias** - We should add the non-updateable parameters then (of the genesis file)  
 91 | **D** - Good idea.  
 92 | **F** - I think it'd be easier if kept in one CIP. I think both can work, Markus' option should be explored.  
 93 | **D** - Another CIP would enable a fleshed out rationale.  
 94 | **Markus** - If we do through PRs for soft-changes and new CIP for Hardforks, then we should rename this one.  
 95 | **D** - This CIP should highlight how future changes would be done.  
 96 | **F** - This one as Standards might be better as Informational to support the state of things.  
 97 | **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.  
 98 | **D** - Let's propose the changes rather than burden Kevin? Change to Informational & others.  
 99 | **Marek** - will work on it.  
100 | => Review in two weeks    
101 | 
102 | #### On-chain stake pool operation to delegates communication  
103 | ([PR44](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP)    
104 | **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.  
105 | **D** - Why do this rather than a RSS feed... Why want it auditable?  
106 | **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.  
107 | Not sure how much this will be used in the future but wanted to cover that space.  
108 | **D** - Seems focused on folks that work on the Wallet frontends.  
109 | **Matthias** - I don't think Darko would have any problem with having multiple CIPs for this, the implementation would fall on my team.   
110 | **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.  
111 | **Marek** - I was reluctant to send link to delegators even.  
112 | **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".  
113 | **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.    
114 | **D** - Reasonable proposal.  
115 | **S** - let's remove the link part, and merge.  
116 | **Marek** - will do changes now, can do now.  
117 | => Merge in two weeks  
118 | 
119 | #### Extended Metadata  
120 | ([PR15](https://github.com/cardano-foundation/CIPs/pull/44) - potential CIP-0006)  
121 | **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)   
122 | **D** - That can be changed.  
123 | **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.  
124 | **F** - Sounds like a separate CIP - here the title could be clarified. Want this to be merged.  
125 | **Markus** - Let's keep in mind: we need CLI support for this to be actually implemented.  
126 | **F** - Right - Inclusion to repo does not imply it will be imlemented, hopefully support in CLI comes.  
127 | **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.  
128 | **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.  
129 | => Merge in two weeks (?)  
130 | 
131 | 
132 | ### Discussions  
133 | - out of time - 
134 | 
135 | 
136 | ### Close  
137 | **ON Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup  
138 | **ON Hold** [PR35 - “Treasury”](https://github.com/cardano-foundation/CIPs/pull/35) (potential CIP) - no plan to merge but will reconsider   
139 | => Last Check - Merge in two weeks pending approvals: [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’)  
140 | => 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')  
141 | => Last Check - Merge in two weeks pending approvals: [PR30 - Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/pull/30) (tentative 'CIP-00xx')  
142 | => Merge **NOW**: [PR33 - HD Wallet for Cardano”](https://github.com/cardano-foundation/CIPs/pull/33) (‘CIP-1852’)  
143 | => Merge **NOW**: [PR37 - “Staking Key Chain for HD Wallets”](https://github.com/cardano-foundation/CIPs/pull/37) (‘CIP-0011’)  
144 | 
145 | ---
146 | ## Extra
147 | 
148 | ### Current CIPs in the CIP repository and their status
149 | 
150 | |#              |Title            | Status               |
151 | | ----------------- |:----------------|:-------------------- |
152 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
153 | | 2                 | [Coin Selection Algorithms for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
154 | | 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |
155 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
156 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
157 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
158 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
159 | | 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |
160 | 
161 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
162 | 
163 | 
164 | ### CIP creation process as a Sequence Diagram  
165 | _"Alice has a Cardano idea she'd like to build more formally":_
166 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
167 | 
168 | ### Understanding CIPs further
169 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
170 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
171 | 
172 | 
173 | 
174 | 
175 | 


--------------------------------------------------------------------------------
/BiweeklyMeetings/01-26-2021.md:
--------------------------------------------------------------------------------
  1 |  **Table of Contents:** 
  2 | 
  3 | - [Summary](#summary)
  4 | - [Editors Meeting Flow](#editors-meeting-flow)
  5 | - [January 26 2021 notes](#january-26-2021-notes)
  6 |   * [Triage](#triage)
  7 |   * [Last Check](#last-check)
  8 |       + [PR15 - Extended Metadata](#Extended-Metadata)
  9 |       + [PR45 - Shelley Initial Parameters](#Shelley-Initial-Parameters)
 10 |       + [PR56 - HD Stake Pool Cold Keys](#HD-Stake-Pool-Cold-Keys)
 11 |   * [Review](#review)
 12 |       + [PR58 - Catalyst Registration transaction metadata format](#Catalyst-Registration-transaction-metadata-format)
 13 |       + [PR61 - Update to CIP-0013](#Update-to-CIP-0013)
 14 |       + [PR62 - Update to CIP-0010](#Update-to-CIP-0010)
 15 |       + [PR57 - Key Serialization formats](#Key-Serialization-formats)   
 16 |   * [Discussions](#discussions)
 17 |   * [Close](#close)
 18 | - [Extra](#extra)
 19 |   * [Current CIPs in the CIP repository and their status](#current-cips-in-the-cip-repository-and-their-status)
 20 |   * [CIP creation process as a Sequence Diagram](#cip-creation-process-as-a-sequence-diagram)
 21 |   * [Understanding CIPs further](#understanding-cips-further)
 22 | ## Summary
 23 | 
 24 | 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.  
 25 | <sub>_Notes might contain errors or miss pieces - call out issues as needed_
 26 | </sub>  
 27 | 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.  
 28 | 
 29 | 
 30 | ## Editors Meeting Flow
 31 | - [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..
 32 | - [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)
 33 | - [x] **New CIPs Review**: CIPs up for review should be looked over collectively, with discussion where needed. (on top of the asynchronous reviews)  
 34 | PR -> ‘Draft’: Needs format + approval.  
 35 | ‘Draft’ -> ‘Proposed’: Needs a PLAN towards Active + implementation.  
 36 | ‘Proposed’ -> ‘Active’:  Objective criteria as laid out observed, and consensus agreeing.   
 37 | - [x] **Current Discussions**: What the current CIPs discussions are on social media / forums / Discord.
 38 | - [x] **Close**: Recap of actions taken and decisions. List the CIPs that are due for review.  Distribution of the minutes via mailing list.
 39 | 
 40 | 
 41 | ## January 26 2021 notes 
 42 | **Attending Editors**: ~Matthias~, Sebastien, Duncan, Frederic.  
 43 | 
 44 | ### Triage  
 45 | N/A
 46 | 
 47 | ### Last Check  
 48 | #### Extended Metadata  
 49 | ([PR15](https://github.com/cardano-foundation/CIPs/pull/15) - potential CIP-0006)    
 50 | **Frederic** - No update from Markus - leaving as-is, reaching out to Markus.  
 51 | => Ping @Gufmar to address final tweaks on Github. Functionally on hold. 
 52 | 
 53 | #### Cardano Parameters   
 54 | ([PR45](https://github.com/cardano-foundation/CIPs/pull/45) - potential CIP-0009)   
 55 | **Frederic** - Ready to go but missing some structure. Consensus was this is ready to be merged.   
 56 | **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.  
 57 | **Sebastien** - Ok to merge by me.  
 58 | **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.  
 59 | **F** - What about the case where a parameter change happens but this CIP does not get updated?  
 60 | **D** - Anyone would be able to come and push a PR with the appropriate change to update this.  
 61 | => **MERGING** pending internal discussion re: status.    
 62 | 
 63 | #### HD Stake Pool Cold Keys  
 64 | ([PR56](https://github.com/cardano-foundation/CIPs/pull/56) - potential CIP-1853)  
 65 | **S** - We requested changes last time.   
 66 | **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.   
 67 | **S** - Approving.   
 68 | => **MERGING** now  
 69 | 
 70 | 
 71 | 
 72 | ### Review  
 73 | 
 74 | #### Catalyst Registration transaction metadata format   
 75 | ([PR58](https://github.com/cardano-foundation/CIPs/pull/58) - potential CIP-0014)   
 76 | **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.  
 77 | **D** - Did anyone else reviewed this and double checked the description corresponds to reality?  
 78 | **S** - No. This is just documenting what the Fund2 used 'in practice'. There were some test vectors and ideas but no formal writeup.   
 79 | **D** - Can we get someone from Catalyst to review the CIP?   
 80 | **S** - I'll ping on the topic and see. I also posted it in the Catalyst Slack channel as well.  
 81 | => to Last Check (to be merged next meeting) 
 82 | 
 83 | #### Update to CIP-0013   
 84 | ([PR61](https://github.com/cardano-foundation/CIPs/pull/61) - Update to CIP-0013)   
 85 | **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.  
 86 | **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.  
 87 | **D** - Why is it that we want to custom URL schemes rather than a MIME type?  
 88 | **S** - Yoroi is a browser extension. Whenever you select such a URL it'd open Yoroi (or Deadalus) appropriately..    
 89 | **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? 
 90 | **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.  
 91 | **D** - They still encourage you to do this rather than file + MIME types?  
 92 | **S** - As far as I know. Have never seen MIME types used rather than this anywhere.   
 93 | **D** - The QR codes?   
 94 | **R** - QR codes are just enconding of URLs   
 95 | **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...  
 96 | **D** - Thanks for the digging into things.   
 97 | **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.  
 98 | **D** - One more Q: Can you use a combination of MIME/URI?  
 99 | **S** - You cannot. It's not possible.   
100 | **D** - Why do we allow pool tickers given they aren't unique rather than their IDs?  
101 | **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.  
102 | => to Last Check (to be merged next meeting) 
103 | 
104 | #### Update to CIP-0010    
105 | ([PR62](https://github.com/cardano-foundation/CIPs/pull/62) - Update to CIP-0010)    
106 | **F** - This is an update to the registry entry - not sure what this does.  
107 | **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.  
108 | **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.  
109 | **D** - Avoiding duplication typically sensible.  
110 | => Move to REVIEW for next meeting + reaching out to Author (Marek).  
111 | 
112 | #### Key Serialization formats    
113 | ([PR57](https://github.com/cardano-foundation/CIPs/pull/57) - potential CIP-xxxx)   
114 | **S** - Have not been able to review.  
115 | **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).  
116 | **S** - There is a good [Forum post](https://forum.cardano.org/t/message-signing-specification/41032/5) describing things, and it lists 4 formats.   
117 | **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.  
118 | => Move to REVIEW for next meeting.  
119 | 
120 | 
121 | 
122 | ### Discussions  
123 | **D** - [PR55](https://github.com/cardano-foundation/CIPs/pull/55) looks like it's simple / ready to go and should be merged.  
124 | **S** - Let's merge it. (=> merging)  
125 | **F** - Mentions about using Tags in the repo if anyone has preference. Also regarding publicizing those meetings.  
126 | **D** - Also let's add [PR31](https://github.com/cardano-foundation/CIPs/pull/31) to next meeting. Looks ready to be merged even.  
127 | **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?  
128 | **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.  
129 | 
130 | 
131 | ### Close  
132 | **On Hold** “Curve proposal” (‘CIP7’) still awaiting legal followup    
133 | **On Hold** [PR15 - “Extended Metadata”](https://github.com/cardano-foundation/CIPs/pull/15) (tentative ‘CIP-0006’) - expecting last tweaks.  
134 | => Merge **NOW**: [PR45 - "Initial Parameters"](https://github.com/cardano-foundation/CIPs/pull/45) ('CIP-0009')   
135 | => Merge **NOW**: [PR56 - "HD stakepool cold keys"](https://github.com/cardano-foundation/CIPs/pull/56) ('CIP-1853')  
136 | => _Last Check,_ Merge in two weeks: [PR58 - "Catalyst Registration transaction metadata format"](https://github.com/cardano-foundation/CIPs/pull/58) (tentative ‘CIP-0014’)   
137 | => _Last Check,_ Merge in two weeks: [PR61 - Update to CIP-0013, adding delegation URI scheme](https://github.com/cardano-foundation/CIPs/pull/61)
138 | 
139 | ---
140 | ## Extra
141 | 
142 | ### Current CIPs in the CIP repository and their status
143 | 
144 | |#              |Title            | Status               |
145 | | ----------------- |:----------------|:-------------------- |
146 | | 1                 | [CIP Process](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001)     | Active   |
147 | | 2                 | [Coin Selection Algorithms](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0002) | Draft   |
148 | | 3                 | [Wallet key generation](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0003)                | Draft   |
149 | | 4                 | [Wallet Checksum](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0004)                | Draft   |
150 | | 5                 | [Common Bech32 Prefixes](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005)                | Draft   |
151 | | 7                 | [Curve Pledge Benefit](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0007)                | Draft   |
152 | | 8                 | [Message Signing](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008)                | Draft   |
153 | | 9                 | [Initial Parameters](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0009)                | Draft   |
154 | | 10                 | [Transaction Metadata Label Registry](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0010)                | Draft   |
155 | | 11                 | [Staking key chain for HD wallets](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0011)                | Draft   |
156 | | 12                 | [On-chain stake pool operator to delegates communication](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0012)                | Draft   |
157 | | 13                 | [Cardano URI Scheme](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0013)                | Draft   |
158 | | 1852                 | [HD Wallets for Cardano](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1852)                | Draft   |  
159 | | 1853                 | [HD Stake Pool Cold Keys](https://github.com/cardano-foundation/CIPs/tree/master/CIP-1853)                | Draft   |  
160 | 
161 | :bulb: -  For more details about Statuses, refer to [CIP1](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001).
162 | 
163 | 
164 | ### CIP creation process as a Sequence Diagram  
165 | _"Alice has a Cardano idea she'd like to build more formally":_
166 | ![Mary interacting with community and editors for a Cardano Proposal](./sequence_diagram.png?raw=true "sequence_diagram.png")
167 | 
168 | ### Understanding CIPs further
169 | [![Cardano Improvement Proposals](https://img.youtube.com/vi/q7U10EfqXJw/0.jpg)](https://www.youtube.com/watch?v=q7U10EfqXJw)
170 | [![The Cardano Effect Ep.94](https://img.youtube.com/vi/dnw7k7VKVyo/0.jpg)](https://www.youtube.com/watch?v=dnw7k7VKVyo)
171 | 
172 | 
173 | 
174 | 
175 | 


--------------------------------------------------------------------------------