dashpay · thephez · Mar 2, 2026 · Mar 2, 2026 · Mar 2, 2026 · Mar 3, 2026
diff --git a/.cspell.json b/.cspell.json
@@ -0,0 +1,22 @@
+{
+  "version": "0.2",
+  "language": "en,en-US,en-GB",
+  "dictionaryDefinitions": [
+    {
+      "name": "project-words",
+      "path": "./project-words.txt",
+      "addWords": true
+    }
+  ],
+  "dictionaries": ["project-words"],
+  "ignorePaths": ["node_modules", "/project-words.txt"],
+  "overrides": [
+    {
+      "filename": "**/*.md",
+      "description": "Ignore letter-only strings 30+ chars (e.g. Base58 alphabet sets, extended hashes)",
+      "ignoreRegExpList": [
+        "/[A-Za-z]{30,}/g"
+      ]
+    }
+  ]
+}
diff --git a/.gitignore b/.gitignore
@@ -1 +1,2 @@
 .DS_Store
+node_modules/
diff --git a/dip-0003.md b/dip-0003.md
@@ -1,3 +1,4 @@
+<!-- cspell:ignore Serv -->
 <pre>
   DIP: 0003
   Title: Deterministic Masternode Lists
@@ -266,15 +267,15 @@
 A ProRegTx is invalid if any of these conditions are true:

 In the case of type 0:
  1. collateralOutpoint `hash` is null but an output with 1000 DASH is not present at position `n` of the ProRegTx outputs
  2. collateralOutpoint `hash` is not null but an output with 1000 DASH can't be found in the UTXO specified by the `hash` and `n`

 In the case of type 1:
  1. collateralOutpoint `hash` is null but an output with 4000 DASH is not present at position `n` of the ProRegTx outputs
  2. collateralOutpoint `hash` is not null but an output with 4000 DASH can't be found in the UTXO specified by the `hash` and `n`

 Applicable to any type:
  1. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting)
  2. KeyIdOwner or PubKeyOperator was already used by any entry in the registered masternodes set
  3. scriptPayout is not a P2PKH or P2SH script
  4. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner or KeyIdVoting

diff --git a/dip-0006.md b/dip-0006.md
@@ -284,7 +284,7 @@
 1. The quorumHash must match the current DKG session
 2. The proTxHash must belong to a member of the LLMQ
 3. The byte size of the validMembers bitvector must match `(quorumSize + 7) / 8`
-4. No out-of-range bits should be set in the byte representation of of the validMembers bitvector
+4. No out-of-range bits should be set in the byte representation of the validMembers bitvector
 5. The number of set bits in the validMembers bitvector must be at least >= quorumThreshold
 6. The sig must validate against the commitmentHash and the committing member’s operator key
 
@@ -436,7 +436,7 @@

 ## Current LLMQ types

 LLMQ types may be defined based on future DIPs. A list of registered LLMQ types can be found [here](dip-0006/llmq-types.md).

 ## Copyright


diff --git a/dip-0010.md b/dip-0010.md
@@ -195,7 +195,7 @@ consensus rules will not create a ChainLock for this block. Consequently the
 block would be invalidated on all nodes when the `ISLOCK` appears.
 
 Only in the case of an attack, where an attacker managed to get control over
-large parts of the masternode network, would this situation becomes a
+large parts of the masternode network, would this situation become a
 possibility. In this situation, ChainLocks have a higher priority when it comes
 to consensus. Please see [DIP0008 - ChainLocks](https://github.com/dashpay/dips/blob/master/dip-0008.md)
 for more details.

diff --git a/dip-0014.md b/dip-0014.md
@@ -1,3 +1,4 @@
+<!-- cspell:ignore Dpriv Dpub -->
 <pre>
   DIP: 0014
   Title: Extended Key Derivation using 256-bit Unsigned Integers
@@ -154,7 +155,7 @@ non-hardened child keys.
   * If it is (compatibility mode): let I = HMAC-SHA512(Key = c<sub>par</sub>, Data =
     ser<sub>P</sub>(K<sub>par</sub>) || ser<sub>32</sub>(i)).
   * If not (UInt256 mode): let I = HMAC-SHA512(Key = c<sub>par</sub>, Data =
-    ser<sub>p</sub>(K<sub>par</sub>) || ser<sub>256</sub>(i)).
+    ser<sub>P</sub>(K<sub>par</sub>) || ser<sub>256</sub>(i)).
 * Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.
 * The returned child key K<sub>i</sub> is point(parse<sub>256</sub>(I<sub>L</sub>)) +
   K<sub>par</sub>.
@@ -183,7 +184,7 @@ Because of the choice of the version bytes, the Base58 representation will start
 
 If (child number >= 2<sup>32</sup>) then serialize the following way :
 
-* 4 byte: version bytes (mainnet: `0X0EECEFC5` public, `0x0EECF02E` private; testnet: `0x0EED270B`
+* 4 byte: version bytes (mainnet: `0x0EECEFC5` public, `0x0EECF02E` private; testnet: `0x0EED270B`
   public, `0x0EED2774` private)
 * 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 derived keys, ....
 * 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)

diff --git a/dip-0015.md b/dip-0015.md
@@ -1,3 +1,4 @@
+<!-- cspell:ignore Dpriv -->
 <pre>
   DIP: 0015
   Title: DashPay
@@ -204,7 +205,7 @@
 Lastly contactInfo documents are used to store private information about other Dash identities.

 A JSON Schema representation of the DashPay contract is associated with this document and can be
 found [here](https://github.com/dashevo/dashpay-contract/blob/master/schema/dashpay.schema.json).
 The three document types are described in further detail in the following sections.

 ## The Contact Request
@@ -667,7 +668,7 @@
 The normal procedure of creating and publishing a document replace transition should be followed.
 All fields must be submitted when updating a profile. Fields that are not being updated should be
 set to their current value. Additionally, one or more of the following fields must be updated:
-`avatarUrl`, `publishMessage` and/or `displayName`. `$updatedAt` should be set to the current system
+`avatarUrl`, `publicMessage` and/or `displayName`. `$updatedAt` should be set to the current system
 time which must be within 5 minutes of the most recently mined platform chain block.
 
 ### Fetching a Profile

diff --git a/dip-0028.md b/dip-0028.md
@@ -1,3 +1,4 @@
+<!-- cspell:ignore Serv -->
 <pre>
   DIP: 0028
   Title: Evolution Masternodes

diff --git a/dip-0029.md b/dip-0029.md
@@ -1,3 +1,4 @@
+<!-- cspell:ignore Lblockdiff -->
 <pre>
   DIP: 0029
   Title: Randomness Beacon For LLMQ Selection
@@ -142,7 +143,7 @@ and standard pseudorandom in the sense of [[7]](https://eprint.iacr.org/2020/096
   random oracle model.
 
 **Note:** A similar formal argument can be made for the standard pseudorandomness of this scheme as
-the proof of pseudorandomness for DFNITY’s DRB, which can be found here
+the proof of pseudorandomness for DFINITY's DRB, which can be found here
 [[7]](https://eprint.iacr.org/2020/096.pdf). While the schemes differ, both rely on a DKG process
 and then a later occurrence of a BLS signature on a message. In their case, the evaluations on the
 challenge plaintext cannot be done during the DKG due to consensus rules and, in our case, due to
@@ -330,12 +331,12 @@ is available at [dashpay/dash#5262](https://github.com/dashpay/dash/pull/5262),
 [1] E. Syta _et al_., "Scalable Bias-Resistant Distributed Randomness," _2017 IEEE Symposium on
 Security and Privacy (SP)_, San Jose, CA, USA, 2017, pp. 444-460, doi: 10.1109/SP.2017.45.
 
-[2] Cloudflare, 1st august 2022, _Cloudflare Randomness Generation_, last accessed january 2023,
+[2] Cloudflare, 1st August 2022, _Cloudflare Randomness Generation_, last accessed January 2023,
 &lt;<https://github.com/cloudflare/cloudflare-docs/blob/production/content/randomness-beacon/cryptographic-background/randomness-generation.md>>.
 
 [3] Buterin, V., 2016, Ethereum 2.0 Mauve Paper.
 
-[4] Corestar, march 31th 2020, _Corestar Arcade_, last accessed january 2023,
+[4] Corestar, March 31st 2020, _Corestar Arcade_, last accessed January 2023,
 &lt;<https://github.com/corestario/tendermint>>.
 
 [5] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta and B. Ford, "OmniLedger: A