Merge branch 'cardano-foundation:master' into master

CIP-0001/README.md

@@ -187,14 +187,13 @@ CIPs may include auxiliary files such as diagrams. Auxiliary files should be inc
 CIP editors serve as stewards of the Cardano ecosystem, here to support and progress CIPs in their various stages within the community and protocol. If you have questions regarding the CIP process, they can point you in the right direction. They provide support for users trying to create a CIP, monitor that the CIP process is fair, formalized, objective, and to facilitate knowledge transfer through the CIPs themselves.
 
 
-Frederic Johnson - @crptmppt 
-
-Matthias Benkort - @KtoZ 
-
-Sebastien Guillemot - @SebastienGllmt
-
-Duncan Coutts - @dcoutts 
+| Frederic Johnson <br/> [@crptmppt][] | Matthias Benkort <br/> [@KtorZ][] | Sebastien Guillemot <br/> [@SebastienGllmt][] | Robert Phair <br/> [@rphair][] |
+| ---                                  | ---                               | ---                                           | ---                            |
 
+[@crptmppt]: https://github.com/crptmppt
+[@KtorZ]: https://github.com/KtorZ
+[@SebastienGllmt]: https://github.com/SebastienGllmt
+[@rphair]: https://github.com/rphair
 
 CIP editors should strive to keep up to date with general technical conversations and Cardano proposals. For each new draft proposal submitted in <https://forum.cardano.org/c/developers/cips/122>, an editor might review it as follows:
 

CIP-0005/README.md

@@ -43,6 +43,8 @@ We define the following set of common prefixes with their corresponding semantic
 | `addr_shared_vk`   | CIP-1854's address verification key                | Ed25519 public key                 |
 | `addr_shared_xsk`  | CIP-1854's address extended signing key            | Ed25519-bip32 extended private key |
 | `addr_shared_xvk`  | CIP-1854's address extended verification key       | Ed25519 public key with chain code |
+| `gov_sk`           | Governance vote signing key                        | Ed25519 private key                |
+| `gov_vk`           | Governance 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                |

CIP-0010/registry.json

@@ -7,6 +7,10 @@
     "transaction_metadatum_label": 88,
     "description": "milkomeda.com - the destination address in the sidechain"
   },
+  {
+    "transaction_metadatum_label": 123,
+    "description": "shareslake.com - Bridge routing information"
+  },
   {
     "transaction_metadatum_label": 309,
     "description": "Proof of Existence record"
@@ -23,6 +27,10 @@
     "transaction_metadatum_label": 777,
     "description": "CIP-0027 - Royalties Standard"
   },
+  {
+    "transaction_metadatum_label": 888,
+    "description": "finitum.io token bridge transactions metadata"
+  },
   {
     "transaction_metadatum_label": 1188,
     "description": "paradiso.app marketplace metadata"
@@ -35,6 +43,10 @@
     "transaction_metadatum_label": 1870,
     "description": "Open Badges v2.0 compliant metadata"
   },
+  {
+    "transaction_metadatum_label": 1888,
+    "description": "amphitheatre by the ape society"
+  },
   {
     "transaction_metadatum_label": 1967,
     "description": "nut.link metadata oracles registry"
@@ -61,10 +73,10 @@
   },
   {
     "transaction_metadatum_label": 61285,
-    "description": "CIP-0015 - Catalyst registration"
+    "description": "CIP-0015 - Catalyst witness"
   },
   {
     "transaction_metadatum_label": 61286,
-    "description": "CIP-0015 - Catalyst registration"
+    "description": "CIP-0015 - Catalyst deregistration"
   }
 ]

CIP-0011/README.md

@@ -11,7 +11,7 @@ License: CC-BY-4.0
 
 ## Abstract
 
-Starting with the Shelley hardfork, Cardano makes use of both the *UTXO model* and the *account model*. To support both transaction models from the same master key, we allocate a new chain for [CIP1852](../CIP-1852)
+Starting with the Shelley hardfork, Cardano makes use of both the *UTXO model* and the *account model*. To support both transaction models from the same master key, we allocate a new chain for [CIP1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md)
 
 ## Terminology
 
@@ -36,7 +36,7 @@ Generally it's best to only use a cryptographic key for a single purpose, and so
 
 ## Specification
 
-Recall that [CIP1852](../CIP-1852) specifies the following derivation path
+Recall that [CIP1852](https://github.com/cardano-foundation/CIPs/blob/master/CIP-1852/README.md) specifies the following derivation path
 
 ```
 m / purpose' / coin_type' / account' / chain / address_index
@@ -71,4 +71,4 @@ stake1uy8ykk8dzmeqxm05znz65nhr80m0k3gxnjvdngf8azh6sjc6hyh36
 
 ## Copyright
 
-This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)
+This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)

CIP-0015/test-vector.md

@@ -30,11 +30,11 @@ e0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef
 
 Data to sign (human readable format)
 ```javascript
-'61284': {
-  '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
-  '2': '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
-  '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-  '4': 1234,
+61284: {
+  1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
+  2: '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
+  3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+  4: 1234,
 },
 ```
 
@@ -52,14 +52,14 @@ a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f
 
 ```javascript
 {
-  '61284': {
-    '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
-    '2': '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
-    '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-    '4': 1234
+  61284: {
+    1: '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
+    2: '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
+    3: '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
+    4: 1234
   },
-  '61285': {
-    '1': '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e'
+  61285: {
+    1: '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e'
   }
 }
 ```

CIP-0021/README.md

@@ -2,8 +2,8 @@
 CIP: 21
 Title: Transaction requirements for interoperability with hardware wallets
 Authors: Gabriel Kerekes <gabriel.kerekes@vacuumlabs.com>, Rafael Korbas <rafael.korbas@vacuumlabs.com>, Jan Mazak <jan.mazak@vacuumlabs.com>
-Status: Draft
-Type: Standards
+Status: Active
+Type: Informational
 Created: 2021-06-15
 License: CC-BY-4.0
 ---
@@ -63,6 +63,7 @@ The number of the following transaction elements individually must not exceed `U
 - withdrawals in transaction body
 - collateral inputs in transaction body
 - required signers in transaction body
+- reference inputs in transaction body
 - the total number of witnesses
 
 **Optional empty lists and maps**
@@ -71,7 +72,15 @@ Unless mentioned otherwise in this CIP, optional empty lists and maps must not b
 
 **Outputs**
 
-Outputs containing no multi-asset tokens must be serialized as a simple tuple, i.e. `[address, coin, ?datum_hash]` instead of `[address, [coin, {}], ?datum_hash]`. In addition, including `datum_hash` is only allowed if the payment part of the output's `address` is a script hash.
+A new, "post Alonzo", output format has been introduced in the Babbage era which uses a map instead of an array to store the output data. For now, both the "legacy" (array) and "post Alonzo" (map) output formats are supported by HW wallets but we encourage everyone to migrate to the "post Alonzo" format as support for the "legacy" output format might be removed in the future. Both formats can be mixed within a single transaction, both in outputs and in the collateral return output.
+
+_Legacy outputs_
+
+Outputs containing no multi-asset tokens must be serialized as a simple tuple, i.e. `[address, coin, ?datum_hash]` instead of `[address, [coin, {}], ?datum_hash]`.
+
+_Post Alonzo outputs_
+
+If the `data` of `datum_option` is included in an output, it must not be empty. `script_ref` (reference script) must also not be empty if it is included in an output.
 
 **Multiassets**
 
@@ -149,6 +158,10 @@ The specified auxiliary data format was chosen in order to be compatible with ot
 
 Tools interacting with HW wallets might need to be updated in order to continue being compatible with HW wallets because of canonical CBOR serialization format, which is being enforced since multi-sig support.
 
+## Tools
+
+[`cardano-hw-interop-library`](https://github.com/vacuumlabs/cardano-hw-interop-lib) or [`cardano-hw-cli'](https://github.com/vacuumlabs/cardano-hw-cli) (which uses the interop library) can be used to validate or transform transactions into a HW wallet compatible format if possible.
+
 ## Copyright
 
 This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)

CIP-0025/README.md

@@ -1,6 +1,6 @@
 ---
 CIP: 25
-Title: NFT Metadata Standard
+Title: Media NFT Metadata Standard
 Authors: Alessandro Konrad <alessandro.konrad@live.de>, Smaug <smaug@pool.pm>
 Comments-URI:
 Status: Active
@@ -12,7 +12,7 @@ License: CC-BY-4.0
 
 ## Abstract
 
-This proposal defines an NFT Metadata Standard for Native Tokens.
+This proposal defines an Media NFT Metadata Standard for Native Tokens.
 
 ## Motivation
 
@@ -78,7 +78,19 @@ The structure allows for multiple token mints, also with different policies, in
 
 - In version `1` the **`policy_id`** must be in text format for the key in the metadata map. In version `2` the the raw bytes of the **`policy_id`** are used.
 
-- The **`image`** and **`name`** property are marked as required. **`image`** should be an URI pointing to a resource with mime type `image/*` used as thumbnail or as actual link if the NFT is an image (ideally <= 1MB).
+- The  **`name`** property is marked as required.
+- The **`image`** property is required and must be a valid [Uniform Resource Identifier (URI)](https://www.rfc-editor.org/rfc/rfc3986) pointing to a resource with mime type `image/*`.  Note that this resource is used as thumbnail or the actual link if the NFT is an image (ideally <= 1MB). If the string representing the resource location is >64 characters, an array may be used in place of a simple JSON string type, which viewers will automatically concatenate to create a single URI.
+	- Please note that if distributed storage systems like IPFS or Arweave are used it is required to use a URI containing the respective scheme (e.g., `ipfs://` or `ar://`) and not merely the content identifier (CID) as NFT viewers may not be able to locate the file.
+		- Valid identifiers would include:
+			- `"https://cardano.org/favicon-32x32.png"`
+			- `"ipfs://QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"`
+			- `["ipfs://", "QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"]`
+		- Invalid identifiers would include:
+			- `"cardano.org/favicon-32x32.png"`
+			- `"QmbQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"`
+			- `["Qm", "bQDvKJeo2NgGcGdnUiUFibTzuKNK5Uij7jzmK8ZccmWp"]`
+	-  If an inline base64-encoded image will be used, the data must be prepended with a valid `data:<mime_type>;base64` prefix as specified by the [data URL scheme standard](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs) to indicate the image is an inline data object
+	- See [the OpenSea "IPFS and Arweave URIs" section in their reference guide](https://docs.opensea.io/docs/metadata-standards#ipfs-and-arweave-uris) for more helpful information on the topic.
 
 - The **`description`** property is optional.
 

CIP-0026/README.md

@@ -315,7 +315,7 @@ The metadata server SHOULD implement the following HTTP methods:
 GET /metadata/{subject}/property/{property name}
 ```
 
-This SHOULD return the property value for the given property name (if any) associated with the subject. This is returned as a single-entry JSON object whose key is the property name and return the complete JSON entry for that subject+name (including `value`, `sequenceNumber` and `signatures`).
+This SHOULD return the property values for the given property name (if any) associated with the subject. This is returned as a array of JSON objects whose key is the property name and return the complete JSON entries for that subject+name (including `value`, `sequenceNumber` and `signatures`).
 
 The metadata server SHOULD set the Content-Length header to allow clients to decide if they wish to download sizeable metadata.
 
@@ -329,7 +329,7 @@ This SHOULD return all the property names which are available for that subject (
 GET /metadata/{subject}
 ```
 
-This SHOULD return the full metadata object associated with this subject, including the subject and all properties associated with it. 
+This SHOULD return a array of the full metadata objects associated with this subject, including the subject and all properties associated with it. 
 
 ```
 POST /metadata/query

CIP-0030/README.md

@@ -30,15 +30,15 @@ The API specified in this document will count as version 0.1.0 for version-check
 
 ### Address
 
-A string represnting an address in either bech32 format, or hex-encoded bytes. All return types containing `Address` must return the bech32 format, but must accept either format for inputs.
+A string representing an address in either bech32 format, or hex-encoded bytes. All return types containing `Address` must return the bech32 format, but must accept either format for inputs.
 
 ### Bytes
 
 A hex-encoded string of the corresponding bytes.
 
 ### cbor\<T>
 
-A hex-encoded string representing [CBOR](https://tools.ietf.org/html/rfc7049) corresponding to `T` defined via [CDDL](https://tools.ietf.org/html/rfc8610) either inside of the [Shelley Mult-asset binary spec](https://github.com/input-output-hk/cardano-ledger-specs/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl) or, if not present there, from the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/CIP-0008.md).
+A hex-encoded string representing [CBOR](https://tools.ietf.org/html/rfc7049) corresponding to `T` defined via [CDDL](https://tools.ietf.org/html/rfc8610) either inside of the [Shelley Multi-asset binary spec](https://github.com/input-output-hk/cardano-ledger-specs/blob/0738804155245062f05e2f355fadd1d16f04cd56/shelley-ma/shelley-ma-test/cddl-files/shelley-ma.cddl) or, if not present there, from the [CIP-0008 signing spec](https://github.com/cardano-foundation/CIPs/blob/master/CIP-0008/CIP-0008.md).
 This representation was chosen when possible as it is consistent across the Cardano ecosystem and widely used by other tools, such as [cardano-serialization-lib](https://github.com/Emurgo/cardano-serialization-lib), which has support to encode every type in the binary spec as CBOR bytes.
 
 ### DataSignature
@@ -223,7 +223,7 @@ This shall return a list of one or more UTXOs (unspent transaction outputs) cont
 
 The main point is to allow the wallet to encapsulate all the logic required to handle, maintain, and create (possibly on-demand) the UTXOs suitable for collateral inputs. For example, whenever attempting to create a plutus-input transaction the dapp might encounter a case when the set of all user UTXOs don't have any pure entries at all, which are required for the collateral, in which case the dapp itself is forced to try and handle the creation of the suitable entries by itself. If a wallet implements this function it allows the dapp to not care whether the suitable utxos exist among all utxos, or whether they have been stored in a separate address chain (see https://github.com/cardano-foundation/CIPs/pull/104), or whether they have to be created at the moment on-demand - the wallet guarantees that the dapp will receive enough utxos to cover the requested amount, or get an error in case it is technically impossible to get collateral in the wallet (e.g. user does not have enough ADA at all).
 
-The `amount` parameter is required, specified as a `string` (BigNumber) or a `number`, and the maximum allowed value must be agreed to be something like 5 ADA. Not limiting the maximum possible value might force the wallet to attempt to purify an unreasonable amount of ADA just because the dapp is doing something weird. Since by protocol the required collateral amount is always a percentage of the transaction fee, it seems that the 5 ADA limit should be enough for the foreseable future.
+The `amount` parameter is required, specified as a `string` (BigNumber) or a `number`, and the maximum allowed value must be agreed to be something like 5 ADA. Not limiting the maximum possible value might force the wallet to attempt to purify an unreasonable amount of ADA just because the dapp is doing something weird. Since by protocol the required collateral amount is always a percentage of the transaction fee, it seems that the 5 ADA limit should be enough for the foreseeable future.
 
 ### api.getBalance(): Promise\<cbor\<value>>