From 4d10a09eaa26bc90ecc9fae3430ec2547c6230de Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 17 Jan 2023 12:58:19 +0530 Subject: [PATCH 01/22] CIP-0013 | Adjust preamble and structure w.r.t CIP-0001 (#429) * fixed 3 broken anchors + add Categories link * update for new CIP-0001 compliance, headers, links, clarity * undoing changes that somehow snuck in from #411 * added H1 title, changed status on top level README * proofreading: markdown URL syntax corrections --- CIP-0013/README.md | 94 +++++++++++++++++++++++++++++----------------- README.md | 2 +- 2 files changed, 61 insertions(+), 35 deletions(-) diff --git a/CIP-0013/README.md b/CIP-0013/README.md index 67c92d2090..33422dd4af 100644 --- a/CIP-0013/README.md +++ b/CIP-0013/README.md @@ -1,33 +1,39 @@ --- CIP: 13 Title: Cardano URI Scheme -Authors: Sebastien Guillemot , Vicente Almonacid , Robert Phair -Comments-URI: -- https://github.com/Emurgo/EmIPs/pull/2 -- https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 -- https://github.com/cardano-foundation/CIPs/pull/25 -- https://github.com/cardano-foundation/CIPs/pull/61 -- https://github.com/cardano-foundation/CIPs/pull/86 -- https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 -Status: Draft -Type: Informational +Status: Proposed +Category: Wallets +Authors: + - Sebastien Guillemot + - Vicente Almonacid + - Robert Phair +Implementors: N/A +Discussions: + - https://github.com/Emurgo/EmIPs/pull/2 + - https://forum.cardano.org/t/cip-cardano-payment-uri-scheme/41457 + - https://github.com/cardano-foundation/CIPs/pull/25 + - https://github.com/cardano-foundation/CIPs/pull/61 + - https://github.com/cardano-foundation/CIPs/pull/86 + - https://forum.cardano.org/t/cip-stake-uri-scheme-for-pools-delegation-portfolios/40594 Created: 2020-09-22 License: CC-BY-4.0 --- -# Abstract +# CIP-0013: Cardano URI Scheme + +## Abstract This proposal describes a basic URI scheme to handle Ada transfers and links to single stake pools or weighted lists of multiple pools. -# Motivation +## Motivation: why is this CIP necessary? -#### For payment URIs: +### For payment URIs: Users who create community content often want donations as a financial incentive. However, forcing users to open their wallet and copy-paste an address lowers the amount of people likely to send tokens (especially if they have to sync their wallet first). If donating was as simple as clicking a link that opens a light wallet with pre-populated fields, users may be more willing to send tokens. URI schemes would enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. -#### For stake pool URIs: +### For stake pool URIs: Centralised sources of information have led a growing amount of stake to be disproportionately assigned to pools pushed near & beyond the saturation point. @@ -41,7 +47,7 @@ Pool links allow for interfaces to initiate delegation transactions without requ URIs for weighted stake pool lists provide alternatives to using a JSON file to implement *delegation portfolios* in a way that may better suit certain platforms, applications, or social contexts. -# Specification +## Specification The core implementation should follow the [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki) standard (with `bitcoin:` replaced with `web+cardano:`) @@ -57,13 +63,13 @@ Examples: Choose our least saturated pool ``` -## Considerations +### Considerations 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) -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. +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; see [registerProtocolHandler > Permitted schemes](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes)). The prefix `ext+` is recommended for extensions, but not mandatory (see [protocol_handlers](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)). -## ABNF Grammar (Proposal) +### ABNF Grammar (Proposal) This is an initial, simplified protocol definition for fast implementation; it only requires: @@ -90,17 +96,22 @@ poolticker = 3*5UNICODE proportion = *digit [ "." *digit ] ``` -### Payment URI queries +For grammar reference, see: + + - [Wikipedia > Augmented Backus–Naur form](https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form) + - [Unicode in ABNF](https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00) + +#### Payment URI queries The amount parameter must follow the [same rules](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki#transfer-amountsize) described in BIP-21, namely, it must be specified in decimal ADA, without commas and using the period (.) decimal separator. -### Stake pool URI queries +#### Stake pool URI queries For brevity, essential in many Internet contexts, `poolticker` must be supported here in addition to the unambiguous `poolhexid`. When there is more than one pool registered with any of the specified `poolticker` parameters (whether for pool groups which have the same ticker for all pools, or for separate pools using the same ticker), the choice to which pool(s) to finally delegate is left to the user through the wallet UI. -#### Interpretation of `proportion`: +##### Interpretation of `proportion`: * If only one stake pool is specified, any proportion is meaningless and ignored. * If all stake pools have a numerical proportion, each component of the resulting stake distribution will have the same ratio as the provided `proportion` to the sum of all the propotions. @@ -116,38 +127,53 @@ If, during a wallet or other application's development process, it is still only * any value for the first URI query argument; * any URI query argument beyond the first. -## Security Considerations +### Security Considerations 1. For payment links, we cannot prompt the user to send the funds right away as they may not be fully aware of the URI they clicked or were redirected to. Instead, it may be better to simply pre-populate fields in a transaction. 2. For either payment or staking links, we should be wary of people who disguise links as actually opening up a phishing website that LOOKS like that corresponding part of the wallet UI. 3. If wallets *create* stake pool links, the actual ada or lovelace balance should not be used literally as the `proportion` figure, to avoid revealing the identity of the wallet owner who is creating the portfolio (e.g. the proportions could be scaled to normalise the largest to `1`). -# Rationale +## Rationale: how does this CIP achieve its goals? -## Why not use Universal links, deep links and other non-protocol-based Solution +### Why not use Universal links, deep links or other non-protocol-based Solution? An alternative solution to the original problem described above is to use standard URL links in combination with a routing backend system. The routing system is used to redirect to the app's URI. The advantage of this scheme is that it allows to provide a fallback mechanism to handle the case when no application implementing the protocol is installed (for instance, by redirecting to the App Store or Google Play). This is the approach behind iOS Universal Links and Android App Links. In general, it provides a better user experience but requires a centralized system which makes it unsuitable for as a multi-app standard. -## How URI delegation portfolio links supplement use of JSON files for the same purpose +For background, see + + - [Android Developer Docs > Add intent filters for incoming links](https://developer.android.com/training/app-links/deep-linking#adding-filters) + - [Apple Developer Docs > Defining a custom URL scheme for your app](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) + - [React Native > Linking](https://reactnative.dev/docs/linking.html) + +### How URI delegation portfolio links supplement use of JSON files for the same purpose? URIs facilitate the "social element" of delegated staking and pool promotion through a socially familiar, easily accessible, and less centralised convention for sharing stake pool references and potential delegation portfolios without having to construct or host a JSON file. The processing of a JSON file delivered by a web server will depend highly on a user's platform and might not even be seen by the wallet application at all. With a properly associated `web+cardano:` protocol, developers and users have another option available in case JSON files are not delivered properly to the wallet application. -## Read More +For a CIP based on this principle, see [CIP-0017](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0017). + +## Path to Active + +### Acceptance Criteria -https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler +- [x] There exist one or more wallets supporting Payment URIs. + - [x] Yoroi +- [x] There exist one or more wallets supporting Stake Pool URIs. + - [ ] TBD -https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers +### Implementation Plan -https://developer.android.com/training/app-links/deep-linking#adding-filters +Survey contemporary wallet developers to suggest adoption of both feature sets, since they are likely to be considered separately: -https://facebook.github.io/react-native/docs/linking.html +- Payment URIs +- Stake Pool URIs -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 +This survey can be conducted and/or advocated by either (ideally both): -https://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_form +- Cardano sponsoring companies +- Community advocates -https://tools.ietf.org/html/draft-seantek-unicode-in-abnf-00 +## Copyright -https://github.com/cardano-foundation/CIPs/pull/82 +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode). diff --git a/README.md b/README.md index d26a087910..b6dfd94218 100644 --- a/README.md +++ b/README.md @@ -38,7 +38,7 @@ CIP Editors meetings are public, recorded, and [published on Youtube](https://ww | 10 | [Transaction Metadata Label Registry](./CIP-0010/) | Active | | 11 | [Staking key chain for HD wallets](./CIP-0011/) | Active | | 12 | [On-chain stake pool operator to delegates communication](./CIP-0012/) | Draft | -| 13 | [Cardano URI Scheme](./CIP-0013/) | Draft | +| 13 | [Cardano URI Scheme](./CIP-0013/) | Proposed | | 14 | [User-Facing Asset Fingerprint](./CIP-0014/) | Active | | 15 | [Catalyst Registration Transaction Metadata Format](./CIP-0015/) | Active | | 16 | [Cryptographic Key Serialisation Formats](./CIP-0016/) | Active | From 1bcc72a015227f9f66e5cfb27afa890a57fbb206 Mon Sep 17 00:00:00 2001 From: Sebastien Guillemot Date: Tue, 17 Jan 2023 16:29:49 +0900 Subject: [PATCH 02/22] CIP-0034 | Include legacy testnet (#412) * Include legacy testnet in cip34 * Add space in legacy testnet name * Fix network ID for new testnets --- CIP-0034/registry.json | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/CIP-0034/registry.json b/CIP-0034/registry.json index b7c2066c3f..e3b021d9c8 100644 --- a/CIP-0034/registry.json +++ b/CIP-0034/registry.json @@ -1,13 +1,13 @@ { "PreProduction": { "Name": "Pre-Production", - "NetworkId": 3, + "NetworkId": 0, "NetworkMagic": 1, "GenesisHash": "d4b8de7a11d929a323373cbab6c1a9bdc931beffff11db111cf9d57356ee1937" }, "Preview": { "Name": "Preview", - "NetworkId": 2, + "NetworkId": 0, "NetworkMagic": 2, "GenesisHash": "72593f260b66f26bef4fc50b38a8f24d3d3633ad2e854eaf73039eb9402706f1" }, @@ -16,5 +16,11 @@ "NetworkId": 1, "NetworkMagic": 764824073, "GenesisHash": "5f20df933584822601f9e3f8c024eb5eb252fe8cefb24d1317dc3d432e940ebb" + }, + "LegacyTestnet": { + "Name": "Legacy Testnet", + "NetworkId": 0, + "NetworkMagic": 1097911063, + "GenesisHash": "96fceff972c2c06bd3bb5243c39215333be6d56aaf4823073dca31afe5038471" } -} \ No newline at end of file +} From bc4ca00e5d6dc385c9fd46740417e0820321a13e Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 17 Jan 2023 08:31:08 +0100 Subject: [PATCH 03/22] Bump express from 4.17.1 to 4.17.3 (#416) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.17.3. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](https://github.com/expressjs/express/compare/4.17.1...4.17.3) --- updated-dependencies: - dependency-name: express dependency-type: direct:production ... Signed-off-by: dependabot[bot] Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- package-lock.json | 403 ++++++++++++++++++++++++---------------------- package.json | 2 +- 2 files changed, 211 insertions(+), 194 deletions(-) diff --git a/package-lock.json b/package-lock.json index f9b3ea2b6b..4d2a6a3965 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,7 +9,7 @@ "version": "1.0.0", "license": "ISC", "dependencies": { - "express": "^4.17.1", + "express": "^4.17.3", "gray-matter": "^4.0.2", "handlebars": "^4.7.7", "moment": "^2.29.2", @@ -18,12 +18,12 @@ } }, "node_modules/accepts": { - "version": "1.3.7", - "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.7.tgz", - "integrity": "sha512-Il80Qs2WjYlJIBNzNkK6KYqlVMTbZLXgHx2oT0pU/fjRHyEp+PEfEPY0R3WCwAGVOtauxh1hOxNgIf5bv7dQpA==", + "version": "1.3.8", + "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.8.tgz", + "integrity": "sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==", "dependencies": { - "mime-types": "~2.1.24", - "negotiator": "0.6.2" + "mime-types": "~2.1.34", + "negotiator": "0.6.3" }, "engines": { "node": ">= 0.6" @@ -67,20 +67,20 @@ "integrity": "sha1-ibTRmasr7kneFk6gK4nORi1xt2c=" }, "node_modules/body-parser": { - "version": "1.19.0", - "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.19.0.tgz", - "integrity": "sha512-dhEPs72UPbDnAQJ9ZKMNTP6ptJaionhP5cBb541nXPlW60Jepo9RV/a4fX4XWW9CuFNK22krhrj1+rgzifNCsw==", + "version": "1.19.2", + "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.19.2.tgz", + "integrity": "sha512-SAAwOxgoCKMGs9uUAUFHygfLAyaniaoun6I8mFY9pRAJL9+Kec34aU+oIjDhTycub1jozEfEwx1W1IuOYxVSFw==", "dependencies": { - "bytes": "3.1.0", + "bytes": "3.1.2", "content-type": "~1.0.4", "debug": "2.6.9", "depd": "~1.1.2", - "http-errors": "1.7.2", + "http-errors": "1.8.1", "iconv-lite": "0.4.24", "on-finished": "~2.3.0", - "qs": "6.7.0", - "raw-body": "2.4.0", - "type-is": "~1.6.17" + "qs": "6.9.7", + "raw-body": "2.4.3", + "type-is": "~1.6.18" }, "engines": { "node": ">= 0.8" @@ -96,9 +96,9 @@ } }, "node_modules/bytes": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.0.tgz", - "integrity": "sha512-zauLjrfCG+xvoyaqLoV8bLVXXNGC4JqlxFCutSDWA6fJrTo2ZuvLYTqZ7aHBLZSMOopbzwv8f+wZcVzfVTI2Dg==", + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz", + "integrity": "sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==", "engines": { "node": ">= 0.8" } @@ -140,11 +140,11 @@ "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=" }, "node_modules/content-disposition": { - "version": "0.5.3", - "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.3.tgz", - "integrity": "sha512-ExO0774ikEObIAEV9kDo50o+79VCUdEB6n6lzKgGwupcVeRlhrj3qGAfwq8G6uBJjkqLrhT0qEYFcWng8z1z0g==", + "version": "0.5.4", + "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz", + "integrity": "sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==", "dependencies": { - "safe-buffer": "5.1.2" + "safe-buffer": "5.2.1" }, "engines": { "node": ">= 0.6" @@ -159,9 +159,9 @@ } }, "node_modules/cookie": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.4.0.tgz", - "integrity": "sha512-+Hp8fLp57wnUSt0tY0tHEXh4voZRDnoIrZPqlo3DPiI4y9lwg/jqx+1Om94/W6ZaPDOUbnjOt/99w66zk+l1Xg==", + "version": "0.4.2", + "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.4.2.tgz", + "integrity": "sha512-aSWTXFzaKWkvHO1Ny/s+ePFpvKsPnjc551iI41v3ny/ow6tBG5Vd+FuqGNhh1LxOmVzOlGUriIlOaokOvhaStA==", "engines": { "node": ">= 0.6" } @@ -190,7 +190,7 @@ "node_modules/depd": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/depd/-/depd-1.1.2.tgz", - "integrity": "sha1-m81S4UwJd2PnSbJ0xDRu0uVgtak=", + "integrity": "sha512-7emPTl6Dpo6JRXOXjLRxck+FlLRX5847cLKEn00PLAgc3g2hTZZgr+e4c2v6QpSmLeFP3n5yUo7ft6avBK/5jQ==", "engines": { "node": ">= 0.6" } @@ -198,7 +198,7 @@ "node_modules/destroy": { "version": "1.0.4", "resolved": "https://registry.npmjs.org/destroy/-/destroy-1.0.4.tgz", - "integrity": "sha1-l4hXRCxEdJ5CBmE+N5RiBYJqvYA=" + "integrity": "sha512-3NdhDuEXnfun/z7x9GOElY49LoqVHoGScmOKwmxhsS8N5Y+Z8KyPPDnaSzqWgYt/ji4mqwfTS34Htrk0zPIXVg==" }, "node_modules/ee-first": { "version": "1.1.1", @@ -238,22 +238,22 @@ "node_modules/etag": { "version": "1.8.1", "resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz", - "integrity": "sha1-Qa4u62XvpiJorr/qg6x9eSmbCIc=", + "integrity": "sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==", "engines": { "node": ">= 0.6" } }, "node_modules/express": { - "version": "4.17.1", - "resolved": "https://registry.npmjs.org/express/-/express-4.17.1.tgz", - "integrity": "sha512-mHJ9O79RqluphRrcw2X/GTh3k9tVv8YcoyY4Kkh4WDMUYKRZUq0h1o0w2rrrxBqM7VoeUVqgb27xlEMXTnYt4g==", + "version": "4.17.3", + "resolved": "https://registry.npmjs.org/express/-/express-4.17.3.tgz", + "integrity": "sha512-yuSQpz5I+Ch7gFrPCk4/c+dIBKlQUxtgwqzph132bsT6qhuzss6I8cLJQz7B3rFblzd6wtcI0ZbGltH/C4LjUg==", "dependencies": { - "accepts": "~1.3.7", + "accepts": "~1.3.8", "array-flatten": "1.1.1", - "body-parser": "1.19.0", - "content-disposition": "0.5.3", + "body-parser": "1.19.2", + "content-disposition": "0.5.4", "content-type": "~1.0.4", - "cookie": "0.4.0", + "cookie": "0.4.2", "cookie-signature": "1.0.6", "debug": "2.6.9", "depd": "~1.1.2", @@ -267,13 +267,13 @@ "on-finished": "~2.3.0", "parseurl": "~1.3.3", "path-to-regexp": "0.1.7", - "proxy-addr": "~2.0.5", - "qs": "6.7.0", + "proxy-addr": "~2.0.7", + "qs": "6.9.7", "range-parser": "~1.2.1", - "safe-buffer": "5.1.2", - "send": "0.17.1", - "serve-static": "1.14.1", - "setprototypeof": "1.1.1", + "safe-buffer": "5.2.1", + "send": "0.17.2", + "serve-static": "1.14.2", + "setprototypeof": "1.2.0", "statuses": "~1.5.0", "type-is": "~1.6.18", "utils-merge": "1.0.1", @@ -323,9 +323,9 @@ } }, "node_modules/forwarded": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.1.2.tgz", - "integrity": "sha1-mMI9qxF1ZXuMBXPozszZGw/xjIQ=", + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz", + "integrity": "sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==", "engines": { "node": ">= 0.6" } @@ -333,7 +333,7 @@ "node_modules/fresh": { "version": "0.5.2", "resolved": "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz", - "integrity": "sha1-PYyt2Q2XZWn6g1qx+OSyOhBWBac=", + "integrity": "sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==", "engines": { "node": ">= 0.6" } @@ -402,15 +402,15 @@ } }, "node_modules/http-errors": { - "version": "1.7.2", - "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.7.2.tgz", - "integrity": "sha512-uUQBt3H/cSIVfch6i1EuPNy/YsRSOUBXTVfZ+yR7Zjez3qjBz6i9+i4zjNaoqcoFVI4lQJ5plg63TvGfRSDCRg==", + "version": "1.8.1", + "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.8.1.tgz", + "integrity": "sha512-Kpk9Sm7NmI+RHhnj6OIWDI1d6fIoFAtFt9RLaTMRlg/8w49juAStsrBgp0Dp4OdxdVbRIeKhtCUvoi/RuAhO4g==", "dependencies": { "depd": "~1.1.2", - "inherits": "2.0.3", - "setprototypeof": "1.1.1", + "inherits": "2.0.4", + "setprototypeof": "1.2.0", "statuses": ">= 1.5.0 < 2", - "toidentifier": "1.0.0" + "toidentifier": "1.0.1" }, "engines": { "node": ">= 0.6" @@ -437,9 +437,9 @@ } }, "node_modules/inherits": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", - "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=" + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", + "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==" }, "node_modules/ipaddr.js": { "version": "1.9.1", @@ -500,7 +500,7 @@ "node_modules/media-typer": { "version": "0.3.0", "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz", - "integrity": "sha1-hxDXrwqmJvj/+hzgAWhUUmMlV0g=", + "integrity": "sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==", "engines": { "node": ">= 0.6" } @@ -530,19 +530,19 @@ } }, "node_modules/mime-db": { - "version": "1.44.0", - "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.44.0.tgz", - "integrity": "sha512-/NOTfLrsPBVeH7YtFPgsVWveuL+4SjjYxaQ1xtM1KMFj7HdxlBlxeyNLzhyJVx7r4rZGJAZ/6lkKCitSc/Nmpg==", + "version": "1.52.0", + "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz", + "integrity": "sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==", "engines": { "node": ">= 0.6" } }, "node_modules/mime-types": { - "version": "2.1.27", - "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.27.tgz", - "integrity": "sha512-JIhqnCasI9yD+SsmkquHBxTSEuZdQX5BuQnS2Vc7puQQQ+8yiP5AY5uWhpdv4YL4VM5c6iliiYWPgJ/nJQLp7w==", + "version": "2.1.35", + "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz", + "integrity": "sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==", "dependencies": { - "mime-db": "1.44.0" + "mime-db": "1.52.0" }, "engines": { "node": ">= 0.6" @@ -578,9 +578,9 @@ "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=" }, "node_modules/negotiator": { - "version": "0.6.2", - "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.2.tgz", - "integrity": "sha512-hZXc7K2e+PgeI1eDBe/10Ard4ekbfrrqG8Ep+8Jmf4JID2bNg7NvCPOZN+kfF574pFQI7mum2AUqDidoKqcTOw==", + "version": "0.6.3", + "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.3.tgz", + "integrity": "sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==", "engines": { "node": ">= 0.6" } @@ -669,11 +669,11 @@ "integrity": "sha1-32BBeABfUi8V60SQ5yR6G/qmf4w=" }, "node_modules/proxy-addr": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.6.tgz", - "integrity": "sha512-dh/frvCBVmSsDYzw6n926jv974gddhkFPfiN8hPOi30Wax25QZyZEGveluCgliBnqmuM+UJmBErbAUFIoDbjOw==", + "version": "2.0.7", + "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz", + "integrity": "sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==", "dependencies": { - "forwarded": "~0.1.2", + "forwarded": "0.2.0", "ipaddr.js": "1.9.1" }, "engines": { @@ -681,11 +681,14 @@ } }, "node_modules/qs": { - "version": "6.7.0", - "resolved": "https://registry.npmjs.org/qs/-/qs-6.7.0.tgz", - "integrity": "sha512-VCdBRNFTX1fyE7Nb6FYoURo/SPe62QCaAyzJvUjwRaIsc+NePBEniHlvxFmmX56+HZphIGtV0XeCirBtpDrTyQ==", + "version": "6.9.7", + "resolved": "https://registry.npmjs.org/qs/-/qs-6.9.7.tgz", + "integrity": "sha512-IhMFgUmuNpyRfxA90umL7ByLlgRXu6tIfKPpF5TmcfRLlLCckfP/g3IQmju6jjpu+Hh8rA+2p6A27ZSPOOHdKw==", "engines": { "node": ">=0.6" + }, + "funding": { + "url": "https://github.com/sponsors/ljharb" } }, "node_modules/range-parser": { @@ -697,12 +700,12 @@ } }, "node_modules/raw-body": { - "version": "2.4.0", - "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.4.0.tgz", - "integrity": "sha512-4Oz8DUIwdvoa5qMJelxipzi/iJIi40O5cGV1wNYp5hvZP8ZN0T+jiNkL0QepXs+EsQ9XJ8ipEDoiH70ySUJP3Q==", + "version": "2.4.3", + "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.4.3.tgz", + "integrity": "sha512-UlTNLIcu0uzb4D2f4WltY6cVjLi+/jEN4lgEUj3E04tpMDpUlkBo/eSn6zou9hum2VMNpCCUone0O0WeJim07g==", "dependencies": { - "bytes": "3.1.0", - "http-errors": "1.7.2", + "bytes": "3.1.2", + "http-errors": "1.8.1", "iconv-lite": "0.4.24", "unpipe": "1.0.0" }, @@ -735,9 +738,23 @@ } }, "node_modules/safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==" + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", + "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==", + "funding": [ + { + "type": "github", + "url": "https://github.com/sponsors/feross" + }, + { + "type": "patreon", + "url": "https://www.patreon.com/feross" + }, + { + "type": "consulting", + "url": "https://feross.org/support" + } + ] }, "node_modules/safer-buffer": { "version": "2.1.2", @@ -757,9 +774,9 @@ } }, "node_modules/send": { - "version": "0.17.1", - "resolved": "https://registry.npmjs.org/send/-/send-0.17.1.tgz", - "integrity": "sha512-BsVKsiGcQMFwT8UxypobUKyv7irCNRHk1T0G680vk88yf6LBByGcZJOTJCrTP2xVN6yI+XjPJcNuE3V4fT9sAg==", + "version": "0.17.2", + "resolved": "https://registry.npmjs.org/send/-/send-0.17.2.tgz", + "integrity": "sha512-UJYB6wFSJE3G00nEivR5rgWp8c2xXvJ3OPWPhmuteU0IKj8nKbG3DrjiOmLwpnHGYWAVwA69zmTm++YG0Hmwww==", "dependencies": { "debug": "2.6.9", "depd": "~1.1.2", @@ -768,9 +785,9 @@ "escape-html": "~1.0.3", "etag": "~1.8.1", "fresh": "0.5.2", - "http-errors": "~1.7.2", + "http-errors": "1.8.1", "mime": "1.6.0", - "ms": "2.1.1", + "ms": "2.1.3", "on-finished": "~2.3.0", "range-parser": "~1.2.1", "statuses": "~1.5.0" @@ -780,19 +797,19 @@ } }, "node_modules/send/node_modules/ms": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.1.tgz", - "integrity": "sha512-tgp+dl5cGk28utYktBsrFqA7HKgrhgPsg6Z/EfhWI4gl1Hwq8B/GmY/0oXZ6nF8hDVesS/FpnYaD/kOWhYQvyg==" + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", + "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==" }, "node_modules/serve-static": { - "version": "1.14.1", - "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.14.1.tgz", - "integrity": "sha512-JMrvUwE54emCYWlTI+hGrGv5I8dEwmco/00EvkzIIsR7MqrHonbD9pO2MOfFnpFntl7ecpZs+3mW+XbQZu9QCg==", + "version": "1.14.2", + "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.14.2.tgz", + "integrity": "sha512-+TMNA9AFxUEGuC0z2mevogSnn9MXKb4fa7ngeRMJaaGv8vTwnIEkKi+QGvPt33HSnf8pRS+WGM0EbMtCJLKMBQ==", "dependencies": { "encodeurl": "~1.0.2", "escape-html": "~1.0.3", "parseurl": "~1.3.3", - "send": "0.17.1" + "send": "0.17.2" }, "engines": { "node": ">= 0.8.0" @@ -804,9 +821,9 @@ "integrity": "sha1-BF+XgtARrppoA93TgrJDkrPYkPc=" }, "node_modules/setprototypeof": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.1.tgz", - "integrity": "sha512-JvdAWfbXeIGaZ9cILp38HntZSFSo3mWg6xGcJJsd+d4aRMOqauag1C63dJfDw7OaMYwEbHMOxEZ1lqVRYP2OAw==" + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz", + "integrity": "sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==" }, "node_modules/showdown": { "version": "1.9.1", @@ -873,9 +890,9 @@ } }, "node_modules/toidentifier": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.0.tgz", - "integrity": "sha512-yaOH/Pk/VEhBWWTlhI+qXxDFXlejDGcQipMlyxda9nthulaxLZUNcUqFxokp0vcYnvteJln5FNQDRrxj3YcbVw==", + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz", + "integrity": "sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==", "engines": { "node": ">=0.6" } @@ -991,12 +1008,12 @@ }, "dependencies": { "accepts": { - "version": "1.3.7", - "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.7.tgz", - "integrity": "sha512-Il80Qs2WjYlJIBNzNkK6KYqlVMTbZLXgHx2oT0pU/fjRHyEp+PEfEPY0R3WCwAGVOtauxh1hOxNgIf5bv7dQpA==", + "version": "1.3.8", + "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.8.tgz", + "integrity": "sha512-PYAthTa2m2VKxuvSD3DPC/Gy+U+sOA1LAuT8mkmRuvw+NACSaeXEQ+NHcVF7rONl6qcaxV3Uuemwawk+7+SJLw==", "requires": { - "mime-types": "~2.1.24", - "negotiator": "0.6.2" + "mime-types": "~2.1.34", + "negotiator": "0.6.3" } }, "ansi-regex": { @@ -1031,20 +1048,20 @@ "integrity": "sha1-ibTRmasr7kneFk6gK4nORi1xt2c=" }, "body-parser": { - "version": "1.19.0", - "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.19.0.tgz", - "integrity": "sha512-dhEPs72UPbDnAQJ9ZKMNTP6ptJaionhP5cBb541nXPlW60Jepo9RV/a4fX4XWW9CuFNK22krhrj1+rgzifNCsw==", + "version": "1.19.2", + "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.19.2.tgz", + "integrity": "sha512-SAAwOxgoCKMGs9uUAUFHygfLAyaniaoun6I8mFY9pRAJL9+Kec34aU+oIjDhTycub1jozEfEwx1W1IuOYxVSFw==", "requires": { - "bytes": "3.1.0", + "bytes": "3.1.2", "content-type": "~1.0.4", "debug": "2.6.9", "depd": "~1.1.2", - "http-errors": "1.7.2", + "http-errors": "1.8.1", "iconv-lite": "0.4.24", "on-finished": "~2.3.0", - "qs": "6.7.0", - "raw-body": "2.4.0", - "type-is": "~1.6.17" + "qs": "6.9.7", + "raw-body": "2.4.3", + "type-is": "~1.6.18" } }, "brace-expansion": { @@ -1057,9 +1074,9 @@ } }, "bytes": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.0.tgz", - "integrity": "sha512-zauLjrfCG+xvoyaqLoV8bLVXXNGC4JqlxFCutSDWA6fJrTo2ZuvLYTqZ7aHBLZSMOopbzwv8f+wZcVzfVTI2Dg==" + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.2.tgz", + "integrity": "sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==" }, "camelcase": { "version": "5.3.1", @@ -1095,11 +1112,11 @@ "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=" }, "content-disposition": { - "version": "0.5.3", - "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.3.tgz", - "integrity": "sha512-ExO0774ikEObIAEV9kDo50o+79VCUdEB6n6lzKgGwupcVeRlhrj3qGAfwq8G6uBJjkqLrhT0qEYFcWng8z1z0g==", + "version": "0.5.4", + "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.4.tgz", + "integrity": "sha512-FveZTNuGw04cxlAiWbzi6zTAL/lhehaWbTtgluJh4/E95DqMwTmha3KZN1aAWA8cFIhHzMZUvLevkw5Rqk+tSQ==", "requires": { - "safe-buffer": "5.1.2" + "safe-buffer": "5.2.1" } }, "content-type": { @@ -1108,9 +1125,9 @@ "integrity": "sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA==" }, "cookie": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.4.0.tgz", - "integrity": "sha512-+Hp8fLp57wnUSt0tY0tHEXh4voZRDnoIrZPqlo3DPiI4y9lwg/jqx+1Om94/W6ZaPDOUbnjOt/99w66zk+l1Xg==" + "version": "0.4.2", + "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.4.2.tgz", + "integrity": "sha512-aSWTXFzaKWkvHO1Ny/s+ePFpvKsPnjc551iI41v3ny/ow6tBG5Vd+FuqGNhh1LxOmVzOlGUriIlOaokOvhaStA==" }, "cookie-signature": { "version": "1.0.6", @@ -1133,12 +1150,12 @@ "depd": { "version": "1.1.2", "resolved": "https://registry.npmjs.org/depd/-/depd-1.1.2.tgz", - "integrity": "sha1-m81S4UwJd2PnSbJ0xDRu0uVgtak=" + "integrity": "sha512-7emPTl6Dpo6JRXOXjLRxck+FlLRX5847cLKEn00PLAgc3g2hTZZgr+e4c2v6QpSmLeFP3n5yUo7ft6avBK/5jQ==" }, "destroy": { "version": "1.0.4", "resolved": "https://registry.npmjs.org/destroy/-/destroy-1.0.4.tgz", - "integrity": "sha1-l4hXRCxEdJ5CBmE+N5RiBYJqvYA=" + "integrity": "sha512-3NdhDuEXnfun/z7x9GOElY49LoqVHoGScmOKwmxhsS8N5Y+Z8KyPPDnaSzqWgYt/ji4mqwfTS34Htrk0zPIXVg==" }, "ee-first": { "version": "1.1.1", @@ -1168,19 +1185,19 @@ "etag": { "version": "1.8.1", "resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz", - "integrity": "sha1-Qa4u62XvpiJorr/qg6x9eSmbCIc=" + "integrity": "sha512-aIL5Fx7mawVa300al2BnEE4iNvo1qETxLrPI/o05L7z6go7fCw1J6EQmbK4FmJ2AS7kgVF/KEZWufBfdClMcPg==" }, "express": { - "version": "4.17.1", - "resolved": "https://registry.npmjs.org/express/-/express-4.17.1.tgz", - "integrity": "sha512-mHJ9O79RqluphRrcw2X/GTh3k9tVv8YcoyY4Kkh4WDMUYKRZUq0h1o0w2rrrxBqM7VoeUVqgb27xlEMXTnYt4g==", + "version": "4.17.3", + "resolved": "https://registry.npmjs.org/express/-/express-4.17.3.tgz", + "integrity": "sha512-yuSQpz5I+Ch7gFrPCk4/c+dIBKlQUxtgwqzph132bsT6qhuzss6I8cLJQz7B3rFblzd6wtcI0ZbGltH/C4LjUg==", "requires": { - "accepts": "~1.3.7", + "accepts": "~1.3.8", "array-flatten": "1.1.1", - "body-parser": "1.19.0", - "content-disposition": "0.5.3", + "body-parser": "1.19.2", + "content-disposition": "0.5.4", "content-type": "~1.0.4", - "cookie": "0.4.0", + "cookie": "0.4.2", "cookie-signature": "1.0.6", "debug": "2.6.9", "depd": "~1.1.2", @@ -1194,13 +1211,13 @@ "on-finished": "~2.3.0", "parseurl": "~1.3.3", "path-to-regexp": "0.1.7", - "proxy-addr": "~2.0.5", - "qs": "6.7.0", + "proxy-addr": "~2.0.7", + "qs": "6.9.7", "range-parser": "~1.2.1", - "safe-buffer": "5.1.2", - "send": "0.17.1", - "serve-static": "1.14.1", - "setprototypeof": "1.1.1", + "safe-buffer": "5.2.1", + "send": "0.17.2", + "serve-static": "1.14.2", + "setprototypeof": "1.2.0", "statuses": "~1.5.0", "type-is": "~1.6.18", "utils-merge": "1.0.1", @@ -1238,14 +1255,14 @@ } }, "forwarded": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.1.2.tgz", - "integrity": "sha1-mMI9qxF1ZXuMBXPozszZGw/xjIQ=" + "version": "0.2.0", + "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.2.0.tgz", + "integrity": "sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow==" }, "fresh": { "version": "0.5.2", "resolved": "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz", - "integrity": "sha1-PYyt2Q2XZWn6g1qx+OSyOhBWBac=" + "integrity": "sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==" }, "fs.realpath": { "version": "1.0.0", @@ -1294,15 +1311,15 @@ } }, "http-errors": { - "version": "1.7.2", - "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.7.2.tgz", - "integrity": "sha512-uUQBt3H/cSIVfch6i1EuPNy/YsRSOUBXTVfZ+yR7Zjez3qjBz6i9+i4zjNaoqcoFVI4lQJ5plg63TvGfRSDCRg==", + "version": "1.8.1", + "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.8.1.tgz", + "integrity": "sha512-Kpk9Sm7NmI+RHhnj6OIWDI1d6fIoFAtFt9RLaTMRlg/8w49juAStsrBgp0Dp4OdxdVbRIeKhtCUvoi/RuAhO4g==", "requires": { "depd": "~1.1.2", - "inherits": "2.0.3", - "setprototypeof": "1.1.1", + "inherits": "2.0.4", + "setprototypeof": "1.2.0", "statuses": ">= 1.5.0 < 2", - "toidentifier": "1.0.0" + "toidentifier": "1.0.1" } }, "iconv-lite": { @@ -1323,9 +1340,9 @@ } }, "inherits": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", - "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=" + "version": "2.0.4", + "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", + "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==" }, "ipaddr.js": { "version": "1.9.1", @@ -1368,7 +1385,7 @@ "media-typer": { "version": "0.3.0", "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz", - "integrity": "sha1-hxDXrwqmJvj/+hzgAWhUUmMlV0g=" + "integrity": "sha512-dq+qelQ9akHpcOl/gUVRTxVIOkAJ1wR3QAvb4RsVjS8oVoFjDGTc679wJYmUmknUF5HwMLOgb5O+a3KxfWapPQ==" }, "merge-descriptors": { "version": "1.0.1", @@ -1386,16 +1403,16 @@ "integrity": "sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==" }, "mime-db": { - "version": "1.44.0", - "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.44.0.tgz", - "integrity": "sha512-/NOTfLrsPBVeH7YtFPgsVWveuL+4SjjYxaQ1xtM1KMFj7HdxlBlxeyNLzhyJVx7r4rZGJAZ/6lkKCitSc/Nmpg==" + "version": "1.52.0", + "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.52.0.tgz", + "integrity": "sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==" }, "mime-types": { - "version": "2.1.27", - "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.27.tgz", - "integrity": "sha512-JIhqnCasI9yD+SsmkquHBxTSEuZdQX5BuQnS2Vc7puQQQ+8yiP5AY5uWhpdv4YL4VM5c6iliiYWPgJ/nJQLp7w==", + "version": "2.1.35", + "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.35.tgz", + "integrity": "sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==", "requires": { - "mime-db": "1.44.0" + "mime-db": "1.52.0" } }, "minimatch": { @@ -1422,9 +1439,9 @@ "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=" }, "negotiator": { - "version": "0.6.2", - "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.2.tgz", - "integrity": "sha512-hZXc7K2e+PgeI1eDBe/10Ard4ekbfrrqG8Ep+8Jmf4JID2bNg7NvCPOZN+kfF574pFQI7mum2AUqDidoKqcTOw==" + "version": "0.6.3", + "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.3.tgz", + "integrity": "sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==" }, "neo-async": { "version": "2.6.2", @@ -1489,18 +1506,18 @@ "integrity": "sha1-32BBeABfUi8V60SQ5yR6G/qmf4w=" }, "proxy-addr": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.6.tgz", - "integrity": "sha512-dh/frvCBVmSsDYzw6n926jv974gddhkFPfiN8hPOi30Wax25QZyZEGveluCgliBnqmuM+UJmBErbAUFIoDbjOw==", + "version": "2.0.7", + "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz", + "integrity": "sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==", "requires": { - "forwarded": "~0.1.2", + "forwarded": "0.2.0", "ipaddr.js": "1.9.1" } }, "qs": { - "version": "6.7.0", - "resolved": "https://registry.npmjs.org/qs/-/qs-6.7.0.tgz", - "integrity": "sha512-VCdBRNFTX1fyE7Nb6FYoURo/SPe62QCaAyzJvUjwRaIsc+NePBEniHlvxFmmX56+HZphIGtV0XeCirBtpDrTyQ==" + "version": "6.9.7", + "resolved": "https://registry.npmjs.org/qs/-/qs-6.9.7.tgz", + "integrity": "sha512-IhMFgUmuNpyRfxA90umL7ByLlgRXu6tIfKPpF5TmcfRLlLCckfP/g3IQmju6jjpu+Hh8rA+2p6A27ZSPOOHdKw==" }, "range-parser": { "version": "1.2.1", @@ -1508,12 +1525,12 @@ "integrity": "sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==" }, "raw-body": { - "version": "2.4.0", - "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.4.0.tgz", - "integrity": "sha512-4Oz8DUIwdvoa5qMJelxipzi/iJIi40O5cGV1wNYp5hvZP8ZN0T+jiNkL0QepXs+EsQ9XJ8ipEDoiH70ySUJP3Q==", + "version": "2.4.3", + "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.4.3.tgz", + "integrity": "sha512-UlTNLIcu0uzb4D2f4WltY6cVjLi+/jEN4lgEUj3E04tpMDpUlkBo/eSn6zou9hum2VMNpCCUone0O0WeJim07g==", "requires": { - "bytes": "3.1.0", - "http-errors": "1.7.2", + "bytes": "3.1.2", + "http-errors": "1.8.1", "iconv-lite": "0.4.24", "unpipe": "1.0.0" } @@ -1537,9 +1554,9 @@ } }, "safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==" + "version": "5.2.1", + "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", + "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==" }, "safer-buffer": { "version": "2.1.2", @@ -1556,9 +1573,9 @@ } }, "send": { - "version": "0.17.1", - "resolved": "https://registry.npmjs.org/send/-/send-0.17.1.tgz", - "integrity": "sha512-BsVKsiGcQMFwT8UxypobUKyv7irCNRHk1T0G680vk88yf6LBByGcZJOTJCrTP2xVN6yI+XjPJcNuE3V4fT9sAg==", + "version": "0.17.2", + "resolved": "https://registry.npmjs.org/send/-/send-0.17.2.tgz", + "integrity": "sha512-UJYB6wFSJE3G00nEivR5rgWp8c2xXvJ3OPWPhmuteU0IKj8nKbG3DrjiOmLwpnHGYWAVwA69zmTm++YG0Hmwww==", "requires": { "debug": "2.6.9", "depd": "~1.1.2", @@ -1567,30 +1584,30 @@ "escape-html": "~1.0.3", "etag": "~1.8.1", "fresh": "0.5.2", - "http-errors": "~1.7.2", + "http-errors": "1.8.1", "mime": "1.6.0", - "ms": "2.1.1", + "ms": "2.1.3", "on-finished": "~2.3.0", "range-parser": "~1.2.1", "statuses": "~1.5.0" }, "dependencies": { "ms": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.1.tgz", - "integrity": "sha512-tgp+dl5cGk28utYktBsrFqA7HKgrhgPsg6Z/EfhWI4gl1Hwq8B/GmY/0oXZ6nF8hDVesS/FpnYaD/kOWhYQvyg==" + "version": "2.1.3", + "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", + "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==" } } }, "serve-static": { - "version": "1.14.1", - "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.14.1.tgz", - "integrity": "sha512-JMrvUwE54emCYWlTI+hGrGv5I8dEwmco/00EvkzIIsR7MqrHonbD9pO2MOfFnpFntl7ecpZs+3mW+XbQZu9QCg==", + "version": "1.14.2", + "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.14.2.tgz", + "integrity": "sha512-+TMNA9AFxUEGuC0z2mevogSnn9MXKb4fa7ngeRMJaaGv8vTwnIEkKi+QGvPt33HSnf8pRS+WGM0EbMtCJLKMBQ==", "requires": { "encodeurl": "~1.0.2", "escape-html": "~1.0.3", "parseurl": "~1.3.3", - "send": "0.17.1" + "send": "0.17.2" } }, "set-blocking": { @@ -1599,9 +1616,9 @@ "integrity": "sha1-BF+XgtARrppoA93TgrJDkrPYkPc=" }, "setprototypeof": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.1.tgz", - "integrity": "sha512-JvdAWfbXeIGaZ9cILp38HntZSFSo3mWg6xGcJJsd+d4aRMOqauag1C63dJfDw7OaMYwEbHMOxEZ1lqVRYP2OAw==" + "version": "1.2.0", + "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.2.0.tgz", + "integrity": "sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==" }, "showdown": { "version": "1.9.1", @@ -1650,9 +1667,9 @@ "integrity": "sha1-5SEekiQ2n7uB1jOi8ABE3IztrZI=" }, "toidentifier": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.0.tgz", - "integrity": "sha512-yaOH/Pk/VEhBWWTlhI+qXxDFXlejDGcQipMlyxda9nthulaxLZUNcUqFxokp0vcYnvteJln5FNQDRrxj3YcbVw==" + "version": "1.0.1", + "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.1.tgz", + "integrity": "sha512-o5sSPKEkg/DIQNmH43V0/uerLrpzVedkUh8tGNvaeXpfpuwjKenlSox/2O/BTlZUtEe+JG7s5YhEz608PlAHRA==" }, "type-is": { "version": "1.6.18", diff --git a/package.json b/package.json index ef103be92b..b2a84eb30d 100644 --- a/package.json +++ b/package.json @@ -11,7 +11,7 @@ "author": "", "license": "ISC", "dependencies": { - "express": "^4.17.1", + "express": "^4.17.3", "gray-matter": "^4.0.2", "handlebars": "^4.7.7", "moment": "^2.29.2", From 0ea15fc09d3c664ecf1826505eb21f544f2d3c5a Mon Sep 17 00:00:00 2001 From: Aaron Dunnington Date: Mon, 16 Jan 2023 23:45:38 -0800 Subject: [PATCH 04/22] [paradiso.app] remove transaction metadatum labels (#405) --- CIP-0010/registry.json | 8 -------- 1 file changed, 8 deletions(-) diff --git a/CIP-0010/registry.json b/CIP-0010/registry.json index 593d3be111..ac7ecf7c58 100644 --- a/CIP-0010/registry.json +++ b/CIP-0010/registry.json @@ -31,14 +31,6 @@ "transaction_metadatum_label": 888, "description": "finitum.io token bridge transactions metadata" }, - { - "transaction_metadatum_label": 1188, - "description": "paradiso.app marketplace metadata" - }, - { - "transaction_metadatum_label": 1189, - "description": "paradiso.app services metadata" - }, { "transaction_metadatum_label": 1564, "description": "Marlowe - a DSL for writing and executing financial contracts" From a2e1ca877e2cb2a83eea3acc8a112bc3bc85cc00 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 17 Jan 2023 09:11:36 +0100 Subject: [PATCH 05/22] Bump moment from 2.29.2 to 2.29.4 (#432) Bumps [moment](https://github.com/moment/moment) from 2.29.2 to 2.29.4. - [Release notes](https://github.com/moment/moment/releases) - [Changelog](https://github.com/moment/moment/blob/develop/CHANGELOG.md) - [Commits](https://github.com/moment/moment/compare/2.29.2...2.29.4) --- updated-dependencies: - dependency-name: moment dependency-type: direct:production ... Signed-off-by: dependabot[bot] Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- package-lock.json | 14 +++++++------- package.json | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/package-lock.json b/package-lock.json index 4d2a6a3965..ed6a284929 100644 --- a/package-lock.json +++ b/package-lock.json @@ -12,7 +12,7 @@ "express": "^4.17.3", "gray-matter": "^4.0.2", "handlebars": "^4.7.7", - "moment": "^2.29.2", + "moment": "^2.29.4", "rimraf": "^3.0.2", "showdown": "^1.9.1" } @@ -565,9 +565,9 @@ "integrity": "sha512-Jsjnk4bw3YJqYzbdyBiNsPWHPfO++UGG749Cxs6peCu5Xg4nrena6OVxOYxrQTqww0Jmwt+Ref8rggumkTLz9Q==" }, "node_modules/moment": { - "version": "2.29.2", - "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.2.tgz", - "integrity": "sha512-UgzG4rvxYpN15jgCmVJwac49h9ly9NurikMWGPdVxm8GZD6XjkKPxDTjQQ43gtGgnV3X0cAyWDdP2Wexoquifg==", + "version": "2.29.4", + "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.4.tgz", + "integrity": "sha512-5LC9SOxjSc2HF6vO2CyuTDNivEdoz2IvyJJGj6X8DJ0eFyfszE0QiEd+iXmBvUP3WHxSjFH/vIsA0EN00cgr8w==", "engines": { "node": "*" } @@ -1429,9 +1429,9 @@ "integrity": "sha512-Jsjnk4bw3YJqYzbdyBiNsPWHPfO++UGG749Cxs6peCu5Xg4nrena6OVxOYxrQTqww0Jmwt+Ref8rggumkTLz9Q==" }, "moment": { - "version": "2.29.2", - "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.2.tgz", - "integrity": "sha512-UgzG4rvxYpN15jgCmVJwac49h9ly9NurikMWGPdVxm8GZD6XjkKPxDTjQQ43gtGgnV3X0cAyWDdP2Wexoquifg==" + "version": "2.29.4", + "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.4.tgz", + "integrity": "sha512-5LC9SOxjSc2HF6vO2CyuTDNivEdoz2IvyJJGj6X8DJ0eFyfszE0QiEd+iXmBvUP3WHxSjFH/vIsA0EN00cgr8w==" }, "ms": { "version": "2.0.0", diff --git a/package.json b/package.json index b2a84eb30d..acac1b2dc5 100644 --- a/package.json +++ b/package.json @@ -14,7 +14,7 @@ "express": "^4.17.3", "gray-matter": "^4.0.2", "handlebars": "^4.7.7", - "moment": "^2.29.2", + "moment": "^2.29.4", "rimraf": "^3.0.2", "showdown": "^1.9.1" } From 90f4ce284c5ff7c0def1678ae5e6bc6754c4f17a Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 17 Jan 2023 09:11:52 +0100 Subject: [PATCH 06/22] Bump minimatch from 3.0.4 to 3.1.2 (#431) Bumps [minimatch](https://github.com/isaacs/minimatch) from 3.0.4 to 3.1.2. - [Release notes](https://github.com/isaacs/minimatch/releases) - [Changelog](https://github.com/isaacs/minimatch/blob/main/changelog.md) - [Commits](https://github.com/isaacs/minimatch/compare/v3.0.4...v3.1.2) --- updated-dependencies: - dependency-name: minimatch dependency-type: indirect ... Signed-off-by: dependabot[bot] Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- package-lock.json | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/package-lock.json b/package-lock.json index ed6a284929..277ce56ad2 100644 --- a/package-lock.json +++ b/package-lock.json @@ -549,9 +549,9 @@ } }, "node_modules/minimatch": { - "version": "3.0.4", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz", - "integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==", + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", "dependencies": { "brace-expansion": "^1.1.7" }, @@ -1416,9 +1416,9 @@ } }, "minimatch": { - "version": "3.0.4", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz", - "integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==", + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.1.2.tgz", + "integrity": "sha512-J7p63hRiAjw1NDEww1W7i37+ByIrOWO5XQQAzZ3VOcL0PNybwpfmV/N05zFAzwQ9USyEcX6t3UO+K5aqBQOIHw==", "requires": { "brace-expansion": "^1.1.7" } From 8939f040ce3064326873e473824f44f21ba1dfa4 Mon Sep 17 00:00:00 2001 From: lnmg <101827074+lnmg@users.noreply.github.com> Date: Tue, 17 Jan 2023 06:11:23 -0300 Subject: [PATCH 07/22] update signatures schema on cip-0026 (#424) --- CIP-0026/schema.json | 47 ++++++++++++++++++++++++-------------------- 1 file changed, 26 insertions(+), 21 deletions(-) diff --git a/CIP-0026/schema.json b/CIP-0026/schema.json index 176bc16c79..fbc4217541 100644 --- a/CIP-0026/schema.json +++ b/CIP-0026/schema.json @@ -92,28 +92,33 @@ , "minimum": 0 } , "signatures": - { "type": "object" - , "additionalProperties": false - , "required": - [ "publicKey" - , "signature" - ] - , "properties": - { "publicKey": - { "type": "string" - , "description": "An Ed25519 Public key, verifying the companion signature." - , "encoding": "base16" - , "minLength": 64 - , "maxLength": 64 - } - , "signature": - { "type": "string" - , "description": "A signed attestation." - , "encoding": "base16" - , "minLength": 128 - , "maxLength": 128 + { "type": "array" + , "items": + { "type": "object" + , "additionalProperties": false + , "required": + [ "publicKey" + , "signature" + ] + , "properties": + { "publicKey": + { "type": "string" + , "description": "An Ed25519 Public key, verifying the companion signature." + , "encoding": "base16" + , "minLength": 64 + , "maxLength": 64 + } + , "signature": + { "type": "string" + , "description": "A signed attestation." + , "encoding": "base16" + , "minLength": 128 + , "maxLength": 128 + } } - } + } } } } + + From 0931388e7f428026753cc8d0567e54040208a9f6 Mon Sep 17 00:00:00 2001 From: Ryan Williams <44342099+Ryun1@users.noreply.github.com> Date: Tue, 17 Jan 2023 09:12:13 +0000 Subject: [PATCH 08/22] Corrected CDDL and fixed test vectors (#426) --- CIP-0036/schema.cddl | 2 +- CIP-0036/test-vector.md | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/CIP-0036/schema.cddl b/CIP-0036/schema.cddl index 6f18b0e6a2..1f0bf2c975 100644 --- a/CIP-0036/schema.cddl +++ b/CIP-0036/schema.cddl @@ -9,7 +9,7 @@ $nonce /= uint $weight /= uint .size 4 $voting_purpose /= uint legacy_key_registration = $voting_pub_key -delegation = ($voting_pub_key, $weight) +delegation = [$voting_pub_key, $weight] ; May support other stake credentials in the future. ; Such additional credentials should be tagged at the CDDL/CBOR level diff --git a/CIP-0036/test-vector.md b/CIP-0036/test-vector.md index 66b5eaf9f1..add73c5475 100644 --- a/CIP-0036/test-vector.md +++ b/CIP-0036/test-vector.md @@ -1,4 +1,4 @@ -# Test vector for CIP15 +# Test vector for CIP36 ### Inputs @@ -56,7 +56,7 @@ Metadata (CBOR encoding) Legacy: ``` -a119ef64a4015820a6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d166302582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2 +a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2 ``` New: @@ -68,7 +68,7 @@ Blake2b-256 hash of metadata Legacy: ``` -872bcb4a9e2b110a06fd5de04be5924b6c659c28a1665ecc75def13ebca6dfd8 +a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f ``` New: @@ -83,12 +83,12 @@ Legacy: { 61284: { 1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', - 2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef', + 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', 4: 1234, }, 61285: { - 1: '0xcf8e34db193edc930faf64626a0a759dd9ce654874d4b6f255dc2aa8f52313b6dbb9aa1b162b43ed8946668edca920dd34f5a51a14130814fdc86adb6218b501' + 1: '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e' } } ``` @@ -98,7 +98,7 @@ New: { 61284: { 1: [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]], - 2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef', + 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', 4: 1234, 5: 0 From f67ad557336c7f4304102732deee2a175c677cf5 Mon Sep 17 00:00:00 2001 From: Robert Phair Date: Tue, 17 Jan 2023 14:56:56 +0530 Subject: [PATCH 09/22] fixed 3 broken anchors + add Categories link (#411) --- CIP-0001/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CIP-0001/README.md b/CIP-0001/README.md index 19dcc18bfa..1c7025b1fb 100644 --- a/CIP-0001/README.md +++ b/CIP-0001/README.md @@ -46,9 +46,9 @@ The CIP process does not _by itself_ offer any form of governance. For example, - [Repository Organization](#repository-organization) - [Licensing](#licensing) - [Statuses](#statuses) - - [Status: Proposed](#statuses-proposed) - - [Status: Active](#statuses-active) - - [Status: Inactive](#statuses-inactive) + - [Status: Proposed](#status-proposed) + - [Status: Active](#status-active) + - [Status: Inactive](#status-inactive) - [Categories](#categories) - [Project Enlisting](#project-enlisting) - [Process](#process) @@ -92,7 +92,7 @@ Field | Description `CIP` | The CIP number (without leading 0), or "\?" before being assigned `Title` | A succinct and descriptive title `Status` | Proposed \| Active \| Inactive (.._reason_..) -`Category` | One of the registered categories covering one area of the ecosystem. +`Category` | One of the registered [categories](#categories) covering one area of the ecosystem. `Authors` | A list of authors' real names and email addresses (e.g. John Doe ) `Implementors` | A list of implementors committed to delivering an implementation of the proposal, when applicable. `N/A` when not applicable and `[]` when there's currently no implementor. `Discussions` | A list of links where major technical discussions regarding this CIP happened. Links should include any discussion before submission, and _must_ include a link to the pull request that created the CIP and any pull request that modifies it. From b225b26d4d71523055bbb4944b1976797206f408 Mon Sep 17 00:00:00 2001 From: Ryan Williams <44342099+Ryun1@users.noreply.github.com> Date: Tue, 17 Jan 2023 09:55:05 +0000 Subject: [PATCH 10/22] CIP-0005, CIP-0036 | Added clarity to voting key definitions (#427) * added cip-36 style vote key bech32 prefixes to cip-05 * Clarified CIP-36 style voting keys * Added preference for the term vote keys in implmentations * Aligned with gitmachtl's suggestions --- CIP-0005/README.md | 2 ++ CIP-0036/README.md | 31 ++++++++++++++++++++++++++++++- 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/CIP-0005/README.md b/CIP-0005/README.md index 79b07dc172..9e466dc7c7 100644 --- a/CIP-0005/README.md +++ b/CIP-0005/README.md @@ -45,6 +45,8 @@ We define the following set of common prefixes with their corresponding semantic | `addr_shared_xvk` | CIP-1854's address extended verification key | Ed25519 public key with chain code | | `gov_sk` | Governance vote signing key | Ed25519 private key | | `gov_vk` | Governance vote verification key | Ed25519 public key | +| `cvote_sk` | CIP-36's vote signing key | Ed25519 private key | +| `cvote_vk` | CIP-36's vote verification key | Ed25519 public key | | `kes_sk` | KES signing key | KES signing key | | `kes_vk` | KES verification key | KES verification key | | `policy_sk` | CIP-1855's policy private key | Ed25519 private key | diff --git a/CIP-0036/README.md b/CIP-0036/README.md index 831aaddd8d..292d2a67ac 100644 --- a/CIP-0036/README.md +++ b/CIP-0036/README.md @@ -55,12 +55,41 @@ Each delegation therefore contains: - a voting key: simply an ED25519 public key. This is the spending credential in the sidechain that will receive voting power from this delegation. For direct voting it's necessary to have the corresponding private key to cast votes in the sidechain. How this key is created is up to the wallet. - the weight that is associated with this key: this is a 4-byte unsigned integer (CBOR major type 0, The weight may range from 0 to 2^32-1) that represents the relative weight of this delegation over the total weight of all delegations in the same registration transaction. -### Voting key derivation path +### Voting key + +The terms "(CIP-36) voting keys" and "(CIP-36) vote keys" should be used interchangeably to indicate the keys described in this specification. But it should be made clear that implementations should favour the term "(CIP-36) vote" and that the association of both terms aims to reduce the possibility of confusion. + +The term governance should not be associated with these keys nor should these keys be associated with other vote or voting keys used in the ecosystem. When discussing these keys in a wider context they should be specified by such terminology as "CIP-36 vote keys" or "CIP-36 style vote keys". + +#### Derivation path To avoid linking voting keys directly with Cardano spending keys, the voting key derivation path must start with a specific segment: `m / 1694' / 1815' / account' / chain / address_index` +We recommend that implementors only use `address_index`=0 to avoid the need for voting key discovery. + +#### Tooling + +Supporting tooling should clearly define and differentiate this as a unique key type, describing such keys as "CIP-36 vote keys". When utilizing Bech32 encoding the appropriate `cvote_sk` and `cvote_vk` prefixes should be used as described in [CIP-05](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0005) + +Examples of acceptable `keyType`s for supporting tools: + +| `keyType` | Description | +| --------- | ----------- | +| `CIP36VoteSigningKey_ed25519` | Catalyst Vote Signing Key | +| `CIP36VoteExtendedSigningKey_ed25519` | Catalyst Vote Signing Key | +| `CIP36VoteVerificationKey_ed25519` | Catalyst Vote Verification Key | +| `CIP36VoteExtendedVerificationKey_ed25519` | Catalyst Vote Verification Key | + +For hardware implementations: +| `keyType` | Description | +| --------- | ----------- | +| `CIP36VoteVerificationKey_ed25519` | Hardware Catalyst Vote Verification Key | +| `CIP36VoteHWSigningFile_ed25519` | Hardware Catalyst Vote Signing File | + +The intention with this design is that if projects beyond Catalyst implement this specification they are able to add to themselves `keyType` **Description**s. + ### Associating voting power with a voting key This method has been used since Fund 2. From c854763d1be927adc0e70d41b53f6053bd74b8ae Mon Sep 17 00:00:00 2001 From: simonjohnthompson Date: Tue, 17 Jan 2023 10:00:11 +0000 Subject: [PATCH 11/22] CIP-0052 | Add public keys to auditor table (#406) * CIP52: added auditor public key info to auditor table (section 3). * added MLabs public key Co-authored-by: Robert Phair --- CIP-0052/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/CIP-0052/README.md b/CIP-0052/README.md index 279a60a97d..57a7feef26 100644 --- a/CIP-0052/README.md +++ b/CIP-0052/README.md @@ -216,13 +216,13 @@ DApps are used by *DApp users*, and built by *DApp developers*. Audit is perform ### 3. Cardano auditors -| Audit company | URL | Contact email | -| ----------- | ----------- | ----------- | -| FYEO Inc. | https://gofyeo.com/blockchain-security | sales@gofyeo.com | -| Hachi | https://hachi.one | team@hachi.one | -| MLabs | https://mlabs.city | info@mlabs.city | -| Runtime Verification | https://www.runtimeverification.com | contact@runtimeverification.com | -| Tweag | https://www.tweag.io | sales@tweag.io | +| Audit company | URL | Contact email | Public key | +| ----------- | ----------- | ----------- | ----------- | +| FYEO Inc. | https://gofyeo.com/blockchain-security | sales@gofyeo.com | | +| Hachi | https://hachi.one | team@hachi.one | | +| MLabs | https://mlabs.city | info@mlabs.city | 64BC640B5454215D12165EEAEEFF303D2643ABA2 (PGP, ed25519) | +| Runtime Verification | https://www.runtimeverification.com | contact@runtimeverification.com | | +| Tweag | https://www.tweag.io | sales@tweag.io | | ### 4. A sample audit report From 47ab2685352fd936df56a4bcb22188554ab91f2f Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Tue, 17 Jan 2023 10:07:57 +0000 Subject: [PATCH 12/22] CIP-0035 | Redraft to handle Plutus Core language versions (#428) * Redraft to handle Plutus Core language versions - Include discussion of Plutus Core language versions and how they change. - Use "ledger language" instead of "language version" or "ledger language version" to avoid confusion. - Remove the reference to the 'Draft' status. - Minor prose improvements. * Address Kenneth's comments --- CIP-0035/README.md | 145 +++++++++++++++++++++++++++------------------ 1 file changed, 87 insertions(+), 58 deletions(-) diff --git a/CIP-0035/README.md b/CIP-0035/README.md index f7c99b6521..cc7234a4b7 100644 --- a/CIP-0035/README.md +++ b/CIP-0035/README.md @@ -27,7 +27,6 @@ The Plutus Core language, its builtins, and its interface to the ledger are all - We may wish to remove elements which have been deprecated due to the addition of improved versions. - … and more -At the moment there is no process for making such changes other than the discretion of the core developers. This CIP gives a taxonomy of changes, explains how such changes might be implemented in Cardano, and prescribes processes for proposing such changes. ## Background @@ -36,11 +35,13 @@ This CIP assumes general familiarity with Plutus Core and the Cardano ledger, bu ### Plutus Core -_Plutus Core_ is a script language used in the Cardano ledger. For the purposes of this document, Plutus Core consists of various _language constructs_, and also _builtin types and functions_. +_Plutus Core_ is a script language used in the Cardano ledger. +For the purposes of this document, Plutus Core consists of various _language constructs_, and also _builtin types and functions_. Plutus Core has a number of builtin types, such as integers, and builtin functions, such as integer addition. -Builtin functions provide access to functionality that would be difficult or expensive to implement in Plutus Core code. -Builtin functions can operate only over builtin types. Builtin types come with a _size metric_ which is used by costing functions. +Builtin functions provide access to functionality that would be difficult or expensive to implement using the basic constructs of Plutus Core, which is otherwise little more than the untyped lambda calculus. +Builtin functions can operate only over builtin types or arbitrary Plutus Core terms treated opaquely. + * [ ] Builtin types come with a _size metric_ which is used by costing functions. For example, the size metric for integers returns the bit-size of the integer. The performance of Plutus Core scripts has two components: how expensive the script actually is to run (_real performance_) and how expensive we say it is to run in the ledger (_model performance_). @@ -52,31 +53,61 @@ For example, the costing function for addition says that the CPU and memory cost Determining costing functions is done empirically, by running the function in question against a large number of inputs and choosing a costing function that fits the data well. +Plutus Core has a _language version_ (LV). +This is the version of the Plutus Core programming language itself, and it controls e.g. which constructs are available in the language. +Changing any of the features which are guarded by the language version requires a new language version to be supported by the chain. +Note that changing the set of builtin types or functions does _not_ require a new language version; any individual Plutus Core language version is compatible with any set of builtin types and functions. + +Depending on the type of change, a major or minor bump to the language version may be required. +The following table shows typical examples. + +| Change | Type | Notes | +|-------------------------------------------------------|-------|---------------------------| +| Adding a construct to the language | Minor | Backwards-compatible. | +| Removing a construct from the language | Major | Not backwards-compatible. | +| Changing the behaviour of a construct in the language | Major | Not backwards-compatible. | +| Changing the binary format of the language in a backwards-compatible way | Minor | Safe even if it makes previously non-deserializable scripts deserializable.[^backwards-safe] | +| Changing the binary format of the language | Major | Not backwards-compatible. | + +[^backwards-safe]: See "Are backwards-compatible binary format changes really safe?". + +Since we always need a new Plutus Core langauge version for any change to the language, in the rest of this document we will focus on the introduction of a new langauge version as the proxy for changes to the language. + ### Scripts in the Cardano ledger -The Cardano ledger recognizes various kinds of _scripts_ identified by _language_. -This language tag is the only way that the ledger has to distinguish between different types of script. +The Cardano ledger recognizes various kinds of _scripts_ identified by _language_. +This language tag is the only way that the ledger has to distinguish between different types of script. Hence if we require different behaviour, we need a new language. - -We omit this distinction when talking about Plutus Core: we refer instead to Plutus Core _language versions_, which are actually entirely distinct _languages_ from the perspective of the ledger. -All Plutus Core language versions which are used in the ledger must be supported forever, in order to be able to validate the history of the chain. +We refer to these languages as _ledger languages_ (LLs). Part of the specification of a language in the ledger is how scripts of that language are run, what arguments they are passed, how those arguments are structured, etc. We refer to this as the _ledger-script interface_. -Languages also have an associated subset of _protocol parameters_ which provide the ability to control some aspects of evaluation without a software update. +Because we want to occasionally change e.g. the ledger-script interface for Plutus Core scripts, this means we need several ledger languages which all run scripts written in Plutus Core.[^ledger-language-versions] +All Plutus Core ledger languages which are used in the ledger must be supported forever, in order to be able to validate the history of the chain. + +[^ledger-language-versions]: The Plutus Core family of ledger languages are sometimes referred to as the Plutus Core _ledger language versions_, and named as such ("PlutusV1", "PlutusV2" etc.) although they actually entirely distinct _languages_ from the perspective of the ledger. In this document we will use the more precise language and refer to them just as distinct ledger languages. + +Ledger languages also have an associated subset of the _protocol parameters_. +These parameters provide the ability to control some aspects of evaluation without a software update. The most notable example is a set of parameters which parameterize the costing of program execution. +Hence, a different Plutus Core ledger language can have a different set of costing protocol parameters. + +We can change the behaviour of ledger languages in a backwards compatible way with new protocol versions. +This ensures that the new behaviour only becomes available at a particular time in the history of the chain. + +Overall the combination of ledger language and protocol version controls: +- The protocol parameters which are available +- The ledger-script interface +- The Plutus Core language versions that are available +- The set of builtin types and values that are available ### Types of change This document considers the following types of change: 1. The Plutus Core language - 1. Adding a construct to the language - 2. Removing a construct from the language - 3. Changing the behaviour of a construct in the language - 4. Changing the binary format of the language in a backwards-compatible way - 5. Changing the binary format of the language in a backwards-incompatible way + 1. Adding a new Plutus Core language version 2. The Plutus Core builtin functions and types 1. Adding a new builtin function or type 2. Removing a builtin function or type @@ -99,37 +130,32 @@ Changes to Plutus Core can be released onto Cardano in four ways, with ascending 1. A _protocol parameter_ change (PP), taking effect as soon as the new parameters are accepted (in a new epoch). 2. A _software update_ (SU) to the node, taking effect when nodes upgrade. 3. A _hard fork_ (HF) (accompanied by a software update), requiring a software update for the new protocol version, and taking effect after the hard fork. -4. A new Plutus Core _language version_ (LV), introduced in a hard fork, and taking effect for scripts that use the new version, but not for those that use the old version. +4. A new Plutus Core _ledger language_ (LL), introduced in a hard fork, and taking effect for scripts that use the new language, but not for those that use the old language. Intuitively, these correspond to how _compatible_ the change is. - A backwards- and forwards-compatible change can be deployed with a software update, as nobody can perceive the difference. - A backwards-compatible (but not forwards-compatible) change must be deployed in a hard fork, since it makes more blocks acceptable than before. -- A backwards-incompatible change requires a new Plutus Core language version, so that the ledger can distinguish them, and maintain the old behaviour for old scripts. +- A backwards-incompatible change requires a new Plutus Core ledger language, so that the ledger can distinguish them, and maintain the old behaviour for old scripts. The following table lists, for each type of change in "Types of change", what kind of release it requires. | Change | Release | Notes | |----------------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------| -| Adding a language construct | HF | Backwards-compatible. | -| Removing a language construct | LV | This will cause scripts which use this construct to be rejected, so is not backwards compatible. | -| Changing the behaviour of a construct in the language | LV | This changes the behaviour of existing scripts, so is not backwards compatible. | -| Changing the binary format of the language in a backwards-compatible way | HF | Safe even if it makes previously non-deserializable scripts deserializable.[^1] | -| Changing the binary format of the language in a backwards-incompatible way | LV | | -| Adding a new builtin function or type | HF (rarely LV[^2]) | Backwards-compatible. Requires a binary format change. | -| Removing a builtin function or type | LV | This will cause scripts which use this builtin to be rejected, so is not backwards compatible. | -| Changing the behaviour of a builtin function or type | LV | This changes the behaviour of existing scripts, so is not backwards compatible. | -| Changing the interface between the ledger and the interpreter | LV | The ledger must provide scripts with exactly the right interface. New interface means new language. | -| Improving model performance | PP | _Must_ strictly follow an improvement in real performance.[^3] | +| Adding a new Plutus Core language version | HF | Backwards-compatible since the new behaviour is guarded by the new LV. | +| Adding a new builtin function or type | HF (rarely LL[^binary-backwards]) | Backwards-compatible. Requires a binary format change. | +| Removing a builtin function or type | LL | This will cause scripts which use this builtin to be rejected, so is not backwards compatible. | +| Changing the behaviour of a builtin function or type | LL | This changes the behaviour of existing scripts, so is not backwards compatible. | +| Changing the interface between the ledger and the interpreter | LL | The ledger must provide scripts with exactly the right interface. New interface means new language. | +| Improving model performance | PP | _Must_ strictly follow an improvement in real performance.[^why-perf-1] | | Regressing model performance | PP | | | Adding cost model parameters | HF | All nodes must recognize the new parameter. | -| Removing cost model parameters | LV | Old scripts will require all the old parameters. | +| Removing cost model parameters | LL | Old scripts will require all the old parameters. | | Improving real performance | SU | | -| Regressing real performance | SU | _Must_ strictly follow a regression in model performance.[^4] | +| Regressing real performance | SU | _Must_ strictly follow a regression in model performance.[^why-perf-2] | -[^1]: See "Are backwards-compatible binary format changes really safe?". -[^2]: The binary format change is backwards compatible unless it breaches the limit of how many builtin functions or types can be encoded, in which case that must be changed, forcing a new LV. -[^3]: See "Why do performance changes require extra steps?". -[^4]: See "Why do performance changes require extra steps?". +[^binary-backwards]: The binary format change is backwards compatible unless it breaches the limit of how many builtin functions or types can be encoded, in which case that must be changed, forcing a new LL. +[^why-perf-1]: See "Why do performance changes require extra steps?". +[^why-perf-2]: See "Why do performance changes require extra steps?". ## Specification @@ -156,25 +182,25 @@ So, for example, a single CIP could propose multiple new builtin functions, or a Proposals for additions to the set of Plutus Core builtins SHOULD be proposed in a CIP and SHOULD adhere to the following additional process. -In order to move to Draft status, it MUST include: +In order to move to Proposed status, it MUST include: - In the Specification: - Names and types/kinds for the new functions or types. - A source for the implementation (e.g. a library which can be linked against); or a generic description of the functionality which is implementable in any programming language. - - In the Rationale: + - For new types: a precise description of the measure used for the size of a value of that type. + - For new builtin functions: a costing function for the builtin function. +- In the Rationale: - An argument for the utility of the new builtins. + - If an external implementation is provided: an argument that it satisfies the following non-exhaustive list of criteria: + - It is trustworthy + - It always terminates + - It (or its Haskell bindings) never throw any exceptions + - Its behaviour is predictable (e.g. does not have worst-case behaviour with much worse performance) + - Discussion of how any measures and costing functions were determined. It SHOULD also include: - In the Rationale - Examples of real-world use cases where the new additions would be useful. - - A comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance). - -In order to move to Proposed status, it MUST include: -- In the Specification: - - For new types: a precise description of the measure used for the size of a value of that type. - - For new builtin functions: a costing function for the builtin function. -- In the Rationale: - - If an external implementation is provided: an argument that it is trustworthy. - - Discussion of how any measures and costing functions were determined. + - If feasible, a comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance). In order to move to Active status, the following must be true: - The external implementations MUST be available. @@ -206,12 +232,12 @@ A "bug fix" is a change to behaviour where: In this case the fix may be submitted directly to the `plutus` repository and is NOT required to go through the CIP process. It must still be released as appropriate. -For example, if a bug fix changes behaviour, it will have to wait for a new Plutus Core language version. +For example, if a bug fix changes behaviour, it will have to wait for a new Plutus Core ledger language. ### Implementing and releasing changes This CIP does not cover the process of implementing changes. -As usual, the CIP process covers the design phase, and it is up to the implementor to ensure that their proposal is implemented, which may require additional work to meet the requirements of the maintainers of the Cardano code repositories (testing, implementation quality, approach), and so on. +As usual, the CIP process covers the design phase, and it is up to the implementer to ensure that their proposal is implemented, which may require additional work to meet the requirements of the maintainers of the Cardano code repositories (testing, implementation quality, approach), and so on. Changes can be released after their CIPs have reached Active status. Different changes will require different releases as described in "Types of release". @@ -224,9 +250,9 @@ Any CIP which proposes a type of change listed in "Types of change" MUST also ad | # | Title | Type of change | Status | |----|-------------------|-------------------------|--------| -| 31 | Reference inputs | Ledger-script interface | Draft | -| 32 | Inline datums | Ledger-script interface | Draft | -| 33 | Reference scripts | Ledger-script interface | Draft | +| 31 | Reference inputs | Ledger-script interface | Active | +| 32 | Inline datums | Ledger-script interface | Active | +| 33 | Reference scripts | Ledger-script interface | Active | ## Rationale @@ -240,15 +266,18 @@ However, this becomes less so as the platform starts to mature and is neither su Furthermore, while many changes to Cardano are obscure or not of interest to many community members, there is a much larger community who have a keen interest in changes to Plutus Core: dApp developers. Hence it is especially important to have a clear way for this community to be able to propose changes and see how they are progressing. -### Do removals and changes really need a new language version? +### Do removals and changes really need a new ledger language? -Not being able to make removals or changes to behaviour without a LV is quite painful. -For example, it means that we cannot just fix bugs in the semantics: we must remain bug-for-bug compatible with any given LV. +Not being able to make removals or changes to behaviour without a LL is quite painful. +For example, it means that we cannot just fix bugs in the semantics: we must remain bug-for-bug compatible with any given LL. It is tempting to think that if we can show that a particular behaviour has never been used in the history of the chain, then changing it is backwards-compatible, since it won’t change the validation of any of the actual chain. However, this is sadly untrue. -The behaviour could be triggered (potentially deliberately) in the interval between the update proposal being accepted and it being implemented, which is extremely dangerous. -So even if a bug is obscure, we cannot just fix it. + +1. The behaviour could be triggered (potentially deliberately) in the interval between the update proposal being accepted and it being implemented. This is extremely dangerous and could lead to an un-managed hard fork. +2. The behaviour could be triggered in a script which has not yet been executed on the chain, but whose hash is used to lock an output. This could lead to that output being unexpectedly un-spendable, or some other change in behaviour. Moreover, since we only have the hash of the script, we have no way of telling whether this is the case. + +So even if a behaviour is obscure, we cannot just change it. ### Are backwards-compatible binary format changes really safe? @@ -295,13 +324,13 @@ Surfacing these difficulties quickly is a key goal of this process. Finally, builtins are a comparatively structured extension point for the language. In comparison, proposals for changes to Plutus Core itself are likely to be much more heterogeneous. -### Why are we reluctant to release new language versions? +### Why are we reluctant to release new ledger language? -Language versions (or more properly, languages from the ledger’s perspective) incur a large maintenance cost. +Ledger languages incur a large maintenance cost. Each one must continue to work, perfectly, in perpetuity. Furthermore, they may need their own, independent set of cost model protocol parameters, etc. -So it is very desirable to keep the number of language versions down. -The simplest way to do this is to batch changes, and only release a new language version occasionally. +So it is very desirable to keep the number of ledger languages down. +The simplest way to do this is to batch changes, and only release a new ledger language occasionally. ### Why include a CIP registry? From e201fd210442e9280e5a9b02e0d2d559c0325e19 Mon Sep 17 00:00:00 2001 From: Martin Lang <47434720+gitmachtl@users.noreply.github.com> Date: Tue, 17 Jan 2023 13:47:35 +0100 Subject: [PATCH 13/22] CIP-0083? | Adding encrypted messages to CIP-0020 (#409) * Create README.md * Create democode-NODEJS.js * Create democode-PHP.php * Create democode-BASH.sh * Create normal-message-metadata.json * Create encrypted-message-metadata.json * Removed markdown in the header preamble * Update README.md * grammer correction * grammer correction * Create democode-WEB.js * Added 'Path to Active' section * Update AdaStat.net Screenshots * Update README.md * Adding Eternl.io - Now active implementation - Eternl.io Wallet has now done an active implementation - Added Screenshot * removed ' 

' * Updating formatting - removed  

entries - shifted captions one level down * moved integration examples into section 'path to active' * added comment about future mixed style option * added comment why base64 format was choosen * Create format.cddl * Update README.md * Changed status to 'Active' * Update and rename CIP-????/README.md to CIP-0083/README.md * Rename CIP-????/format.cddl to CIP-0083/format.cddl * Rename CIP-????/codesamples/democode-BASH.sh to CIP-0083/codesamples/democode-BASH.sh * Rename CIP-????/codesamples/democode-NODEJS.js to CIP-0083/codesamples/democode-NODEJS.js * Rename CIP-????/codesamples/democode-PHP.php to CIP-0083/codesamples/democode-PHP.php * Rename CIP-????/codesamples/democode-WEB.js to CIP-0083/codesamples/democode-WEB.js * Rename CIP-????/codesamples/encrypted-message-metadata.json to CIP-0083/codesamples/encrypted-message-metadata.json * Rename CIP-????/codesamples/normal-message-metadata.json to CIP-0083/codesamples/normal-message-metadata.json --- CIP-0083/README.md | 275 ++++++++++++++++++ CIP-0083/codesamples/democode-BASH.sh | 50 ++++ CIP-0083/codesamples/democode-NODEJS.js | 97 ++++++ CIP-0083/codesamples/democode-PHP.php | 88 ++++++ CIP-0083/codesamples/democode-WEB.js | 42 +++ .../encrypted-message-metadata.json | 11 + .../codesamples/normal-message-metadata.json | 5 + CIP-0083/format.cddl | 14 + 8 files changed, 582 insertions(+) create mode 100644 CIP-0083/README.md create mode 100644 CIP-0083/codesamples/democode-BASH.sh create mode 100644 CIP-0083/codesamples/democode-NODEJS.js create mode 100644 CIP-0083/codesamples/democode-PHP.php create mode 100644 CIP-0083/codesamples/democode-WEB.js create mode 100644 CIP-0083/codesamples/encrypted-message-metadata.json create mode 100644 CIP-0083/codesamples/normal-message-metadata.json create mode 100644 CIP-0083/format.cddl diff --git a/CIP-0083/README.md b/CIP-0083/README.md new file mode 100644 index 0000000000..ef0ef66212 --- /dev/null +++ b/CIP-0083/README.md @@ -0,0 +1,275 @@ +--- +CIP: 83 +Title: Encrypted Transaction message/comment metadata (Addendum to CIP-0020) +Status: Active +Category: Metadata +Authors: + - Martin Lang + - Ola Ahlman + - Andrew Westberg + - Adam Dean +Implementors: + - Cardano Explorer + - StakePoolOperator Scripts + - AdaStat.net + - Eternl Wallet + - CNTools + - JorManager + - Cardanoscan.io +Discussions: + - https://github.com/cardano-foundation/CIPs/pull/394 +Created: 2022-12-08 +License: CC-BY-4.0 +--- + + +## Abstract + +This CIP is an addendum to the original [CIP-0020](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0020), which is active since mid 2021 and widely used across many entities. +It describes the JSON schema to add encrypted messages/comments/memos as transaction metadata. It is fully backwards compatible and requires no changes in existing tools, explorers, wallets. +Tools/Wallets that do not have an implementation to decrypt this format will just show the encrypted base64 as the message, but it will not break any existing processes. + +## Motivation: why is this CIP necessary? + +### Current state of transaction messages + +Transaction messages/comments/memos via CIP-0020 are widely used across the Cardano Blockchain. For example DEXs are using it to comment there payouts to the customers. +Individual users are using it to send funds across the network to other users with attached information about it. Users are buying goods and pay directly in ADA, attaching payment informations +via an added message. + +Theses and many other usecases are actively happening on the blockchain right now and are a valuable addition to the core functions. + +### What is the issue with the current implementation? + +Metadata is attached as a CBOR bytearray in the auxiliary dataset of a transaction. So the encoding is just done from UTF8-Text to Hex-Code/Bytes and after that it is sent in plaintext over the network/blockchain. +To seek further adoption of blockchain usage, privacy features are a must in the future. Having cleartext information in a TCP packet might not be an issue for many things, but it is an issue if you wanna convince +users to use the blockchain and their transaction feature like users using it now with bank transfers. + +It is easy for 3rd-party entities like Internet Service Providers, Datacenters or basically any Man-In-The-Middle to collect data that is sent in cleartext. +Data such as bank-account-numbers, email-addresses, telephone numbers, etc. which are parts of transaction messages. + +### What benefits/features would this CIP have on transaction messages? + +As pointed out above, everyone that is having access to the datastream and of course the publicly distributed ledger can extract the cleartext data of the transaction messages. +Because there must not even be a specific approach to get such transaction message data out of a TCP stream, just a simple filter for email addresses (example) is enough. +Even with a simple encryption of such messages - and publicly known passphrase - it is much more complicated for the Man-In-The-Middle listener to collect data on the fly. + +**Targeted benefits:** + - By using a default passphrase, Man-In-The-Middle "sniffer" cannot extract/parse data like email-addresses, invoice-numbers on the fly that easily. They would need to search for a cardano-node transmission and decrypt each message. Public explorers like Cexplorer.io, Cardanoscan, etc. can still show the decrypted message content via there https connection to the user. So no cleartext transmission at all. + - Different users can transfer funds with encrypted messages attached between each other, using a preshared passphrase. Only theses users need to know the content. Example: A user buys goods from an online-store, the store provides a preshared-passphrase to the user on their website or via email, the user sends the payment with payment-information encrypted with this passphrase to the store. + - Keeping the usecase of a transaction private does not only belong to different entities, but to a single user too. Example: If a user sends funds to a Dex or wants to lend some fund to a friend, he just can add information like 'Sent xxx ADA to bob for xxx' to the outgoing transaction as a documentation using an own choosen private passphrase. This information is stored on the chain and so in the wallet, only the user itself can review the use case of these transactions. + - Backwards compatible with CIP-0020 + - Easy implementation by using well known tools like OpenSSL + +### What this CIP is not trying to do + +This addition to the original CIP-0020 should not be seen as the end-all-be-all security solution for privacy on the blockchain. There's better options and upcoming Midnight for that. The transaction messages are also not intended to act like chat messages on the chain. + +# Specification - Encrypted message + +The specification update for encrypted messages takes advantage of the simple original design, which is leaving room for additional json-keys not affecting the parsing of the content at all. The only outcome if a receiver does not process the encrypted content is, that the encrypted message is shown instead of an maybe autodecrypted one. But even the encrypted base64 strings fit into the max. 64char long string restriction. So it does not break any tools. More on the autodecryption later. + +### Format: +``` json +{ + "674": + { + "enc": "", + "msg": + [ + "base64-string 1", "base64-string 2", "base64-string 3" ... + ] + } +} +``` +The format is identical to the original one, with a simple addition of the `enc` (encryptionmode) entry. + +The value given in the `enc` field references the type of encryption is used. Starting with a simple implementation named `basic`. There is room to add additional encryption method in the future like using ChaCha20/Poly1305 or using public/private key encryption. Also there is the possibility to not encode the metadata in the standard JSON format, but using CBOR encoding instead. + + +### Encryption methods: + +#### **plain** - no encryption at all + + | Parameter | Value | + | :--- | :--- | + | method | **plain** | + |description|plaintext, no encryption| + + This is not really an encryption mode, but included as a backwards compatible entry to signal this message as an unencrypted one. The entry is not needed and fully optional for unencrypted messages. + +#### **basic** - aes-256-cbc salted symmetric encryption via passpharse (+default passphrase) + + | Parameter | Value | + | :--- | :--- | + | method | **basic** | + | description | symmetrical encryption via openssl and a passphrase | + | default passphrase | cardano | + | type | openssl | + | cipher | aes-256-cbc (salted) | + | digest | pdkdf2 | + | iterations | 10000 (default) | + | key + iv | 32 bytes key + 16 bytes iv | + | salt | 8 bytes | + | prefix | `Salted__` | + | encoding | base64| + +OpenSSL was choosen, because its fast and widely available also for all kind of different platforms, web frontends, etc. Encryption algo is **AES-256-CBC** (salted) using `pdkdf2` to derive the key from the given passphrase. 10000 Iterations is the default value for this encryption method. The format of the encoded output is base64 format. + +The encryption is based on a given passphrase, which can be choosen by the user. However, a default-passphrase "cardano" should be used to encrypt/decrypt if no other passphrase is provided or known. + +##### Why a default passphrase? + +As pointed out above, its way harder for man-in-the-middle listeners, to decrypt every single message on the fly. So by using a default passphrase, tools can encrypt messages and explorers/wallets can autodecrypt such messages trying to use the default passphrase. In that way, the displayed message is automatically readable to the user. If a more protected communication is needed, the sender can choose a custom passphrase and communicate that to the receiver as a preshared passphrase. + +What part is uses for the encryption? + +The **whole content** of the unencrypted normal transaction **metadata `msg:` key is used**, thats the array with the message string(s). (Example below) + +##### Is there sample code? + +Yes, example implementations for node.js, PHP, bash, etc. can be found in the [codesamples](./codesamples/) folder. They are showing how to encrypt/decrypt text with the right parameters set for this basic mode. + +**warning** + +Message decryption should be done on the user frontend if possible, not via server callbacks.** + +#### Encryption/Decryption example on the console - basic mode + +First, generate a normal metadata transaction message. + +**normal-message-metadata.json**: +``` json +{ + "674": { + "msg": ["Invoice-No: 123456789","Order-No: 7654321","Email: john@doe.com"] + } +} +``` + +The **encryption** is done on the **whole content of the `msg:` key**, so this is + +`["Invoice-No: 123456789","Order-No: 7654321","Email: john@doe.com"]` + +in our example. + +**Encrypt** this content via openssl, the default passprase **cardano**, iteration set to 10000 and key-derivation via pbkdf2: +``` console +openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k "cardano" <<< '["Invoice-No: 123456789","Order-No: 7654321","Email: john@doe.com"]' +``` + +The encrypted result are the **base64 encoded strings**: +``` +U2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y +/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7 +``` + +Compose the JSON by **using the base64 encoded encrypted strings now for the `msg:` part**. + +Also add the value `basic` for the `enc:` key, to mark this transaction message as encrypted with basic mode. + +**encrypted-message-metadata.json**: +``` json +{ + "674": + { + "enc": "basic", + "msg": + [ + "U2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y", + "/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7" + ] + } +} +``` + +Console one-liner: +``` console +jq ".\"674\".msg = [ $(jq -crM .\"674\".msg normal-message-metadata.json | openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k "cardano" | awk {'print "\""$1"\","'} | sed '$ s/.$//') ]" <<< '{"674":{"enc":"basic"}}' | tee encrypted-message-metadata.json | jq +``` + +--- + +A **decryption** can be done in a similar way: +``` console +jq -crM ".\"674\".msg[]" encrypted-message-metadata.json | openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -a -k "cardano" +``` + +Which results in the original content of the **msg** key: + +`["Invoice-No: 123456789","Order-No: 7654321","Email: john@doe.com"]` + +## Rationale + +This design is simple, so many tools on the cardano blockchain can adopt it easily and a few have already started to implement it. +The original CIP-0020 design allowed the addition of new entries like the `"enc":` key for encrypted messages in this CIP. Therefore the encoding format of the encrypted message was choosen to be UTF-8 instead of bytearrays, because it would break the backwards compatibility to CIP-0020. But maybe more important, it gives the user a simple text-format to handle such messages. Users can copy and paste the base64 encoded string(s) using there own tools for creation and verification. For example, a user can simply copy the encrypted format from an explorer and verify it with an external own local tool. Such messages are usally pretty short. Yes, the benefit of using bytearrays is to have less data (around -33% over base64), but the decision was made to sacrifice this benefit in favor of the base64 format for the reasons pointed out before. + +There is also for example [CIP-8](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0008), but CIP-8 doesn't really fulfill the simplicity of just providing encrypted messages. CIP-8 is focused on Signing, which is not needed for encryption. The method to generate encrypted messages here is not intended to verify the owner of a message via signing. There is no need that everything on Cardano must be difficult. Also using such CBOR encoded structures would break all currently implemented transaction message solutions. This CIP uses openssl and base64 encoding, and endusers could even copy&paste such text into other tools, etc. Future updates may include the option to mix encrypted and unencrypted messages by adding another key like `msgclear` to support such a mixed message style format. + +### Implementation suggestions + +Wallets/Tools can implement an autodecryption attempt with the default passphrase on such messages, to give the user a more streamlined experience. The communication should be done via https or similar to make sure the message cleartext is not exposed again during the transmission. +Additionally the Tools can prompt for an input and decrypt the message once the user has requested it, this decryption should be done on the user frontend for further security. + +### Handling ill-formed 674 metadata ## + +Like with CIP-0020, it is up to the wallet-/display-/receiver-implementor to parse and check the provided metadata. As for the current state, its not possible to have the same label "674" more than once in a cardano transaction. So a check about that can be ignored at the moment. This CIP provides the correct implementation format, the parsing should search for the "674" metadata label, the "msg" and the "enc" key underneath it. There should also be a check, that the provided data within that "msg" key is an array. All other implementations like a missing "msg" key, or a single string instead of an array, should be marked by the display-implementor as "invalid". Additional keys within the "674" label should not affect the parsing of the "msg" and the "enc" key. As written above, we will likely see more entries here in the future like a "version" key for example, so additional keys should not harm the parsing of the "msg" and "enc" key. + +### Implementation conclusion ## + +An encrypted transaction message should be considered valid if the following apply: + +* Label = 674. +* has property "enc". +* enc property contains a supported method like `basic` +* has property "msg". +* msg property contains an array of strings, even for a single-line message. +* Each line has a maximum length of 64 characters. +* If there are additional properties, they don't invalidate the message. They can just be ignored. + +If any of the above is not met, ignore the metadata as an encrypted transaction message. Can still be displayed as general metadata to the transaction. + +The implementation format in this CIP should be the ground base for encrypted transaction messages/comments/memos and should be respected by creator-/sender-implementations as well as in wallet-/receiver-/display-implementations. + +## Path to Active + +### Acceptance Criteria + +The acceptance criteria to be `Active` should already have been met, because the following Implementors using this CIP on the Cardano Blockchain: + +* Cardano Explorer (https://cexplorer.io) +* StakePoolOperator Scripts (https://github.com/gitmachtl/scripts) +* AdaStat.net (https://adastat.net) +* Eternl Wallet (https://eternl.io) + +#### Integration examples for encrypted messages + +**Cexplorer.io**: With the implementation of the **encrypted message decoding**. +![image](https://user-images.githubusercontent.com/47434720/204560392-f45bbe4f-7f78-48fa-9e47-4d3b104685bf.png) + +**StakePool Operator Scripts**: It works on the commandline like any other script of the collection by just adding the `"enc: basic"` parameter, you can provide an individual passphrase by using the `"pass:"` parameter. This automatically generates the needed metadata.json structure with the encrypted message in it and attaches it to the transaction itself. +![image](https://user-images.githubusercontent.com/47434720/205442737-748a7fb0-90fc-4cc3-898c-98b06894a900.png) + +**Eternl.io**: +![image](https://user-images.githubusercontent.com/47434720/210166917-8af475fe-5cda-46f5-bd8d-3fc4c2c12482.png) + +**AdaStat.net**: With the implementation of the **encrypted message decoding** using a pure **frontend solution**. +![image](https://user-images.githubusercontent.com/47434720/206574191-22aa490a-5870-4853-906b-443284458987.png) +![image](https://user-images.githubusercontent.com/47434720/206574354-5dd81551-efc6-4f69-a2aa-282bb40e5084.png) + + +### Implementation Plan + +The following Projects have committed to also implement it: + +* CNTools (https://cardano-community.github.io/guild-operators/#/Scripts/cntools) +* JorManager (https://bitbucket.org/muamw10/jormanager/) +* Cardanoscan.io (https://cardanoscan.io) + +The plan is to reach out to other projects - which already supporting the normal transaction messages - too. And of course also to new ones. + +There are various **code samples available** in the [**codesamples**](codesamples/) folder to make it as easy as possible for integrators to implement it. + +## Copyright + +This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode) diff --git a/CIP-0083/codesamples/democode-BASH.sh b/CIP-0083/codesamples/democode-BASH.sh new file mode 100644 index 0000000000..0fa135e493 --- /dev/null +++ b/CIP-0083/codesamples/democode-BASH.sh @@ -0,0 +1,50 @@ +#!/bin/bash + +# -------------------------------------------------------------------------------------------- +# Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via BASH +# -------------------------------------------------------------------------------------------- + +#Setting default passphrase +passphrase="cardano" + + +#Unencrypted Metadata JSON +echo "Normal unencrpted messages metadata JSON:" +cat normal-message-metadata.json | jq +echo + + +#Encrypt the msg array from the JSON +encrText=$(jq -crM .\"674\".msg normal-message-metadata.json | openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -a -k "${passphrase}") +echo "Encrypted Strings (base64 format):" +echo "${encrText}" +echo + + +#Compose it into a new JSON and add the 'enc' entry +echo "New encrypted messages metadata JSON:" +jq ".\"674\".msg = [ $(awk {'print "\""$1"\","'} <<< ${encrText} | sed '$ s/.$//') ]" <<< '{"674":{"enc":"basic"}}' | jq + + +echo +echo "----------------------" +echo + + +#Encrypted Metadata JSON +echo "Encrypted messages metadata JSON:" +cat encrypted-message-metadata.json | jq +echo + + +#Decrypt the msg array from the JSON +decrText=$(jq -crM ".\"674\".msg[]" encrypted-message-metadata.json | openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -a -k "${passphrase}") +echo "Decrypted Content:" +echo "${decrText}" +echo + + +#Compose it into a new JSON in the standard message format +echo "New messages metadata JSON:" +jq ".\"674\".msg = ${decrText}" <<< "{}" +echo diff --git a/CIP-0083/codesamples/democode-NODEJS.js b/CIP-0083/codesamples/democode-NODEJS.js new file mode 100644 index 0000000000..2d42418b27 --- /dev/null +++ b/CIP-0083/codesamples/democode-NODEJS.js @@ -0,0 +1,97 @@ +// ----------------------------------------------------------------------------------------------- +// Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via NODE-JS +// ----------------------------------------------------------------------------------------------- + +const crypto = require('crypto'); + +// +// Calculate the KeyIV via the PasswordBasedKeyDerivedFormat2 pbkdf2 method, 10000 iterations, 48 bytes long, sha256 +// +function calc_KeyIV(passphrase, salt) { //passphrase as utf8 string, salt as hexstring + const key_IV = crypto.pbkdf2Sync(Buffer.from(passphrase,'utf8'), Buffer.from(salt,'hex'), 10000, 48, 'sha256').toString('hex') + console.log(` keyIV: ${key_IV}`); + return key_IV; //hex-string +} + +// +// Encryption Function +// +function encryptCardanoMessage(decrypted_msg, passphrase = 'cardano') { //decrypted_msg as utf8 string, passphrase as utf8 string(defaults to cardano) + //Encrypted Message (salted) looks like 'Salted__' + 8 bytes salt + cyphertext + //Build up the encrypted Message as hex string + var encrypted_hex = Buffer.from('Salted__','utf8').toString('hex'); + //Generate the random salt + var salt = crypto.randomBytes(8).toString('hex'); + encrypted_hex += salt; //append the salt + console.log(` salt: ${salt}`); + //Calculate the Key+IV + var keyIV = calc_KeyIV(passphrase, salt) + //The key itself is the first 32 Bytes (char 0-64 in hex string) + var key = keyIV.substring(0,64); + //The IV (initialization vector) is 16 Bytes and follows the key + var iv = keyIV.substring(64); + console.log(` key: ${key}`); + console.log(` iv: ${iv}`); + //Encrypt the message + const cipher = crypto.createCipheriv('aes-256-cbc', Buffer.from(key,'hex'), Buffer.from(iv,'hex')); + try { + var cyphertext = cipher.update(decrypted_msg, 'utf8', 'hex') + cipher.final('hex'); + } catch (error) { console.error(`Could not encrypt the message\n${error}`); process.exit(1); } + console.log(` cyphertext: ${cyphertext}`); + encrypted_hex += cyphertext; //append the cyphertext + console.log(` Enc-Message(hex): ${encrypted_hex}`); + return Buffer.from(encrypted_hex,'hex').toString('base64'); //base64 string +} + + +// +// Decryption Function +// +function decryptCardanoMessage(encrypted_msg, passphrase = 'cardano') { //encrypted_msg as base64 string, passphrase as utf8 string(defaults to cardano) + //Encrypted Message is base64 encoded, convert it to hex + const encrypted_hex = Buffer.from(encrypted_msg, 'base64').toString('hex'); + console.log(` Enc-Message(hex): ${encrypted_hex}`); + //Encrypted Message (salted) looks like 'Salted__' + 8 bytes salt + cyphertext + //Salt is byte 9-16 in the Encrypted Message (char 16-32 in a hex string) + var salt = encrypted_hex.substring(16,32); + console.log(` salt: ${salt}`); + //Cyphertext is all the rest after the salt (starting with char 32 in a hex string) + var cyphertext = encrypted_hex.substring(32); + console.log(` cyphertext: ${cyphertext}`); + //Calculate the Key+IV + var keyIV = calc_KeyIV(passphrase, salt) + //The key itself is the first 32 Bytes (char 0-64 in hex string) + var key = keyIV.substring(0,64); + //The IV (initialization vector) is 16 Bytes and follows the key + var iv = keyIV.substring(64); + console.log(` key: ${key}`); + console.log(` iv: ${iv}`); + //Decrypt the cyphertext with the key and the iv + const decipher = crypto.createDecipheriv('aes-256-cbc', Buffer.from(key,'hex'), Buffer.from(iv,'hex')); + try { + var decr_msg = decipher.update(cyphertext, 'hex').toString('utf8') + decipher.final('utf8'); + } catch (error) { console.error(`Could not decrypt the message\n${error}`); process.exit(1); } + return decr_msg; //utf8 +} + +//------------------------- +// DEMO Encrypt and Decrypt +//------------------------- + +const passphrase = 'cardano'; //Using default passphrase 'cardano' + +// Encryption +console.log(`--- Encryption ---`); +var decrypted_msg = 'Hi, this is a test-message. Best regards, Martin'; +console.log(` Dec-Message(utf8): ${decrypted_msg}`) +var encrypted_msg = encryptCardanoMessage(decrypted_msg, passphrase); +console.log(`Enc-Message(base64): ${encrypted_msg}`); +console.log(`\n\n`); + +// Decryption +console.log(`--- Decryption ---`); +var encrypted_msg = 'U2FsdGVkX18UshV/vpKWoYtutcS2efoloN+okKMY+pYdvUnqi88znUhHPxSSX8t4'; +console.log(`Enc-Message(base64): ${encrypted_msg}`); +var decrypted_msg = decryptCardanoMessage(encrypted_msg, passphrase); +console.log(` Dec-Message(utf8): ${decrypted_msg}`) +console.log(`\n\n`); diff --git a/CIP-0083/codesamples/democode-PHP.php b/CIP-0083/codesamples/democode-PHP.php new file mode 100644 index 0000000000..b116dc3f60 --- /dev/null +++ b/CIP-0083/codesamples/democode-PHP.php @@ -0,0 +1,88 @@ +// ------------------------------------------------------------------------------------------ +// Demonstration implementation of CIP-0020 Transaction Messages Encryption/Decryption via PHP +// ------------------------------------------------------------------------------------------ + + 60) { + return ($elapsed / 60) . " minutes"; + } else { + return $elapsed . " seconds"; + } +} + +function getPbkdf2($password, $salt, $iterations) { + return openssl_pbkdf2($password, $salt, 48, $iterations, 'sha256'); +} + +function encryptCardanoMessage($msg, $password = 'cardano', $iterations = 10000) { + if (debug) { + $start = microtime(true); + } + $salt = openssl_random_pseudo_bytes(8); + $encryptedText = "Salted__" . $salt; + + $keyIV = getPbkdf2($password, $salt, $iterations); + $key = substr($keyIV, 0, 32); + $iv = substr($keyIV, 32); + + $encryptedText .= openssl_encrypt($msg, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); + $hashedEncryptedText = base64_encode($encryptedText); + + if (debug) { + echo "Done encrypting message in " . elapsedTime($start) . "\r\n"; + } + + return $hashedEncryptedText; +} + +function decryptCardanoMessage($msg, $password = 'cardano', $iterations = 10000) { + if (debug) { + $start = microtime(true); + } + + $encryptedText = base64_decode($msg); + $salt = substr($encryptedText, 8, 8); + $cyphertext = substr($encryptedText, 16); + + $keyIV = getPbkdf2($password, $salt, $iterations); + $key = substr($keyIV, 0, 32); + $iv = substr($keyIV, 32); + + $decrypted = openssl_decrypt($cyphertext, 'aes-256-cbc', $key, OPENSSL_RAW_DATA, $iv); + + if (debug) { + echo "Done decrypting message in " . elapsedTime($start) . "\r\n"; + } + + return $decrypted; +} + +$payload = "Testing message signing..."; + +// Basic signed/encrypted message w/ default password of "cardano" +$signed = encryptCardanoMessage($payload); + +// Basic signed/encrypted message w/ custom password +$passwordSigned = encryptCardanoMessage($payload, "You'll never guess it!"); + +// Basic signed/encrypted message w/ custom password and fewer iterations +$shortPasswordSigned = encryptCardanoMessage($payload, "Please", 20); + +// Basic decoding w/ default password of "cardano" +$unsigned = decryptCardanoMessage($signed); +echo "\$signed is: {$unsigned}\r\n"; + +// Basic decoding w/ custom password +$unsignedPassword = decryptCardanoMessage($passwordSigned, "You'll never guess it!"); +echo "\$passwordSigned is: {$unsignedPassword}\r\n"; + +// Basic decoding w/ custom password and fewer iterations +$shortUnsigned = decryptCardanoMessage($shortPasswordSigned, "Please", 20); +echo "\$shortPasswordSigned is: {$shortUnsigned}\r\n"; diff --git a/CIP-0083/codesamples/democode-WEB.js b/CIP-0083/codesamples/democode-WEB.js new file mode 100644 index 0000000000..5432e3d102 --- /dev/null +++ b/CIP-0083/codesamples/democode-WEB.js @@ -0,0 +1,42 @@ +// ----------------------------------------------------------------------------------------------- +// Democode for running a Decryption on the Web Frontend - Method BASIC +// ----------------------------------------------------------------------------------------------- + +// Library that is used for this codesample: https://www.npmjs.com/package/crypto-js +// Just import it before using this code + +let encrypted = "U2FsdGVkX18IJMMB5MDfNmuvvlbu4m5ODGmCrHHtWfYKarTRT4/x790+uhsj7cgRxDFvjxU7dcSPqH5PAXvRtPcaRyqoYBaXOQbm3D78wQCY4wCiLF1/mFOvFHPfpQHeC9jykRfpaVC3rtlJdHCPTw==" +let encryptedWA = cryptoJS.enc.Base64.parse(encrypted); + +// Split the encrypted data into the individual pieces +let prefixWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(0, 8/4)); // Salted__ prefix +let saltWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(8/4, 16/4)); // 8 bytes salt: 0x0123456789ABCDEF +let ciphertextWA = cryptoJS.lib.WordArray.create(encryptedWA.words.slice(16/4, encryptedWA.words.length)); // ciphertext + +// Determine key and IV using PBKDF2 +let password = 'cardano' +let keyIvWA = cryptoJS.PBKDF2( + password, + saltWA, + { + keySize: (32+16)/4, // key and IV + iterations: 10000, + hasher: cryptoJS.algo.SHA256 + } +); +let keyWA = cryptoJS.lib.WordArray.create(keyIvWA.words.slice(0, 32/4)); +let ivWA = cryptoJS.lib.WordArray.create(keyIvWA.words.slice(32/4, (32+16)/4)); + +// Decrypt the data +let decryptedWA = cryptoJS.AES.decrypt( + { + ciphertext: ciphertextWA}, + keyWA, + {iv: ivWA} +); +let decrypted = decryptedWA.toString(cryptoJS.enc.Utf8) + +console.log(`Encrypted Data:`) +console.log(encrypted) +console.log(`Decrypted Data:`) +console.log(decrypted) diff --git a/CIP-0083/codesamples/encrypted-message-metadata.json b/CIP-0083/codesamples/encrypted-message-metadata.json new file mode 100644 index 0000000000..37d693a297 --- /dev/null +++ b/CIP-0083/codesamples/encrypted-message-metadata.json @@ -0,0 +1,11 @@ +{ + "674": + { + "enc": "basic", + "msg": + [ + "U2FsdGVkX1/5Y0A7l8xK686rvLsmPviTlna2n3P/ADNm89Ynr1UPZ/Q6bynbe28Y", + "/zWYOB9PAGt+bq1L0z/W2LNHe92HTN/Fwz16aHa98TOsgM3q8tAR4NSqrLZVu1H7" + ] + } +} diff --git a/CIP-0083/codesamples/normal-message-metadata.json b/CIP-0083/codesamples/normal-message-metadata.json new file mode 100644 index 0000000000..9ff9494fb1 --- /dev/null +++ b/CIP-0083/codesamples/normal-message-metadata.json @@ -0,0 +1,5 @@ +{ + "674": { + "msg": ["Invoice-No: 123456789","Order-No: 7654321","Email: john@doe.com"] + } +} diff --git a/CIP-0083/format.cddl b/CIP-0083/format.cddl new file mode 100644 index 0000000000..93877372c5 --- /dev/null +++ b/CIP-0083/format.cddl @@ -0,0 +1,14 @@ +string = text .size (0..64) ; utf-8 + +message_details = + { + msg : [* string], + ? enc : string + } + +; msg = array of utf-8 encoded strings +; enc = optional string with the encryption-method +; 'plain' => no encryption (optional) +; 'basic' => encryption-method basic + +messagedata = { 674 : uint => label_metadata } From 18228d57726137531fbf3771663ed66682c9288c Mon Sep 17 00:00:00 2001 From: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> Date: Tue, 17 Jan 2023 15:03:28 +0100 Subject: [PATCH 14/22] Edit CIP numbers and top-level README from editors meeting #60's outcome (#434) * Edit CIP numbers and top-level README from editors meeting #60's outcome * URL typo which breaks link * continued form last commit Now it is apparent there the extra S came from in the previously corrected typo. Co-authored-by: Robert Phair --- README.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index b6dfd94218..164f23159f 100644 --- a/README.md +++ b/README.md @@ -73,12 +73,15 @@ CIP Editors meetings are public, recorded, and [published on Youtube](https://ww | 60 | [Music Token Metadata](./CIP-0060) | Active | | 67 | [Asset Name Label Registry](./CIP-0067) | Proposed | | 68 | [Datum Metadata Standard](./CIP-0068) | Proposed | +| 71 | [Non-Fungible Token (NFT) Proxy Voting Standard](./CIP-0071) | Proposed | | 74 | [Set min-pool-cost to 0](./CIP-0074) | Proposed | +| 83 | [Encrypted Transaction message/comment metadata (Addendum to CIP-0020)](./CIP-0083) | Active | | 381 | [Plutus Support for Pairings Over BLS12-381](./CIP-0381) | Proposed | | 1852 | [HD (Hierarchy for Deterministic) Wallets for Cardano](./CIP-1852/) | Active | | 1853 | [HD (Hierarchy for Deterministic) Stake Pool Cold Keys for Cardano](./CIP-1853/) | Active | | 1854 | [Multi-signatures HD Wallets](./CIP-1854/) | Draft | | 1855 | [Forging policy keys for HD Wallets](./CIP-1855/) | Active | +| 9999 | [Cardano Problem Statements](./CIP-9999/) | Active |

Last updated on 2022-11-30

@@ -92,6 +95,8 @@ Below are listed tentative CIPs still under discussion with the community. They | --- | --- | | 38? | [Arbitrary Script as Native Script Spending Conditions](https://github.com/cardano-foundation/CIPs/pull/309) | 39? | [Language Annotated Address](https://github.com/cardano-foundation/CIPs/pull/310) | +| 45? | [Decentralized WebRTC dApp-Wallet Communication](https://github.com/cardano-foundation/CIPs/pull/395) | +| 46? | [Merklised Plutus Scripts](https://github.com/cardano-foundation/CIPs/pull/385/files) | | 48? | [Extended NFT metadata](https://github.com/cardano-foundation/CIPs/pull/249) | | 50? | [Shelley's Voltaire Decentralization Update](https://github.com/cardano-foundation/CIPs/pull/242) | | 56? | [Treasury Donation](https://github.com/cardano-foundation/CIPs/pull/269) | @@ -108,6 +113,7 @@ Below are listed tentative CIPs still under discussion with the community. They | 79? | [Implement Ouroboros Leios to increase Cardano throughput](https://github.com/cardano-foundation/CIPs/pull/379) | | 80? | [Transaction Serialization Deprecation Cycle](https://github.com/cardano-foundation/CIPs/pull/372) | | 81? | [Tiered Pricing Protocol](https://github.com/cardano-foundation/CIPs/pull/381) +| 82? | [Improved Rewards Scheme Parameters](https://github.com/cardano-foundation/CIPs/pull/422) | | 1694? | [A proposal for entering the Voltaire phase](https://github.com/cardano-foundation/CIPs/pull/380) | ### Proposals Under Review (CPS) @@ -129,14 +135,7 @@ The following list contains proposals that have been under review and for which - [UPLC Serialization Optimizations](https://github.com/cardano-foundation/CIPs/pull/314) - [Address Resolution Through DNS](https://github.com/cardano-foundation/CIPs/pull/319) - [Additional Factors For NFT Market Verification](https://github.com/cardano-foundation/CIPs/pull/226) -- [Decentralization: Using Pledge as a Bidding Param](https://github.com/cardano-foundation/CIPs/pull/229) -- [Prepay Min Fixed Fee](https://github.com/cardano-foundation/CIPs/pull/190) -- [Preserve Submitter's Ordering of Transaction Inputs](https://github.com/cardano-foundation/CIPs/pull/231) - [Transferring Stake Pool Ownership](https://github.com/cardano-foundation/CIPs/pull/276) -- [NFT Identity / W3C DID on Cardano](https://github.com/cardano-foundation/CIPs/pull/294) -- [Fair Stakepool Rewards](https://github.com/cardano-foundation/CIPs/pull/360) -- [ISPO KYC_CDD](https://github.com/cardano-foundation/CIPs/pull/241) -- [Ed25519 Elliptic Curve Group Primitives in Plutus Core](https://github.com/cardano-foundation/CIPs/pull/308)

Last updated on 2022-11-30

From d2b5b16d14c432fcb7b295d44cf2cda9e7a41ebd Mon Sep 17 00:00:00 2001 From: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> Date: Tue, 17 Jan 2023 16:13:31 +0100 Subject: [PATCH 15/22] Fix website build (#438) * Fix editors parsing + provide better debugging on malformed input data. * Display CIPs by category, if it exists. This also sorts categories such that 'All' is always first and 'Unclassified' is always last. --- CIP-0049/README.md | 20 +++++--------------- CIP-0074/README.md | 2 +- scripts/build.js | 40 ++++++++++++++++++++++++---------------- templates/cips.hbs | 4 ++-- 4 files changed, 32 insertions(+), 34 deletions(-) diff --git a/CIP-0049/README.md b/CIP-0049/README.md index 003854df69..b1081de802 100644 --- a/CIP-0049/README.md +++ b/CIP-0049/README.md @@ -1,25 +1,15 @@ --- -CIP: 49 -Title: ECDSA and Schnorr signatures in Plutus Core -Authors: Koz Ross (koz@mlabs.city), - Michael Peyton-Jones (michael.peyton-jones@iohk.io), - Iñigo Querejeta Azurmendi (querejeta.azurmendi@iohk.io) +CIP: 49 +Title: ECDSA and Schnorr signatures in Plutus Core +Authors: Koz Ross (koz@mlabs.city), Michael Peyton-Jones (michael.peyton-jones@iohk.io), Iñigo Querejeta Azurmendi (querejeta.azurmendi@iohk.io) Discussions-To: koz@mlabs.city -Comments-Summary: -Comments-URI: Status: Proposed Type: Standards Track -Created: 2022-04-27 -* License: -* License-Code: -* Post-History: -* Requires: -* Replaces: -* Superseded-By: +Created: 2022-04-27 --- ## Simple Summary -Support ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core; +Support ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core; specifically, allow validation of such signatures as builtins. ## Abstract diff --git a/CIP-0074/README.md b/CIP-0074/README.md index 2607a55afb..9006f28679 100644 --- a/CIP-0074/README.md +++ b/CIP-0074/README.md @@ -1,7 +1,7 @@ --- CIP: 74 Title: Set minPoolCost to 0 -Author: Robin of Loxley +Authors: Robin of Loxley Comments-URI: https://forum.cardano.org/t/cip-69-set-minpoolcost-to-0/109309 Status: Proposed Type: Standards diff --git a/scripts/build.js b/scripts/build.js index 84740cb978..c13fefe185 100644 --- a/scripts/build.js +++ b/scripts/build.js @@ -14,12 +14,16 @@ handlebars.registerHelper('dateFormat', (d, f) => { return moment(d).format(f); }); -handlebars.registerHelper('getAuthors', function (Authors) { +handlebars.registerHelper('getAuthors', function (data) { + if (data.Authors == undefined) { + throw new Error(`No authors: ${JSON.stringify(data)}`); + } - // Temporary fallback for CI to not fail - if(!Authors) return ''; + const authors = Array.isArray(data.Authors) + ? data.Authors + : data.Authors.split(','); - return Authors.split(',').map(author => { + return authors.map(author => { const [_, name, link] = author.trim().match(/^([^<]+)]+)?>?$/) || [] let type = 'url' if (link === undefined) { @@ -99,7 +103,7 @@ function renderHTML(uriPath, template, data) { fs.writeFileSync(path.join(publicPath, uriPath, 'index.html'), hbTemplate(data), { encoding: 'utf8' }) } -const types = { All: [] } +const categories = { All: [] } function slugify(string) { return string.toLowerCase().replace(/\s/g, '-') @@ -117,9 +121,10 @@ function build() { if (asset === 'README.md') { const cip = loadFrontmatter(assetPath) cip.tableOfContents = getTableOfContents(cip.content.split('\n')) - types[cip.data.Type] = types[cip.data.Type] || [] - types[cip.data.Type].push(cip) - types.All.push(cip) + const category = cip.data.Category || "Unclassified"; + categories[category] = categories[category] || [] + categories[category].push(cip) + categories.All.push(cip) } else { const name = item.toLowerCase().replace(/cip-0*([1-9][0-9]*)/g, 'cip$1') const title = `${name.replace(/cip/g, 'CIP ')} - Annexe`; @@ -143,20 +148,23 @@ function build() { const headerData = [] - Object.keys(types).forEach(type => { - headerData.push({ label: type, path: `/${slugify(type)}/` }) + Object.keys(categories).sort((a, b) => { + if ([a,b].includes("All")) { return a === "All" ? -1 : 1 } + if ([a,b].includes("Unclassified")) { return a === "Unclassified" ? 1 : -1 } + return a > b ? 1 : -1; + }).forEach(category => { + headerData.push({ label: category, path: `/${slugify(category)}/` }) }) - Object.keys(types).forEach(type => { + Object.keys(categories).forEach(category => { - renderHTML(`/${slugify(type)}/`, 'cips', { + renderHTML(`/${slugify(category)}/`, 'cips', { headerData, - cips: types[type], - type, - title: type + cips: categories[category], + category }) - types[type].forEach(cip => { + categories[category].forEach(cip => { renderHTML(`/cips/cip${cip.data.CIP}/`, 'cip', { headerData, cip, diff --git a/templates/cips.hbs b/templates/cips.hbs index 66ea4e5256..7b9060d4d7 100644 --- a/templates/cips.hbs +++ b/templates/cips.hbs @@ -14,10 +14,10 @@ {{{cip.data.Title}}} {{dateFormat cip.data.Created "DD MMMM YYYY"}} - {{{getAuthors cip.data.Authors}}} + {{{getAuthors cip.data}}} {{cip.data.Status}} {{/each}} -{{/main}} \ No newline at end of file +{{/main}} From 7f01399da798832bb10aefc41ee385f7f50c8e31 Mon Sep 17 00:00:00 2001 From: jmagan Date: Thu, 19 Jan 2023 15:07:13 +0100 Subject: [PATCH 16/22] Initial draft --- CIP-????/README.md | 98 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 CIP-????/README.md diff --git a/CIP-????/README.md b/CIP-????/README.md new file mode 100644 index 0000000000..1863ab9d6b --- /dev/null +++ b/CIP-????/README.md @@ -0,0 +1,98 @@ +--- +CIP: ? +Title: Authenticated Web3 HTTP requests +Category: Tools +Status: Proposed +Authors: + - Juan Salvador Magán Valero +Implementors: [] +Discussions: + - https://github.com/cardano-foundation/cips/pulls/? +Created: 2022-12-27 +License: CC-BY-4.0 +--- + +# CIP-XXXX: Authenticated Web3 HTTP requests + +## Abstract + +The cardano wallets have the ability to sign arbitrary pieces of data as we can see in the [Message signing CIP-0008](/CIP-0008/README.md). All wallets implement the method ```api.signData(addr: Address, payload: Bytes): Promise``` defined in [Cardano dApp-Wallet Web Bridge CIP-0030](/CIP-0030/README.md). + +An important use case for web3 sites is calling HTTP endpoints using authenticated requests signed by the private keys of the users' wallets. In this way, the servers can perform actions using onchain and offchain data. + + +## Motivation + +dApps generate arbritary payloads as byte arrays. These payloads are signed and included in the protected headers of the signatures. The wallets are responsible for showing the payload data to the user, who will proceed to sign or reject the payload. It's a common practice to encode a string or a JSON string but there isn't any standard for the way to construct and to show this data. + +The current implementations for web3 applications use static strings. This is dangerous because if a bad actor intercepts the signed message then it can be used in a replay attack by the bad actor. That's why it is very important to produce a dynamic payload rather a static string. + +Another problem with the current approach is how the wallets show the information contained in the payload. The payload is a enconded byte array and it could contain anything. If Alice want to call an endpoint and Bob has the ability to change the message before Alice gets it. Alice must be notified somehow that she is signing a potentially malicious payload. A simple hex-encoded representation of the payload isn't enough to ensure a safe interaction. + +## Specification + +This specification involves multiple parties. We split this specification in three parts: server processing, payload structure and wallet specification. + +### Requirement Levels + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). + +### Payload structure + +The payload MUST be encoded as a JSON string. JSON strings are semi-structured data that are human-readable. So that with a straightforward decoding into text, it will be understandable for the readers. This feature also allows the users to debug it in an easy manner, for example, with the browser debugger tools. + +The content of the payload will be included in the protected header of the COSESign1 signature, hence the content effects directly the behavior and security of the system. The payload MUST have the following fields: + +1. The field ```url``` MUST contain the full path to the endpoint, where the payload will be processed. + +2. Sometimes, the endpoint ```url``` field is not enough to determine its purpose. The user should understand perfectly the objective of the payload which he or she is signing. That's why the payload MUST contain an ```action``` field with a descriptive text containing the purpose of the payload. + +3. The payload MUST include a UNIX timestamp. The ```timestamp``` field is used as a nonce and a mark for the payload expiration. This field is very imporant in case the payload is compromised. + +Additional fields MAY be included in the payload. Depending on the process, it could be useful to include some aditional fields in the protected header of the signature. For example, the email information should be included in the protected header in a registration request. In that way, this payload can be used only to register that specific email and it can not be tampered. + +```JSON +{ + "url": "http://example.com/signup", + "action": "Sign up", + "timestamp": 1673261248, + ["email": "email@example.com"] <- Optional +} +``` + +### Wallet specification + +The wallets can improve the overall security implementing the folliwing guidelines. We RECOMMEND to show in a structured way the payload information for shake of clarity. This information should be well understanded by the users before the payload is singed. + +The ```url``` field provides information about the hostname of the application. This hostname MUST be included in the wallet allow list. If a known domain A tries to sign a payload for an unknown domain B, you will be prompted with permission popup making more obvious the cross-domain interaction. When possible, the wallet SHOULD warn the user if a payload is for a different domain. + +The wallet SHOULD update the ```timestamp``` field to the current time just before the signature. This field ideally should match the moment just before the signature, thereby the server recieves the more updated payload possible. + +### Server processing + +The server has ultimate responsibility of processing correctly the requests. We use the content to validate the payload. The request will be processed with the following steps: + +1. The server MUST check the action and the endpoint included in the request. Each route to an endpoint MUST have an associated action and a URL. The first step is to check that they match with the parameterized action. + +2. The server MUST check the expiration of the payload. The expiration SHOULD be enough to give time to the user to introduce the wallet password but it SHOULD NOT be too long, we RECOMMEND not more than 5 minutes. + +3. The server MUST validate the COSESign1 signature and check that the address inside the protected map of the signature corresponds to the public key in the COSEKey. + +Additionally the server COULD extract the payload content and pass it through the server logic. + +## Rationale: how does this CIP achieve its goals? + +This specification provides the general guidelines and necessary recommendations for performing secure authenticated web3 requests in the Cardano ecosystem. It covers the two main desired characteristics for a secure payload: It must expire and it must be non-static. + +Another important aspect for security is how wallets process the payload. They can improve the security using the data inside the payload to warn the users about possible malicious interactions. This specification emphasizes the importance of informing users clearly about the purpose of the payloads and how wallets can use the URL field to apply allow-lists and/or cross-domain policies. + +Finally, it establishes the requirements and recommendations for server side processing. The server must also ensure the validity of the signature and the payload, as well as of its purpose in order to accomplish the authentication. + +## Reference implementation + +* [jmagan/passport-cardano-web3](https://github.com/jmagan/passport-cardano-web3) +* [jmagan/cardano-express-web3-skeleton](https://github.com/jmagan/cardano-express-web3-skeleton) + +## Copyright + +This CIP is licensed under [CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From 71309e10724a3129a7a9e20991a7ff7750ed4430 Mon Sep 17 00:00:00 2001 From: jmagan Date: Thu, 19 Jan 2023 16:54:09 +0100 Subject: [PATCH 17/22] fix: spelling --- CIP-????/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index 1863ab9d6b..6dd3388e9d 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -62,7 +62,7 @@ Additional fields MAY be included in the payload. Depending on the process, it c ### Wallet specification -The wallets can improve the overall security implementing the folliwing guidelines. We RECOMMEND to show in a structured way the payload information for shake of clarity. This information should be well understanded by the users before the payload is singed. +The wallets can improve the overall security implementing the following guidelines. We RECOMMEND to show in a structured way the payload information for shake of clarity. This information should be well understanded by the users before the payload is signed. The ```url``` field provides information about the hostname of the application. This hostname MUST be included in the wallet allow list. If a known domain A tries to sign a payload for an unknown domain B, you will be prompted with permission popup making more obvious the cross-domain interaction. When possible, the wallet SHOULD warn the user if a payload is for a different domain. From e6cf475317a2bcbce410c1daa7d37ef4bedbbe53 Mon Sep 17 00:00:00 2001 From: Michael Peyton Jones Date: Fri, 20 Jan 2023 13:58:41 +0000 Subject: [PATCH 18/22] CIP-0035 | Update for new CIP-1 (#437) * Update CIP-35 to be more in line with the new CIP-001 * Update metadata for CIP-(31-33) * Address comments --- CIP-0031/README.md | 7 ++- CIP-0032/README.md | 7 ++- CIP-0033/README.md | 7 ++- CIP-0035/README.md | 142 +++++++++++++++++++++++---------------------- 4 files changed, 84 insertions(+), 79 deletions(-) diff --git a/CIP-0031/README.md b/CIP-0031/README.md index c252d5eb53..583b94ebae 100644 --- a/CIP-0031/README.md +++ b/CIP-0031/README.md @@ -2,10 +2,11 @@ CIP: 31 Title: Reference inputs Authors: Michael Peyton Jones -Comments-Summary: No comments -Comments-URI: +Implementors: + - Michael Peyton Jones + - Jared Corduan Status: Active -Type: Standards Track +Category: Plutus Created: 2021-11-29 License: CC-BY-4.0 --- diff --git a/CIP-0032/README.md b/CIP-0032/README.md index 873d80d4f0..743c3a00a1 100644 --- a/CIP-0032/README.md +++ b/CIP-0032/README.md @@ -2,10 +2,11 @@ CIP: 32 Title: Inline datums Authors: Michael Peyton Jones -Comments-Summary: No comments -Comments-URI: +Implementors: + - Michael Peyton Jones + - Jared Corduan Status: Active -Type: Standards Track +Category: Plutus Created: 2021-11-29 License: CC-BY-4.0 --- diff --git a/CIP-0033/README.md b/CIP-0033/README.md index f1792200b4..e5874751cf 100644 --- a/CIP-0033/README.md +++ b/CIP-0033/README.md @@ -2,10 +2,11 @@ CIP: 33 Title: Reference scripts Authors: Michael Peyton Jones -Comments-Summary: No comments -Comments-URI: +Implementors: + - Michael Peyton Jones + - Jared Corduan Status: Active -Type: Standards +Category: Plutus Created: 2021-11-29 License: CC-BY-4.0 Requires: CIP-31 diff --git a/CIP-0035/README.md b/CIP-0035/README.md index cc7234a4b7..1465311237 100644 --- a/CIP-0035/README.md +++ b/CIP-0035/README.md @@ -1,22 +1,22 @@ --- CIP: 35 -Title: Plutus Core Evolution +Title: Changes to Plutus Core Authors: Michael Peyton Jones -Comments-Summary: No comments -Comments-URI: Status: Active -Type: Process +Category: Meta Created: 2022-02-09 License: CC-BY-4.0 --- -# Evolution of Plutus Core in the Cardano ledger +# Changes to Plutus Core ## Abstract -This CIP proposes a process for proposing changes to Plutus Core, its builtins, and its interface to the Cardano ledger. +This CIP specifies a process for proposing changes to Plutus Core, its builtins, and its interface to the Cardano ledger. +It gives a taxonomy of typical changes, and explains how these changes may be made, which in some cases requires a CIP. +It introduces the 'Plutus' CIP category for tracking these. -## Motivation +## Motivation: why is this CIP necessary? The Plutus Core language, its builtins, and its interface to the ledger are all likely to evolve significantly over time. There are many reasons for this: - We may be able to increase performance, improve safety, or reduce script sizes by changing the language. @@ -41,7 +41,7 @@ For the purposes of this document, Plutus Core consists of various _language con Plutus Core has a number of builtin types, such as integers, and builtin functions, such as integer addition. Builtin functions provide access to functionality that would be difficult or expensive to implement using the basic constructs of Plutus Core, which is otherwise little more than the untyped lambda calculus. Builtin functions can operate only over builtin types or arbitrary Plutus Core terms treated opaquely. - * [ ] Builtin types come with a _size metric_ which is used by costing functions. +Builtin types come with a _size metric_ which is used by costing functions. For example, the size metric for integers returns the bit-size of the integer. The performance of Plutus Core scripts has two components: how expensive the script actually is to run (_real performance_) and how expensive we say it is to run in the ledger (_model performance_). @@ -159,17 +159,31 @@ The following table lists, for each type of change in "Types of change", what ki ## Specification -This proposal deals only with the types of change listed in "Types of change", all others are out of scope. +### Scope + +This CIP deals with the types of change listed in "Types of change". +That list aims to cover the most typical changes to Plutus Core, but it is not exhaustive. +CIPs which do not propose changes in the list but whose authors believe they significantly affect Plutus Core should nonetheless be assigned to the Plutus category. + +Additionally, there is significant overlap with the Ledger category around the ledger-script interface and the protocol parameters. +CIPs which change these parts of Cardano should generally use the Plutus category and not the Ledger category, although the Editors may ask the Ledger reviewers to comment. + +### The Plutus reviewers + +The following table gives the current set of reviewers for Plutus CIPs. + +| Name | Email | GitHub username | +|----------------------|------------------------------|-----------------| +| Michael Peyton Jones | michael.peyton-jones@iohk.io | michaelpj | ### Changes that require a CIP -This proposal recommends that some of the changes listed in "Types of change" (specified below) should: +This proposal requires that some of the changes listed in "Types of change" (specified below) should: 1. Be proposed in a CIP. 2. Go through additional process in addition to the [usual CIP process](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md). The additional process mostly takes the form of additional information that should be present in the CIP before it moves to particular stages. -As such, it is up to the CIP Editors to enforce this. The requirement to propose a change via a CIP is, as all CIPs are, advisory. In exceptional circumstances or where swift action is required, we expect that changes may still be made without following this process. @@ -178,51 +192,55 @@ In such circumstances, a retrospective CIP SHOULD be made after the fact to reco Changes that require a CIP do not have to each be in an individual CIP, they can be included in batches or in other CIPs. So, for example, a single CIP could propose multiple new builtin functions, or a CIP proposing a change to the ledger could also propose a change to the ledger-script interface. +### Processes + +All changes that require a CIP SHOULD adhere to the following generic process. + +In order to move to Proposed status: +- The Specification MUST include: + - The type of change that is being proposed. + - For changes to Plutus Core itself, a formal specification of the changes which is precise enough to update the Plutus Core specification from. +- The Acceptance Criteria MUST include: + - The external implementations are available. + - The `plutus` repository is updated with the specification of the proposal. + - The `plutus` repository is updated with an implementation of the proposal. +- The Implementation Plan MUST include: + - The type of release that the change requires. + #### Additions to the Plutus Core Builtins Proposals for additions to the set of Plutus Core builtins SHOULD be proposed in a CIP and SHOULD adhere to the following additional process. -In order to move to Proposed status, it MUST include: -- In the Specification: +In order to move to Proposed status: +- The Specification MUST include: - Names and types/kinds for the new functions or types. - A source for the implementation (e.g. a library which can be linked against); or a generic description of the functionality which is implementable in any programming language. - For new types: a precise description of the measure used for the size of a value of that type. - For new builtin functions: a costing function for the builtin function. -- In the Rationale: - - An argument for the utility of the new builtins. +- The Rationale MUST include: - If an external implementation is provided: an argument that it satisfies the following non-exhaustive list of criteria: - It is trustworthy - It always terminates - It (or its Haskell bindings) never throw any exceptions - Its behaviour is predictable (e.g. does not have worst-case behaviour with much worse performance) - Discussion of how any measures and costing functions were determined. +- The Acceptance Criteria MUST include: + - The ledger is updated to include new protocol parameters to control costing of the new builtins. + +The Rationale of a CIP should always be a clear argument for why the CIP should be adopted. +In this case we recommend including: +- An argument for the utility of the new builtins. +- Examples of real-world use cases where the new additions would be useful. +- If feasible, a comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance). -It SHOULD also include: -- In the Rationale - - Examples of real-world use cases where the new additions would be useful. - - If feasible, a comparison with an implementation using the existing features, and an argument why the builtin is preferable (e.g. better performance). - -In order to move to Active status, the following must be true: -- The external implementations MUST be available. -- The `plutus` repository MUST be updated with an implementation including costing. -- The Plutus Core specification MUST be updated to include the new builtins. -- The ledger MUST be updated to include new protocol parameters to control costing of the new builtins. -- The completion of these steps MUST be tracked in the Path to Active section. - -#### Other changes - -Proposals for other additions, removals, or changes to behaviour of any part of Plutus Core or its builtins SHOULD be proposed in a CIP and SHOULD adhere to the following additional process. - -In order to move to Active status, the following must be true: -- The `plutus` repository MUST be updated with an implementation of the proposal. -- For changes to Plutus Core itself, there MUST be a formal specification of the changes, either a sufficiently formal presentation in the CIP or a pull request to the Plutus Core specification. -- The completion of these steps MUST be tracked in the Path to Active section. +#### Protocol parameter updates -### Changes that do NOT require a CIP +Protocol parameter updates that affect Plutus Core should be proposed in the Ledger category and following its processes. +The only additional process required is review by the Plutus reviewers. -#### Performance changes and protocol parameter updates +#### Performance changes -This CIP does not propose any process for proposing these changes. +This CIP does not require any process for proposing performance changes. #### Bug fixes @@ -234,37 +252,11 @@ In this case the fix may be submitted directly to the `plutus` repository and is It must still be released as appropriate. For example, if a bug fix changes behaviour, it will have to wait for a new Plutus Core ledger language. -### Implementing and releasing changes - -This CIP does not cover the process of implementing changes. -As usual, the CIP process covers the design phase, and it is up to the implementer to ensure that their proposal is implemented, which may require additional work to meet the requirements of the maintainers of the Cardano code repositories (testing, implementation quality, approach), and so on. - -Changes can be released after their CIPs have reached Active status. -Different changes will require different releases as described in "Types of release". -This CIP does not cover the process by which changes are actually incorporated into releases after having been implemented. -In particular, there is NO assumption that a feature which requires a particular release will be included in the next such release, even after it has been implemented. - -### Plutus Core CIP registry - -Any CIP which proposes a type of change listed in "Types of change" MUST also add itself to this registry (in addition to the main registry). - -| # | Title | Type of change | Status | -|----|-------------------|-------------------------|--------| -| 31 | Reference inputs | Ledger-script interface | Active | -| 32 | Inline datums | Ledger-script interface | Active | -| 33 | Reference scripts | Ledger-script interface | Active | - -## Rationale - -### Why have a public process for changes? +#### Other changes -Cardano is continuing to move towards decentralized governance within the Voltaire phase of development. -Historically, key development and implementation decisions have been made by the core development team. -This was important in the earliest stages of the platform’s evolution. -However, this becomes less so as the platform starts to mature and is neither sustainable nor desirable in the long term. +Proposals for other additions, removals, or changes to behaviour of any part of Plutus Core or its builtins SHOULD be proposed in a CIP. -Furthermore, while many changes to Cardano are obscure or not of interest to many community members, there is a much larger community who have a keen interest in changes to Plutus Core: dApp developers. -Hence it is especially important to have a clear way for this community to be able to propose changes and see how they are progressing. +## Rationale: how does this CIP achieve its goals? ### Do removals and changes really need a new ledger language? @@ -332,8 +324,18 @@ Each one must continue to work, perfectly, in perpetuity. Furthermore, they may So it is very desirable to keep the number of ledger languages down. The simplest way to do this is to batch changes, and only release a new ledger language occasionally. -### Why include a CIP registry? +## Path to Active + +### Acceptance Criteria + +This CIP requires the acceptance of the Plutus team, which it has in virtue of its authorship. + +### Implementation Plan + +No implementation is required. + +## Copyright -This is just to make it easy for those considering proposing a CIP following this process to see which CIPs have already been submitted. -An alternative would be a standard title for CIPs, or perhaps some kind of CIP metadata to indicate that it follows the process in this CIP. +This CIP is licensed under [CC-BY-4.0][]. +[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode From a98b5fae27da789c9cddb79aa5ddeb79d2f387a0 Mon Sep 17 00:00:00 2001 From: Ryan Williams <44342099+Ryun1@users.noreply.github.com> Date: Fri, 20 Jan 2023 13:59:25 +0000 Subject: [PATCH 19/22] CIP-0036 | Change reward address field for Fund 10 (#373) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Stressed payment address for reward payments * Adjusted wording and started with test vectors * Reset changes to test vectors * Added test vectors * Typos + added public gov key to test vectors * Missed comma * Update CIP-0036/README.md Co-authored-by: Ján Mazák <42575685+janmazak@users.noreply.github.com> * Update CIP-0036/README.md Co-authored-by: Ján Mazák <42575685+janmazak@users.noreply.github.com> * Removed cardano-cli specific notation from test vectors, just leaving CBOR hex * Renamed rewards_address field to payment_address * Addressed @KtorZ comments Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> Co-authored-by: Ján Mazák <42575685+janmazak@users.noreply.github.com> --- CIP-0036/README.md | 14 ++-- CIP-0036/schema.cddl | 4 +- CIP-0036/test-vector.md | 144 ++++++++++++++++++++++++---------------- 3 files changed, 96 insertions(+), 66 deletions(-) diff --git a/CIP-0036/README.md b/CIP-0036/README.md index 292d2a67ac..d156ab8a78 100644 --- a/CIP-0036/README.md +++ b/CIP-0036/README.md @@ -26,7 +26,7 @@ We therefore need a registration transaction that serves three purposes: 1. Registers a "voting key" to be included in the sidechain and/or delegates to existing "voting key"s 2. Associates mainnet ADA to this voting key(s) -3. Declares an address to receive Catalyst rewards +3. Declares a payment address to receive Catalyst rewards Note: This schema does not attempt to differentiate delegations from direct registrations, as the two options have exactly the same format. It also does not distinguish between delegations that are made as "private" arrangements (proxy votes) @@ -43,7 +43,7 @@ A registration transaction is a regular Cardano transaction with a specific tran Notably, there should be five entries inside the metadata map: - A non-empty array of delegations, as described below; - A stake address for the network that this transaction is submitted to (to point to the Ada that is being delegated); - - A Shelley address discriminated for the same network this transaction is submitted to to receive rewards. + - A Shelley payment address (see [CIP-0019](https://github.com/cardano-foundation/CIPs/tree/master/CIP-0019)) discriminated for the same network this transaction is submitted to, to receive rewards. - A nonce that identifies that most recent delegation - A non-negative integer that indicates the purpose of the vote. This is an optional field to allow for compatibility with CIP-15. For now, we define 0 as the value to use for Catalyst, and leave others for future use. A new registration should not invalidate a previous one with a different voting purpose value. @@ -121,7 +121,7 @@ Voting registration example: 1: [["0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663", 1], ["0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee", 3]], // stake_pub - CBOR byte array 2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee", - // reward_address - CBOR byte array + // payment_address - CBOR byte array 3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4", // nonce 4: 5479467 @@ -130,7 +130,7 @@ Voting registration example: } ``` The entries under keys 1, 2, 3, 4 and 5 represent the Catalyst delegation array, -the staking credential on the Cardano network, the address to receive rewards, +the staking credential on the Cardano network, the payment address to receive rewards, a nonce, and a voting purpose, respectively. A registration with these metadata will be considered valid if the following conditions hold: @@ -139,7 +139,7 @@ considered valid if the following conditions hold: The advised way to construct a nonce is to use the current slot number. This is a simple way to keep the nonce increasing without having to access the previous transaction data. -- The reward address is a Shelley address discriminated for the same network +- The payment address is a Shelley payment address discriminated for the same network this transaction is submitted to. - The delegation array is not empty - The weights in the delegation array are not all zero @@ -259,6 +259,10 @@ Fund 8: - added the `voting_purpose` field to limit the scope of the delegations. - rename the `staking_pub_key` field to `stake_credential` and `registration_signature` to `registration_witness` to allow for future credentials additions. +Fund 10: +- Replaced the `reward_address` field with `payment_address` field, keeping it at index 3. Stipulating that `payment_address` must be a Shelley payment address, otherwise voting reward payments will not be received. + - **Note:** up to Catalyst's Fund 9, voting rewards were paid via MIR transfer to a stake address provided within the `reward_address` field. From Fund 10 onwards, a regular payment address must be provided in the `payment_address` field to receive voting rewards. This allows Catalyst to avoid MIR transfers and instead pay voting rewards via regular transactions. + Fund 11: - added the `deregistration` metadata format. diff --git a/CIP-0036/schema.cddl b/CIP-0036/schema.cddl index 1f0bf2c975..246c483ef9 100644 --- a/CIP-0036/schema.cddl +++ b/CIP-0036/schema.cddl @@ -4,7 +4,7 @@ registration_cbor = { } $voting_pub_key /= bytes .size 32 -$reward_address /= bytes +$payment_address /= bytes $nonce /= uint $weight /= uint .size 4 $voting_purpose /= uint @@ -27,7 +27,7 @@ $ed25519_signature /= bytes .size 64 key_registration = { 1 : [+delegation] / legacy_key_registration, 2 : $stake_credential, - 3 : $reward_address, + 3 : $payment_address, 4 : $nonce, ? 5 : $voting_purpose .default 0 } diff --git a/CIP-0036/test-vector.md b/CIP-0036/test-vector.md index add73c5475..e9b8ebbb29 100644 --- a/CIP-0036/test-vector.md +++ b/CIP-0036/test-vector.md @@ -1,110 +1,136 @@ -# Test vector for CIP36 +# Test Vector for CIP-0036 -### Inputs +## Keys -Payment **public** key hex +**Note:** Not all keys are required for certificate recreation. + +Payment **private** signing key Hex: +``` +614fdfe13d403bee2014570b190d81851f17d8daca0b6dd1ce33014403191003 +``` + +Payment **public** verification Hex: +``` +7a24dd8e692cec94b612c2ec81f508aada96557c2052a447b9d197b006fa7d2a +``` + +Staking **private** signing key Hex: +``` +852fa5d17df3efdfdcd6dac53ec9fe5593f3c0bd7cadb3c2af76c7e15dfa8a5c +``` + +Staking **public** verification key Hex: ``` -3273a5316e4de228863bd7cf8dac90d57149e1a595f3dd131073b84e35546676 +e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369 ``` -Staking **private** key hex +CIP-36 Vote **public** verification key Hex: ``` -f5beaeff7932a4164d270afde7716067582412e8977e67986cd9b456fc082e3a +0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0 ``` -Catalyst **private** key hex +CIP-36 Vote **extended private** signing key Hex: ``` 4820f7ce221e177c8eae2b2ee5c1f1581a0d88ca5c14329d8f2389e77a465655c27662621bfb99cb9445bf8114cc2a630afd2dd53bc88c08c5f2aed8e9c7cb89 ``` -### Intermediate steps +## Addresses +- This example uses Pre-Production testnet (testnet-magic 1). -Reward address generated from staking key +Payment Address: ``` -bech32 -stake_test1uzhr5zn6akj2affzua8ylcm8t872spuf5cf6tzjrvnmwemcehgcjm +bech32: "addr_test1qprhw4s70k0vzyhvxp6h97hvrtlkrlcvlmtgmaxdtjz87xrjkctk27ypuv9dzlzxusqse89naweygpjn5dxnygvus05sdq9h07" -hex-encoded -e0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef +hex-encoded: "004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9" +```` + +Staking Address: +``` +bech32: "stake_test1upetv9m90zq7xzk303rwgqgvnje7hvjyqef6xnfjyxwg86gzpmj80" + +hex-encoded: "e072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9" ``` -Data to sign (human readable format) +## Certificate Example + +- Assigning all voting power to a single voting key. + +### Human Readable Format -Legacy version (full delegation to one key only): +Legacy CIP-15 version: ```javascript -61284: { - 1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', - 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', - 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', - 4: 1234, -}, +"61284": { + "1": "0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", + "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", + "3": "0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", + "4": 1234 +} ``` -New version: +CIP-36 version: ```javascript -61284: { - 1: [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]], - 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', - 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', - 4: 1234, - 5: 0 -}, +"61284": { + "1": [["0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", 1]], + "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", + "3": "0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", + "4": 1234, + "5": 0 +} ``` +### CBOR Encoding -Metadata (CBOR encoding) - -Legacy: +Legacy CIP-15 version: ``` -a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2 +a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e43236903581de072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d2 ``` -New: +CIP-36 version: ``` -a119ef64a50182825820a6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d16630182582000588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee0302582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d20500 +a119ef64a501818258200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a001025820e3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369035839004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9041904d20500 ``` -Blake2b-256 hash of metadata +### Blake2b-256 Hash -Legacy: +Legacy CIP-15 version: ``` -a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f +9946e71b5f6c16150cf431910a0f7dbb8084a992577847802e60d32becb3d6be ``` -New: +CIP-36 version: ``` -5bc0681f173efd76e1989037a3694b8a7abea22053f5940cbb5cfcdf721007d7 +3110fbad72589a80de7fc174310e92dac35bbfece1690c2dce53c2235a9776fa ``` -### Output +## Metadata Example with Witness -Legacy: +Legacy CIP-15 version: ```javascript { - 61284: { - 1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', - 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', - 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', - 4: 1234, + "61284": { + "1": "0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", + "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", + "3": "0xe072b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", + "4": 1234 }, - 61285: { - 1: '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e' + "61285": { + "1": "0xa9ec8735804c6c4c5c4a02e9589c65508ec7060063b2d7dbeba82d1cbfa1b8be6b457f95d4ead5e8b454b989624fa44e0b89a64d089fdc0a6a1268fef4876d0f" } } ``` -New: +CIP-36 version: ```javascript { - 61284: { - 1: [['0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663', 1], ['0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee', 3]], - 2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e', - 3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef', - 4: 1234, - 5: 0 + "61284": { + "1": [["0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0", 1]], + "2": "0xe3cd2404c84de65f96918f18d5b445bcb933a7cda18eeded7945dd191e432369", + "3": "0x004777561e7d9ec112ec307572faec1aff61ff0cfed68df4cd5c847f1872b617657881e30ad17c46e4010c9cb3ebb2440653a34d32219c83e9", + "4": 1234, + "5": 0 }, - 61285: { - 1: '0x3aaa2e6b43c0a96e880a7d70df84dffb2a1a17b19d7a99a6ed27b91d499b32027c43acfbf6dff097af7634b2ee38c8039af259b0b6a64316f02b4ffee28a0608' + "61285": { + "1": "0xcbb96ba1596fafc18eec84e306feea3067ba1c6ace95b11af820bcbd53837ef32bdcf28176749061e1f2a1300d4df98c80582722786e40cf330072d0b78a7408" } } -``` +``` \ No newline at end of file From 705523e13f946939cbeb1e173c5b3327db7321d8 Mon Sep 17 00:00:00 2001 From: jmagan Date: Tue, 24 Jan 2023 21:48:29 +0100 Subject: [PATCH 20/22] fix: Implementation plan indention feat: Path to active --- CIP-????/README.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index 6dd3388e9d..09f79d12f3 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -88,10 +88,30 @@ Another important aspect for security is how wallets process the payload. They c Finally, it establishes the requirements and recommendations for server side processing. The server must also ensure the validity of the signature and the payload, as well as of its purpose in order to accomplish the authentication. -## Reference implementation + +### Reference implementation * [jmagan/passport-cardano-web3](https://github.com/jmagan/passport-cardano-web3) * [jmagan/cardano-express-web3-skeleton](https://github.com/jmagan/cardano-express-web3-skeleton) +## Path to Active + +### Acceptance Criteria + +- [X] At least one library should implement this authentication method. +- [ ] The 80% users should have wallets implementing the following requirements: + 1. It MUST detect when the payload is formatted using this specification. + 2. The information contained in the payload MUST be parsed and formatted in the signing pop-up. + 3. The wallet SHOULD update the timestamp just before the payload is signed. + 4. The wallet MUST detect if the URL is in the allow list. + 5. The wallet SHOULD warn the user against cross-domain requests. +- [ ] A detailed documentation about web3 standards should be published. This documentation will include this standard and further best practices for web3 technologies. + +### Implementation Plan + +- [X] Create a library for processing payload according to this specification. +- [ ] Open a conversation about this specification and its possible improvements. +- [ ] Talk about further web3 standards and new specifications. +- [ ] Write the documentation for web3 developers. ## Copyright From 2c655e2d34507de013341725e1b59151fc8a5980 Mon Sep 17 00:00:00 2001 From: jmagan Date: Tue, 28 Feb 2023 16:39:46 +0100 Subject: [PATCH 21/22] Next JS reference implementation --- CIP-????/README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CIP-????/README.md b/CIP-????/README.md index 09f79d12f3..143a42a5a8 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -93,6 +93,7 @@ Finally, it establishes the requirements and recommendations for server side pro * [jmagan/passport-cardano-web3](https://github.com/jmagan/passport-cardano-web3) * [jmagan/cardano-express-web3-skeleton](https://github.com/jmagan/cardano-express-web3-skeleton) +* [jmagan/cardano-nextjs-web3-skeleton](https://github.com/jmagan/cardano-nextjs-web3-skeleton) ## Path to Active ### Acceptance Criteria From 760afaa30b6301beec544ac67eeeebc4e25e5e86 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Salvador=20Mag=C3=A1n=20Valero?= Date: Tue, 4 Apr 2023 17:46:58 +0200 Subject: [PATCH 22/22] Apply suggestions from code review Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> --- CIP-????/README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/CIP-????/README.md b/CIP-????/README.md index 143a42a5a8..20bc823de0 100644 --- a/CIP-????/README.md +++ b/CIP-????/README.md @@ -16,7 +16,7 @@ License: CC-BY-4.0 ## Abstract -The cardano wallets have the ability to sign arbitrary pieces of data as we can see in the [Message signing CIP-0008](/CIP-0008/README.md). All wallets implement the method ```api.signData(addr: Address, payload: Bytes): Promise``` defined in [Cardano dApp-Wallet Web Bridge CIP-0030](/CIP-0030/README.md). +The cardano wallets have the ability to sign arbitrary pieces of data as we can see in the [Message signing CIP-0008](../CIP-0008). All wallets implement the method ```api.signData(addr: Address, payload: Bytes): Promise``` defined in [Cardano dApp-Wallet Web Bridge CIP-0030](../CIP-0030). An important use case for web3 sites is calling HTTP endpoints using authenticated requests signed by the private keys of the users' wallets. In this way, the servers can perform actions using onchain and offchain data. @@ -27,7 +27,7 @@ dApps generate arbritary payloads as byte arrays. These payloads are signed and The current implementations for web3 applications use static strings. This is dangerous because if a bad actor intercepts the signed message then it can be used in a replay attack by the bad actor. That's why it is very important to produce a dynamic payload rather a static string. -Another problem with the current approach is how the wallets show the information contained in the payload. The payload is a enconded byte array and it could contain anything. If Alice want to call an endpoint and Bob has the ability to change the message before Alice gets it. Alice must be notified somehow that she is signing a potentially malicious payload. A simple hex-encoded representation of the payload isn't enough to ensure a safe interaction. +Another problem with the current approach is how the wallets show the information contained in the payload. The payload is a encoded byte array and it could contain anything. If Alice want to call an endpoint and Bob has the ability to change the message before Alice gets it. Alice must be notified somehow that she is signing a potentially malicious payload. A simple hex-encoded representation of the payload isn't enough to ensure a safe interaction. ## Specification @@ -43,11 +43,11 @@ The payload MUST be encoded as a JSON string. JSON strings are semi-structured d The content of the payload will be included in the protected header of the COSESign1 signature, hence the content effects directly the behavior and security of the system. The payload MUST have the following fields: -1. The field ```url``` MUST contain the full path to the endpoint, where the payload will be processed. +1. The field `url` MUST contain the full path to the endpoint, where the payload will be processed. -2. Sometimes, the endpoint ```url``` field is not enough to determine its purpose. The user should understand perfectly the objective of the payload which he or she is signing. That's why the payload MUST contain an ```action``` field with a descriptive text containing the purpose of the payload. +2. Sometimes, the endpoint `url` field is not enough to determine its purpose. The user should understand perfectly the objective of the payload which he or she is signing. That's why the payload MUST contain an `action` field with a descriptive text containing the purpose of the payload. -3. The payload MUST include a UNIX timestamp. The ```timestamp``` field is used as a nonce and a mark for the payload expiration. This field is very imporant in case the payload is compromised. +3. The payload MUST include a UNIX timestamp. The `timestamp` field is used as a nonce and a mark for the payload expiration. This field is very important in case the payload is compromised. Additional fields MAY be included in the payload. Depending on the process, it could be useful to include some aditional fields in the protected header of the signature. For example, the email information should be included in the protected header in a registration request. In that way, this payload can be used only to register that specific email and it can not be tampered. @@ -62,11 +62,11 @@ Additional fields MAY be included in the payload. Depending on the process, it c ### Wallet specification -The wallets can improve the overall security implementing the following guidelines. We RECOMMEND to show in a structured way the payload information for shake of clarity. This information should be well understanded by the users before the payload is signed. +The wallets can improve the overall security implementing the following guidelines. We RECOMMEND to show in a structured way the payload information for sake of clarity. This information should be well understood by the users before the payload is signed. -The ```url``` field provides information about the hostname of the application. This hostname MUST be included in the wallet allow list. If a known domain A tries to sign a payload for an unknown domain B, you will be prompted with permission popup making more obvious the cross-domain interaction. When possible, the wallet SHOULD warn the user if a payload is for a different domain. +The `url` field provides information about the hostname of the application. This hostname MUST be included in the wallet allow list. If a known domain A tries to sign a payload for an unknown domain B, you will be prompted with permission popup making more obvious the cross-domain interaction. When possible, the wallet SHOULD warn the user if a payload is for a different domain. -The wallet SHOULD update the ```timestamp``` field to the current time just before the signature. This field ideally should match the moment just before the signature, thereby the server recieves the more updated payload possible. +The wallet SHOULD update the `timestamp` field to the current time just before the signature. This field ideally should match the moment just before the signature such that the server receives fresh payload. ### Server processing