Merge pull request #29 from intricate/cip5-bech32-key-hashes

Introduce verification key hashes to the CIP5 specification
cardano-foundation · Oct 20, 2020 · 0a34c9b · 0a34c9b
2 parents 0cf4324 + 80ad319
commit 0a34c9b
Showing 1 changed file with 36 additions and 21 deletions.
diff --git a/CIP5/README.md b/CIP5/README.md
@@ -23,27 +23,31 @@ 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.
 
-| Prefix       | Semantic                                |
-| ---          | ---                                     |
-| `addr_vk`    | Address verification key                |
-| `addr_sk`    | Address signing key                     |
-| `addr_xvk`   | Address extended verification key       |
-| `addr_xsk`   | Address extended signing key            |
-| `addr`       | Mainnet address                         |
-| `addr_test`  | Testnet address                         |
-| `stake_vk`   | Stake address verification key          |
-| `stake_sk`   | Stake address signing key               |
-| `stake_xvk`  | Stake address extended verification key |
-| `stake_xsk`  | Stake address extended signing key      |
-| `stake`      | Mainnet stake address                   |
-| `stake_test` | Testnet stake address                   |
-| `pool`       | Pool Id                                 |
-| `pool_vk`    | Pool operator verification key          |
-| `pool_sk`    | Pool operator signing key               |
-| `kes_vk`     | KES verification key                    |
-| `kes_sk`     | KES signing key                         |
-| `vrf_vk`     | VRF verification key                    |
-| `vrf_sk`     | VRF signing key                         |
+| Prefix       | Semantic                                      |
+| ---          | ---                                           |
+| `addr_vk`    | Address verification key                      |
+| `addr_vkh`   | Address verification key hash                 |
+| `addr_sk`    | Address signing key                           |
+| `addr_xvk`   | Address extended verification key             |
+| `addr_xsk`   | Address extended signing key                  |
+| `addr`       | Mainnet address                               |
+| `addr_test`  | Testnet address                               |
+| `stake_vk`   | Stake address verification key                |
+| `stake_vkh`  | Stake address verification key hash           |
+| `stake_sk`   | Stake address signing key                     |
+| `stake_xvk`  | Stake address extended verification key       |
+| `stake_xsk`  | Stake address extended signing key            |
+| `stake`      | Mainnet stake address                         |
+| `stake_test` | Testnet stake address                         |
+| `pool`       | Pool operator verification key hash (pool ID) |
+| `pool_vk`    | Pool operator verification key                |
+| `pool_sk`    | Pool operator signing key                     |
+| `kes_vk`     | KES verification key                          |
+| `kes_vkh`    | KES verification key hash                     |
+| `kes_sk`     | KES signing key                               |
+| `vrf_vk`     | VRF verification key                          |
+| `vrf_vkh`    | VRF verification key hash                     |
+| `vrf_sk`     | VRF signing key                               |
 
 ## Rationale
 
@@ -71,6 +75,17 @@ Both are rather transparent abbreviations for **s**igning **k**ey and **v**erifi
 
 The prefix `x` is typically used in cryptography to refer to e**x**tended keys (e.g. `xpub`, `xprv` ...). Following this convention, we prefix `sk` and `vk` as such when they refer to extended keys.
 
+#### About `vkh`
+
+An abbreviation for **v**erification **k**ey **h**ash.
+
+Verification key hashes are commonly utilized throughout the Cardano
+eco-system. For example, they're used in stake pool registration and
+retirement certificates, stake key registration, delegation, and
+deregistration certificates, etc. As a result, it seems useful to have a
+human-readable prefix by which one can discern the different kinds of
+verification key hashes.
+
 ## Backwards compatibility
 
 The only prior work done towards that direction has been [jcli](https://input-output-hk.github.io/jormungandr/jcli/introduction.html). Historically, prefixes evolved very organically and without any agreed-upon standard. jcli is however only compatible with Jörmungandr and is not intended to be compatible with the cardano-node. Therefore, there's little concern regarding compatibility here.