From f61885edcf5e63ac205b1ca5f08173f1336bff74 Mon Sep 17 00:00:00 2001
From: John Bampton <jbampton@users.noreply.github.com>
Date: Wed, 1 May 2024 06:54:05 +1000
Subject: docs: fix spelling (#1117)

Co-authored-by: Mark "Murch" Erhardt <murch@murch.one>
---
 bip-0083.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'bip-0083.mediawiki')

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==
 
-- 
cgit v1.2.3

