You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* first draft remediation of CIP-1853
* spelled NA instead of standard N/A
* not quite so adopted as thought, so need 3 specific implementations
Co-authored-by: Ryan Williams <[email protected]>
* duplicating implementation status of other not-yet-implemented key paths
* continuing precedent of 3 wallets to signify active derivation path
* add Ledger App as implementation
Co-authored-by: Ryan Williams <[email protected]>
* add Vacuum Labs as implementor
Co-authored-by: Ryan Williams <[email protected]>
---------
Co-authored-by: Ryan Williams <[email protected]>
[CIP-1852] establishes how Shelley-era hierarchical deterministic (HD) wallets should derive their keys. This document is a follow-up of this CIP specifying how stake pool cold keys should be derived.
15
20
16
-
## Motivation
21
+
## Motivation: why is this CIP necessary?
17
22
18
23
(Hierarchical) deterministic derivation of stake pool cold keys enables their restorability from a seed and most importantly, their management on hardware wallet devices. This in turn mitigates man-in-the middle attacks to which pool operators would otherwise be vulnerable if they managed their stake pool cold keys on a device not specifically hardened against alteration of the data to be signed/serialized without operator's explicit consent.
19
24
20
25
## Specification
21
26
22
-
Using `1853'` as the purpose field, we define the following derivation path structure for stake pool cold keys.
27
+
Using `1853'` as the purpose field, we define the following derivation path structure for stake pool cold keys:
23
28
24
29
```
25
30
m / purpose' / coin_type' / usecase' / cold_key_index'
@@ -31,7 +36,7 @@ Here the `usecase` is currently fixed to `0'`.
31
36
32
37
Given that stake pool cold keys are cryptographically the same as wallet keys already covered in CIP-1852, the master node and subsequent child keys derivation **MUST** be implemented in the same way as specified for wallets in CIP-1852.
33
38
34
-
## Rationale
39
+
## Rationale: how does this CIP achieve its goals?
35
40
36
41
### Why introducing a new purpose?
37
42
@@ -53,8 +58,19 @@ Each stake pool is supposed to be managed separately so there is currently no in
53
58
54
59
We chose hardened derivation at the usecase index as there is no incentive to mix the stake pool cold keys with other potential usecases and if there was such incentive, it would most likely be more appropriate to create a separate usecase/purpose for that.
55
60
61
+
## Path to Active
62
+
63
+
### Acceptance Criteria
64
+
65
+
-[ ] Standardisation of this derivation path among three wallets as of the Shelley ledger era.
0 commit comments