diff options
| author | John Bampton <jbampton@users.noreply.github.com> | 2024-05-01 06:54:05 +1000 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-04-30 16:54:05 -0400 |
| commit | f61885edcf5e63ac205b1ca5f08173f1336bff74 (patch) | |
| tree | 2d577255ee2fd3c3c5743edf1c0184a67abcb7d2 /bip-0083.mediawiki | |
| parent | 2d9e431fbe654640b55bca3bf8c4b17462890109 (diff) | |
docs: fix spelling (#1117)
Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
Diffstat (limited to 'bip-0083.mediawiki')
| -rw-r--r-- | bip-0083.mediawiki | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0083.mediawiki b/bip-0083.mediawiki index d7bbe8e..c669001 100644 --- a/bip-0083.mediawiki +++ b/bip-0083.mediawiki @@ -53,7 +53,7 @@ p //' n instead of p / 0' / n Rather than specifying upfront which path is to be used for a specific purpose (i.e. external invoicing vs. internal change), different applications can specify arbitrary parent nodes and derivation paths. This allows for nesting of sublevels to arbitrary depth with application-specified semantics. Rather than trying to specify use cases upfront, we leave the design completely open-ended. Different applications can exchange these mappings for interoperability. Eventually, if certain mappings become popular, application user interfaces can provide convenient shortcuts or use them as defaults. -Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more ideosyncracies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. +Note that BIP32 suggests reserving child 0 for the derivation of signing keys rather than sublevels. It is not really necessary to reserve signing key parents, however, as each key's parent's path can be explicitly stated. But unless we reserve a child for sublevel derivation, we lose the ability to nest deeper levels into the hierarchy. While we could reserve any arbitrary index for nesting sublevels, reserving child 0 seems simplest to implement, leaving all indices > 0 for contiguously indexed signing keys. We could also use MAX_INDEX (2<sup>31</sup> - 1) for this purpose. However, we believe doing so introduces more idiosyncrasies into the semantics and will present a problem if we ever decide to extend the scheme to use indices larger than 31 bits. ==Use Cases== |