Fix spellcheck

Author: rkalis

.cspell.json

@@ -33,6 +33,7 @@
         "cashc",
         "cashproof",
         "cashscript",
+        "cashtokens",
         "castable",
         "checkdatasig",
         "checkdatasigverify",
@@ -79,6 +80,7 @@
         "INPUTBYTECODE",
         "INPUTINDEX",
         "INPUTSEQUENCENUMBER",
+        "ints",
         "kalis",
         "keypair",
         "keypairs",
@@ -98,6 +100,7 @@
         "meep",
         "minimaldata",
         "minimalif",
+        "mocknet",
         "n",
         "noncompressed",
         "nonschnorr",
@@ -109,6 +112,7 @@
         "numequal",
         "numequalverify",
         "numnotequal",
+        "NOTEQUAL",
         "op",
         "opcode",
         "opcodes",
@@ -156,21 +160,28 @@
         "sigs",
         "spedn",
         "startup",
+        "standardness",
         "tagline",
         "teardown",
         "tendo",
         "timeout",
+        "timeops",
+        "timelock",
+        "timelocks",
         "toaltstack",
         "troutner",
         "tuple",
         "tuples",
+        "typeof",
         "txid",
         "TXINPUTCOUNT",
         "TXLOCKTIME",
         "TXOUTPUTCOUNT",
         "txvalue",
         "TXVERSION",
         "unary",
+        "unlocker",
+        "unlockers",
         "utxo",
         "utxo's",
         "UTXOBYTECODE",
@@ -185,29 +196,43 @@
         "workdir"
     ],
     "ignoreWords": [
+        "bitcats",
         "bitcoincashjs",
+        "branchup",
+        "bchguru",
         "cashcompiler",
+        "cashninjas",
         "cherian",
+        "CSCriptNum",
         "docu",
+        "fundme",
+        "hardhat",
         "infima",
         "jedex",
         "lichos",
+        "mainnetjs",
         "maxdepth",
         "networkprovider",
         "outputnulldata",
         "outputp",
+        "pako",
+        "popd",
+        "pushd",
         "setfiletype",
         "tada",
+        "tapswap",
         "txage",
         "txbytecode",
         "txhashoutputs",
         "txtime",
+        "vite",
         "withage",
         "withfeeperbyte",
         "withhardcodedfee",
         "withminchange",
         "withopreturn",
-        "withtime"
+        "withtime",
+        "XBVJRKV"
     ],
     "ignorePaths": [
         // Do not spellcheck NPM files

packages/cashscript/src/LibauthTemplate.ts

@@ -101,7 +101,7 @@ export const buildTemplate = async ({
       };
 
       // add extra unlocking and locking script for P2PKH inputs spent alongside our contract
-      // this is needed for correct cross-referrences in the template
+      // this is needed for correct cross-references in the template
       template.scripts[unlockScriptName] = {
         name: unlockScriptName,
         script:

packages/cashscript/src/Transaction.ts

@@ -278,7 +278,7 @@ export class Transaction {
       // Compare nfts in- and outputs, check if inputs have nfts corresponding to outputs
       // Keep list of nfts in inputs without matching output
       // First check immutable nfts, then mutable & minting nfts together
-      // This is so an immutible input gets matched first and is removed from the list of unused nfts
+      // This is so an immutable input gets matched first and is removed from the list of unused nfts
       let unusedNfts = listNftsInputs;
       for (const nftInput of listNftsInputs) {
         if (nftInput.capability === 'none') {

packages/cashscript/src/TransactionBuilder.ts

@@ -52,7 +52,7 @@ export class TransactionBuilder {
       (!unlocker && utxos.some((utxo) => !isUnlockableUtxo(utxo)))
       || (unlocker && utxos.some((utxo) => isUnlockableUtxo(utxo)))
     ) {
-      throw new Error('Either all UTXOs must have an individual unlocker speciifed, or no UTXOs must have an individual unlocker specified and a shared unlocker must be provided');
+      throw new Error('Either all UTXOs must have an individual unlocker specified, or no UTXOs must have an individual unlocker specified and a shared unlocker must be provided');
     }
 
     if (!unlocker) {

packages/cashscript/test/debugging.test.ts

@@ -694,7 +694,7 @@ describe('Debugging tests', () => {
     });
 
     // test_multiline_non_require_error
-    it('should fail with correct error message and statament when a multiline non-require statement fails', async () => {
+    it('should fail with correct error message and statement when a multiline non-require statement fails', async () => {
       const contract = new Contract(artifact3, [], { provider });
 
       provider.addUtxo(contract.address, randomUtxo());

website/docs/basics/about-bch.md

@@ -5,7 +5,7 @@ sidebar_label: About Bitcoin Cash
 
 Bitcoin Cash (ticker BCH) is one of the biggest cryptocurrencies. Bitcoin Cash is a fork of Bitcoin started in 2017 because of differences in vision for the future of the Bitcoin project.
 
-Bitcoin Cash shares many of the same fundamentals as Bitcoin (BTC) like the *Proof-of-Work* consensus alrgorithm and the *UTXO data-model*. However regarding smart contract programmability, Bitcoin Cash has significantly diverged from Bitcoin (BTC). We will first cover the UTXO data model and then delve into the smart contract capabilities of Bitcoin Cash.
+Bitcoin Cash shares many of the same fundamentals as Bitcoin (BTC) like the *Proof-of-Work* consensus algorithm and the *UTXO data-model*. However regarding smart contract programmability, Bitcoin Cash has significantly diverged from Bitcoin (BTC). We will first cover the UTXO data model and then delve into the smart contract capabilities of Bitcoin Cash.
 
 :::info
 To learn more about the Bitcoin Basics refer to the book ['Mastering Bitcoin'](https://github.com/bitcoinbook/bitcoinbook). There is also a modified version for BCH specifically called ['Mastering Bitcoin Cash'](https://github.com/Bitcoin-com/mastering-bitcoin-cash).
@@ -31,4 +31,4 @@ The locking and unlocking scripts of regular transactions and smart contracts on
 
 ### CashScript
 
-CashScript is a high-level programming language for smart contracts on Bitcoin Cash that offers a strong abstraction for a smoother development experience. The CashScript syntax is based on Ethereum's smart contract language Solidity, but its functionality is very different since smart contracts on Bitcoin Cash differ greatly from smart contracts on Ethereum.
+CashScript is a high-level programming language for smart contracts on Bitcoin Cash that offers a strong abstraction for a smoother development experience. The CashScript syntax is based on Ethereum's smart contract language Solidity, but its functionality is very different since smart contracts on Bitcoin Cash differ greatly from smart contracts on Ethereum.

website/docs/basics/getting-started.md

@@ -20,7 +20,7 @@ With the CashScript playground there's a nice integrated editor to get started,
 
 To write CashScript smart contracts locally you use a code editor. For the best developer experience, we recommend to use VS Code with the CashScript extension. This way it will automatically recognize `.cash` files and offer highlighting and autocompletion.
 
-:::note prerequisties
+:::note prerequisites
 - Basic familiarity with the command line
 - Node.js installed
 - A code editor (VS Code recommended)
@@ -149,4 +149,4 @@ const transferDetails = await contract.functions
 console.log(transferDetails);
 ```
 
-Congrats 🎉! You've successfully created a transaction spending from a Bitcoin Cash smart contract! 
+Congrats 🎉! You've successfully created a transaction spending from a Bitcoin Cash smart contract!

website/docs/guides/debugging.md

@@ -26,14 +26,14 @@ If a CashScript transaction is evaluated with `.debug()` or is sent to a network
 ```bash
 HodlVault.cash:23 Require statement failed at input 0 in contract HodlVault.cash at line 23.
 Failing statement: require(price >= priceTarget)
-Bithauth IDE: [link]
+Bitauth IDE: [link]
 ```
 
 Read the error message to see which line in the CashScript contract causes the transaction validation to fail. Investigate whether the contract function invocation is the issue (on the TypeScript SDK side) or whether the issue is in the CashScript contract itself (so you'd need to update your contract and recompile the artifact). If it is not clear **why** the CashScript contract is failing on that line, then you can use the following two strategies: console logging & Bitauth IDE stack trace.
 
 ### Console Logging
 
-To help with debugging you can add `console.log` statements to your CashScript contract file to log variables. This way you investigate whether the variables have the expected values when they get to the failing `require` statement in the CashScript file. After adding the `console.log` statements, recompile your contract so they are added to your contract's Artifact. 
+To help with debugging you can add `console.log` statements to your CashScript contract file to log variables. This way you investigate whether the variables have the expected values when they get to the failing `require` statement in the CashScript file. After adding the `console.log` statements, recompile your contract so they are added to your contract's Artifact.
 
 ### Bitauth IDE
 
@@ -50,7 +50,7 @@ const uri = await transaction.bitauthUri();
 It is unsafe to debug transactions on mainnet as private keys will be exposed to BitAuth IDE and transmitted over the network.
 :::
 
-The Bithauth IDE will show you the two-way mapping between the CashScript contract code generated opcodes. Here is [a Bithauth IDE link][BitauthIDE] for the basic `TransferWithTimeout` contract as an example:
+The Bitauth IDE will show you the two-way mapping between the CashScript contract code generated opcodes. Here is [a Bitauth IDE link][BitauthIDE] for the basic `TransferWithTimeout` contract as an example:
 
 ```js
 // "TransferWithTimeout" contract constructor parameters
@@ -73,7 +73,7 @@ OP_3 OP_ROLL OP_1 OP_ROLL OP_CHECKSIG OP_VERIFY /*         require(checkSig(send
 OP_1 OP_ROLL OP_CHECKLOCKTIMEVERIFY OP_DROP     /*         require(tx.time >= timeout);                                         */
 OP_1 OP_NIP                                     /*     }                                                                        */
 OP_ENDIF                                        /* }                                                                            */
-                                                /*      
+                                                /*
 ```
 
 ## Advanced Transaction Builder
@@ -88,12 +88,12 @@ When a transaction gets rejected by a full node, it will return a cryptic error
 mandatory-script-verify-flag-failed (Script failed an OP_VERIFY operation) (code 16)
 ```
 
-Read the message carefully to investigate whether the issue is a failing script (failing OpCode) or whether a standardness rule like minimum-relay-fee is violated. 
+Read the message carefully to investigate whether the issue is a failing script (failing OpCode) or whether a standardness rule like minimum-relay-fee is violated.
 If the cause is a failing OpCode, you can check the contract's Artifact to see how many appearances this OpCode has. Sometimes the OpCode only appears once or twice, indicating where the failing `require` statement is. Other times you might see 15 appearances of the OpCode leaving you to try the next strategies.
 
 ### Removing Contract Checks
 
-If your contract fails, you can remove (or comment out) the lines that are the likely cause of the error. After recompiling to a new Artifact you can test whether the remaining subcontract works or fails with a different error. If this is the case, then you learned that there is an issue in the removed CashScript code block. In the worst case, when you have no indication from the failing opcode (previous strategy), then you will have to try to remove different parts of your contract and try different sub-contracts repeatedly. 
+If your contract fails, you can remove (or comment out) the lines that are the likely cause of the error. After recompiling to a new Artifact you can test whether the remaining subcontract works or fails with a different error. If this is the case, then you learned that there is an issue in the removed CashScript code block. In the worst case, when you have no indication from the failing opcode (previous strategy), then you will have to try to remove different parts of your contract and try different sub-contracts repeatedly.
 
 To use this strategy effectively, the contract setup with funding should be automated as to avoid having to send testnet coins manually to each different subcontract. However inefficient, this strategy should always be able to get you to find the failing line in your CashScript contract. Then you can investigate whether the issue is the contract invocation or the `require` statement in the CashScript file.
 

website/docs/guides/optimization.md

@@ -109,7 +109,7 @@ console.log(contract.opcount);
 console.log(contract.bytesize);
 ```
 
-With this workflow, you can make changes to the contract and the run the JavaScript program to 
+With this workflow, you can make changes to the contract and the run the JavaScript program to
 get an accurate measure of how the bytesize of your contract changes with different optimizations.
 
 ## To optimize or not to optimize?
@@ -120,5 +120,5 @@ In the context of optimizing contract bytecode, there's an important remark to c
 
 >We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
 
-It's worth considering whether optimizing the redeem script is necessary at all. If the contract is accepted by the network, and there is no glaring inefficiency in the bytecode, perhaps the best optimization is to not to obsess prematurely about things like blocksize.
+It's worth considering whether optimizing the redeem script is necessary at all. If the contract is accepted by the network, and there is no glaring inefficiency in the bytecode, perhaps the best optimization is to not to obsess prematurely about things like block size.
 

website/docs/language/globals.md

@@ -71,7 +71,7 @@ int tx.locktime
 Represents the `nLocktime` field of the transaction. This is similar to the [`tx.time`][tx.time] global variable but `tx.time` can only be used in `require` statements, not for variable declaration.
 
 :::tip
- The usecase for `tx.locktime` is to read the `nLocktime` value and add to the local state. Example usage for this is demonstrated in the [Sablier example](/docs/guides/covenants#keeping-local-state-in-nfts).
+ The use case for `tx.locktime` is to read the `nLocktime` value and add to the local state. Example usage for this is demonstrated in the [Sablier example](/docs/guides/covenants#keeping-local-state-in-nfts).
 :::
 
 ### tx.inputs