Rework CIP-0005's headers and sections + remove h1 headers from vario…

…us CIPs (#453)

* Rework CIP-0005's headers and sections according to new CIP-0001

* Remove h1 header from template and CIPs.

.github/CIP-TEMPLATE.md

@@ -26,9 +26,6 @@ License: CC-BY-4.0
 
 -->
 
-# CIP-XXXX: Title
-<!-- A reminder of the document's number & title, for readability. -->
-
 ## Abstract
 <!-- A short (\~200 word) description of the proposed solution and the technical issue being addressed. -->
 

.github/CPS-TEMPLATE.md

@@ -25,9 +25,6 @@ Created: YYYY-MM-DD
 
 -->
 
-# CPS-XXXX: Title
-<!-- A reminder of the document's number & title, for readability. -->
-
 ## Abstract
 <!-- A short (\~200 word) description of the target goals and the technical obstacles to those goals. -->
 

CIP-0001/README.md

@@ -18,8 +18,6 @@ Created: 2020-03-21
 License: CC-BY-4.0
 ---
 
-# CIP-0001: Cardano Improvement Proposals
-
 ## Abstract
 
 A Cardano Improvement Proposal (CIP) is a formalised design document for the Cardano community and the name of the process by which such documents are produced and listed. A CIP  provides information or describes a change to the Cardano ecosystem, processes, or environment concisely and in sufficient technical detail. In this CIP, we explain what a CIP is; how the CIP process functions; the role of the CIP Editors; and how users should go about proposing, discussing and structuring a CIP.

CIP-0002/README.md

@@ -13,8 +13,6 @@ Created: 2020-05-04
 License: CC-BY-4.0
 ---
 
-# CIP-0002: Coin Selection Algorithms for Cardano
-
 ## Abstract
 
 This article describes, in _human-readable terms_, the coin selection

CIP-0003/README.md

@@ -18,8 +18,6 @@ Created: 2020-05-07
 License: CC-BY-4.0
 ---
 
-# CIP-0003: Wallet Key Generation
-
 ## Abstract
 
 Many wallets utilize some way of mapping a sentence of words (easy to read and write for humans) uniquely back and forth to a sized binary data (harder to remember).

CIP-0004/README.md

@@ -16,8 +16,6 @@ Created: 2019-05-01
 License: Apache-2.0
 ---
 
-# CIP-0004: Wallet Checksums
-
 ## Abstract
 
 We introduce a checksum algorithm to help users verify they are restoring the right wallet before the restoration actually takes place.

CIP-0005/README.md

@@ -1,10 +1,18 @@
 ---
 CIP: 5
 Title: Common Bech32 Prefixes
-Authors: Matthias Benkort <[email protected]>
-Comments-URI: https://forum.cardano.org/t/cip5-common-bech32-prefixes/35189
+Category: Tools
 Status: Active
-Type: Standards
+Authors:
+  - Matthias Benkort <[email protected]>
+Implementors: N/A
+Discussions:
+  - https://forum.cardano.org/t/cip5-common-bech32-prefixes/35189
+  - https://github.com/cardano-foundation/CIPs/pull/427
+  - https://github.com/cardano-foundation/CIPs/pull/342
+  - https://github.com/cardano-foundation/CIPs/pull/251
+  - https://github.com/cardano-foundation/CIPs/pull/177
+  - https://github.com/cardano-foundation/CIPs/pull/31
 Created: 2020-05-28
 License: Apache-2.0
 ---
@@ -13,7 +21,7 @@ License: Apache-2.0
 
 This CIP defines a set of common prefixes (or so-called human-readable part in the [bech32](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)) encoding format) for various bech32-encoded binary data across the Cardano eco-system.
 
-## Motivation
+## Motivation: why is this CIP necessary?
 
 Many tools used within the Cardano eco-system are manipulating binary data. Binary data are typically encoded as hexadecimal text strings when shown in a user interface (might it be a console, a url or a structured document from a server). From the user perspective, it can be difficult to distinguish between various encoded data. From the tools developer perspective, it can also be difficult to validate inputs based only on raw bytes (in particular when encoded data often have the same length).
 
@@ -23,7 +31,7 @@ Therefore, we can leverage bech32 for binary data encoding, with a set of common
 
 We define the following set of common prefixes with their corresponding semantic. Any software willing to represent binary data in a human-friendly way should abide by these guidelines. Should a data-type be missing, we encourage developers to update this CIP and register a new prefix.
 
-#### Keys
+### Keys
 
 | Prefix             | Meaning                                            | Contents                           |
 | ---                | ---                                                | ---                                |
@@ -72,7 +80,7 @@ We define the following set of common prefixes with their corresponding semantic
 | `vrf_sk`           | VRF signing key                                    | VRF signing key                    |
 | `vrf_vk`           | VRF verification key                               | VRF verification key               |
 
-#### Hashes
+### Hashes
 
 | Prefix             | Meaning                                            | Contents                                                 |
 | ---                | ---                                                | ---                                                      |
@@ -89,7 +97,7 @@ We define the following set of common prefixes with their corresponding semantic
 | `datum`            | Output datum hash                                  | blake2b\_256 digest of output datum                       |
 | `script_data`      | Script data hash                                   | blake2b\_256 digest of script data                        |
 
-#### Miscellaneous 
+### Miscellaneous
 
 | Prefix       | Meaning               | Contents                                                      |
 | ---          | ---                   | ---                                                           |
@@ -98,34 +106,33 @@ We define the following set of common prefixes with their corresponding semantic
 | `stake`      | Mainnet stake address | Network tag and stake credential                              |
 | `stake_test` | Testnet stake address | Network tag and stake credential                              |
 
+## Rationale: how does this CIP achieve its goals?
 
-## Rationale
-
-#### About the `_test` suffix
+### About the `_test` suffix
 
 Address already contains a discriminant tag, yet it requires one to peek at the internal binary payload. With Base58-encoded addresses, people have been used to look at first few characters and distinguish address this way. Not only this is cumbersome, but it is also made harder with both Shelley and Bech32-encoded addresses. On the one hand, the "common" part of the internal payload is much less than in Byron addresses and thus, the first bytes of the payload are varying much more. Plus, the bech32 prefix which can now be fixed makes it even more error-prone.
 
 Therefore, having a clear human-readable indicator regarding the network discrimination is useful.
 
-#### About `addr`
+### About `addr`
 
 Addresses probably are the most user-facing object in the current Cardano eco-system. Being able to clearly identify them
 
 > :bulb: Open question: with side-chains and multi-currencies coming soon, would it make sense to include the currency in the bech32 prefix? e.g. `ada1...` or `ada_addr1.`
 
-#### About `stake`
+### About `stake`
 
 Stake _addresses_ are references to reward account. They are used in many manipulation involving rewards (registering stake key, delegating, fetching reward balance etc..). We therefore make it a "first-class" object and assign it a dedicated prefix.
 
-#### About `sk` & `vk`
+### About `sk` & `vk`
 
 Both are rather transparent abbreviations for **s**igning **k**ey and **v**erification **k**ey.
 
-#### About `xsk` & `xvk`
+### About `xsk` & `xvk`
 
 The prefix `x` is typically used in cryptography to refer to e**x**tended keys (e.g. `xpub`, `xprv` ...). Following this convention, we prefix `sk` and `vk` as such when they refer to extended keys.
 
-#### About `vkh`
+### About `vkh`
 
 An abbreviation for **v**erification **k**ey **h**ash.
 
@@ -136,13 +143,25 @@ deregistration certificates, etc. As a result, it seems useful to have a
 human-readable prefix by which one can discern the different kinds of
 verification key hashes.
 
-## Backwards compatibility
+### Backwards compatibility
 
 The only prior work done towards that direction has been [jcli](https://input-output-hk.github.io/jormungandr/jcli/introduction.html). Historically, prefixes evolved very organically and without any agreed-upon standard. jcli is however only compatible with Jörmungandr and is not intended to be compatible with the cardano-node. Therefore, there's little concern regarding compatibility here.
 
-## Reference implementation
+## Path to Active
+
+### Acceptance Criteria
+
+- [x] There is a variety of tools and services utilizing this standard:
+  - [x] Trezor, Ledger
+  - [x] cardano-cli
+  - [x] cardano-wallet
+  - [x] Blockfrost
+  - [x] cardanoscan, cexplorer
+  - ... and more
+
+### Implementation Plan
 
-[cip5-js](https://www.npmjs.com/package/@dcspark/cip5-js)
+- Available JavaScript library: [cip5-js](https://www.npmjs.com/package/@dcspark/cip5-js)
 
 ## Copyright
 

CIP-0013/README.md

@@ -19,21 +19,19 @@ Created: 2020-09-22
 License: CC-BY-4.0
 ---
 
-# 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: 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.
 

CIP-0020/README.md

@@ -31,8 +31,6 @@ Created: 2021-06-13
 License: CC-BY-4.0
 ---
 
-# CIP-0020: Transaction message/comment metadata
-
 ## Abstract
 
 This CIP describes a basic JSON schema to add messages/comments/memos as transaction metadata by using the metadatum label **674**.

CIP-0031/README.md

@@ -1,8 +1,9 @@
 ---
 CIP: 31
 Title: Reference inputs
-Authors: Michael Peyton Jones <[email protected]>
-Implementors: 
+Authors:
+    - Michael Peyton Jones <[email protected]>
+Implementors:
     - Michael Peyton Jones <[email protected]>
     - Jared Corduan <[email protected]>
 Status: Active
@@ -11,8 +12,6 @@ Created: 2021-11-29
 License: CC-BY-4.0
 ---
 
-# Reference inputs
-
 ## Abstract
 
 We introduce a new kind of input, a _reference_ input, which allows looking at an output without spending it.

CIP-0032/README.md

@@ -1,8 +1,9 @@
 ---
 CIP: 32
 Title: Inline datums
-Authors: Michael Peyton Jones <[email protected]>
-Implementors: 
+Authors:
+    - Michael Peyton Jones <[email protected]>
+Implementors:
     - Michael Peyton Jones <[email protected]>
     - Jared Corduan <[email protected]>
 Status: Active
@@ -11,8 +12,6 @@ Created: 2021-11-29
 License: CC-BY-4.0
 ---
 
-# Inline datums
-
 ## Abstract
 
 We propose to allow datums themselves to be attached to outputs instead of datum hashes.

CIP-0033/README.md

@@ -1,8 +1,9 @@
 ---
 CIP: 33
 Title: Reference scripts
-Authors: Michael Peyton Jones <[email protected]>
-Implementors: 
+Authors:
+    - Michael Peyton Jones <[email protected]>
+Implementors:
     - Michael Peyton Jones <[email protected]>
     - Jared Corduan <[email protected]>
 Status: Active