Fix typos and grammar across docs guides

Author: mr-zwets

website/docs/guides/adversarial.md

@@ -3,7 +3,7 @@ title: Adversarial Analysis
 sidebar_label: Adversarial Analysis
 ---
 
-In this guide we'll dive into "adversarial analysis" for smart contract systems. Adversarial analysis means to analyze your system from the point of a potential malicious 3rd party which might want to hamper or attack your system. This guide will build further on knowledge from the [the transaction lifecycle guide](/docs/guides/lifecycle).
+In this guide we'll dive into "adversarial analysis" for smart contract systems. Adversarial analysis means to analyze your system from the point of a potential malicious 3rd party which might want to hamper or attack your system. This guide will build further on knowledge from the [transaction lifecycle guide](/docs/guides/lifecycle).
 
 ## The Happy Case
 
@@ -21,7 +21,7 @@ The adversarial case is where 3rd parties intentionally double spend unconfirmed
 In an adversarial environment where double spends occur, user-created transactions interacting with public are not certain to be confirmed. This means waiting for block confirmations is required to be sure the transaction isn't cancelled.
 :::
 
-There is 2 categories to consider for adversarial double spends:
+There are 2 categories to consider for adversarial double spends:
 
 1) Race-condition double spends (no miner help required)
 
@@ -37,7 +37,7 @@ For an adversarial attack to pull off this time-sensitive attack, he would requi
 
 ### Late Double Spends
 
-In the case of a late double spend (which does not try to exploit a race condition) the adversarial actor need help from a miner.
+In the case of a late double spend (which does not try to exploit a race condition) the adversarial actor needs help from a miner.
 Either the adversarial actor needs to convince the miners to abandon their first seen rule or he needs to be mining himself to be able to construct his own block.
 
 :::caution
@@ -100,7 +100,7 @@ Adversarial analysis should take into account that "first-seen rule" is just a c
 ### Specialized Block-Builders
 
 
-As described in the section on "stale-state arbitrage" economic actors may be incentivized to strategically create a competing transaction chain which takes advantage of an older price state/ratio which has not yet been confirmed in the blockchain. Although miners are not specialized in the optimal construction of DeFi transactions in a block, miner would over time be likely to team up with teams/companies creating this type of software for them.
+As described in the section on "stale-state arbitrage" economic actors may be incentivized to strategically create a competing transaction chain which takes advantage of an older price state/ratio which has not yet been confirmed in the blockchain. Although miners are not specialized in the optimal construction of DeFi transactions in a block, miners would over time be likely to team up with teams/companies creating this type of software for them.
 
 :::note
 Ethereum with its large amount of MEV has already seen the emergence of specialized 'block builder' as a new class of relevant economic actors separate from the block proposer (who signs the block).
@@ -120,7 +120,7 @@ This strategy of batching same-block trades (or "joint-execution") is the key co
 
 ### Centralized Co-signing
 
-For contract systems relying on a continuously update on-chain oracle price feed, the problem of 'stale-state arbitrage' reappears.
+For contract systems relying on a continuously updated on-chain oracle price feed, the problem of 'stale-state arbitrage' reappears.
 However in this context the only known solution to adversarial actors exploiting stale state with a late double spend is to require centralized co-signing in the contract system.
 
 The drawback of this approach is that it introduces a central party to enforce honest, sequential actions to prevent late double spends. The approach introduces the need for interactivity and assumes that the central signing service does not collude or cannot be bribed, additionally it also introduces new possible security concerns.

website/docs/guides/cashtokens.md

@@ -38,7 +38,7 @@ The maximum size for a fungible token `amount` is the max signed 64-bit integer
 
 ### Non-Fungible Tokens
 
-The `nft` info on a UTXO will only be present if the UTXO contains an NFT. The `nft` object has 2 properties: the `capability` and the `commitment`. The `commitment` is the data field for the NFT which can is allowed to be up to 128 bytes.
+The `nft` info on a UTXO will only be present if the UTXO contains an NFT. The `nft` object has 2 properties: the `capability` and the `commitment`. The `commitment` is the data field for the NFT which is allowed to be up to 128 bytes.
 
 Capability `none` then refers to an immutable NFT where the commitment cannot be changed. The `mutable` capability means the `commitment` field can change over time, usually to contain smart contract state. Lastly the `minting` capability means that the NFT can create new NFTs from the same `category`.
 
@@ -91,7 +91,7 @@ bytes tx.inputs[i].tokenCategory
 
 When accessing the `tokenCategory` through introspection the result returns `0x` (empty byte string) when that specific item does not contain tokens. If the item does have tokens it returns the `bytes32 tokenCategory`. When the item contains an NFT with a capability, the 32-byte `tokenCategory` is concatenated together with `0x01` for a mutable NFT and `0x02` for a minting NFT.
 
-If you want to check for an NFT using introspection, you have either split the `tokenCategory` from the `capability` or check the concatenation of the `tokenCategory` and `capability`.
+If you want to check for an NFT using introspection, you have to either split the `tokenCategory` from the `capability` or check the concatenation of the `tokenCategory` and `capability`.
 
 ```solidity
   // Constructor parameters: providedCategory
@@ -162,6 +162,11 @@ The easiest way to prevent issues with "junk" empty NFTs is to check that only N
 The `tokenCategory` introspection variable returns the tokenCategory in the original unreversed order, this is unlike wallets and explorers which use the reversed byte-order. So be careful about the byte-order of `tokenCategory` when working with BCH smart contracts.
 
 ```ts
+// Reverse byte order of a hex string.
+function reverseHex(hex: string): string {
+  return hex.match(/../g)!.reverse().join('');
+}
+
 // when using a standard encoded tokenId, reverse the hex before using it in your contract
 const contract = new Contract(artifact, [reverseHex(tokenId)], { provider })
 ```
@@ -186,7 +191,7 @@ Signing for CashTokens inputs is designed in such a way that pre-CashTokens wall
 
 ## CashTokens Genesis transactions
 
-A CashTokens genesis transaction is a transaction which creates a new `category` of CashTokens. To create a CashTokens genesis transaction you need a `vout0` UTXO because the txid of the UTXO will be you newly created `category`.
+A CashTokens genesis transaction is a transaction which creates a new `category` of CashTokens. To create a CashTokens genesis transaction you need a `vout0` UTXO because the txid of the UTXO will be your newly created `category`.
 
 The requirement for a `vout0` UTXO can mean that you might need to create a setup transaction "pre-genesis" which will create this output. The "pre-genesis" txid then is your token's `category`.
 

website/docs/guides/covenants.md

@@ -35,7 +35,7 @@ When using CashScript, you can access a lot of *introspection data* that can be
 While we know the individual data fields, it's not immediately clear how this can be used to create useful smart contracts on Bitcoin Cash. However, there are several constraints that can be created using these fields — most important of which are constraints on the recipients of funds — so that is what we discuss.
 
 ### Restricting P2PKH recipients
-One interesting technique in Bitcoin Cash is called blind escrow, meaning that funds are placed in an escrow contract. This contract can only release the funds to one of the escrow participants, and has no other control over the funds. We can implement this blind escrow as a covenants by restricting the possible recipients (although there are other possible designs for escrows).
+One interesting technique in Bitcoin Cash is called blind escrow, meaning that funds are placed in an escrow contract. This contract can only release the funds to one of the escrow participants, and has no other control over the funds. We can implement this blind escrow as a covenant by restricting the possible recipients (although there are other possible designs for escrows).
 
 ```solidity
 contract Escrow(bytes20 arbiter, bytes20 buyer, bytes20 seller) {
@@ -219,7 +219,7 @@ We use `tx.locktime` to introspect the value of the timelock, and to write the v
 
 #### Integer padding for local state
 
-Padding an integer to a fixed-size byte-length is a very important when storing local state in an nftCommitment. We can use the `toPaddedBytes(int, length)` function to pad the integer to the desired length. When casting a script number to bytes, developers need to consider what the preferable fixed-size length is for each individual case depending on the integer range. Below we add a table with info on the maximum integer size for common cases:
+Padding an integer to a fixed-size byte-length is very important when storing local state in an nftCommitment. We can use the `toPaddedBytes(int, length)` function to pad the integer to the desired length. When casting a script number to bytes, developers need to consider what the preferable fixed-size length is for each individual case depending on the integer range. Below we add a table with info on the maximum integer size for common cases:
 
 | Integer Type    | Max integer value                  | Max Byte Size in Script Number Format  |
 | --------------  | -----------------------------------| ---------------------------------------|
@@ -234,7 +234,7 @@ VM numbers follow Script Number format (A.K.A. CSCriptNum), to convert VM number
 
 ### Issuing NFTs as receipts
 
-A covenant that manages funds (BCH + fungible tokens of a certain category) which are pooled together from different people often wants to enable its participants to also exit the covenants with their funds. It would be incredibly hard continuously updating a data structure to keep track of which address contributed how much in the local state of the contract. A much better solution is to issue receipts each time funds are added to the pool! This way the contract does not have a 'global view' of who owns what at any time, but it can validate the receipts when invoking a withdrawal.
+A covenant that manages funds (BCH + fungible tokens of a certain category) which are pooled together from different people often wants to enable its participants to also exit the covenants with their funds. It would be incredibly hard to continuously update a data structure to keep track of which address contributed how much in the local state of the contract. A much better solution is to issue receipts each time funds are added to the pool! This way the contract does not have a 'global view' of who owns what at any time, but it can validate the receipts when invoking a withdrawal.
 
 Technically this happens by minting a new NFT, with in the commitment field the amount of satoshis or fungible tokens that were contributed to the pool, and sending this to the address of the contributor.
 
@@ -311,8 +311,8 @@ contract PooledFunds(
         require(tx.inputs[1].tokenCategory == tokenCategoryReceipt);
 
         // Read the amount that was contributed to the pool from the NFT commitment
-        bytes ntfCommitmentData = tx.inputs[1].nftCommitment;
-        bytes actionIdentifier, bytes amountToWithdrawBytes = ntfCommitmentData.split(1);
+        bytes nftCommitmentData = tx.inputs[1].nftCommitment;
+        bytes actionIdentifier, bytes amountToWithdrawBytes = nftCommitmentData.split(1);
         int amountToWithdraw = int(amountToWithdrawBytes);
 
         if (actionIdentifier == 0x01) {

website/docs/guides/debugging.md

@@ -45,7 +45,7 @@ Whenever a transaction fails, there will be a link in the console to open your s
 It's also possible to export the transaction for step-by-step debugging in the BitAuth IDE without failure. To do so, you can call the `getBitauthUri()` function on the transaction. This will return a URI that can be opened in the BitAuth IDE.
 
 ```ts
-const uri = await transactionBuilder.getBitauthUri();
+const uri = transactionBuilder.getBitauthUri();
 ```
 
 :::caution

website/docs/guides/infrastructure.md

@@ -31,7 +31,7 @@ To construct the full contract script you need both the `constructor` arguments
 To store the contract details off-chain, you will need to run a database server which stores the specific constructor arguments for each contract, this will translate into their respective smart contract addresses. This is crucial data for users to spend from BCH locked in such a smart contract. So this approach does introduce a single point of failure.
 
 :::caution
-When using off-chain storage, it is the crucial responsibility of smart contract service to keep track of the contract details making up the `P2SH` contract, as user-wallets currently aren't capable to keep track of contract details and are fully reliant on the app server to store this critical info.
+When using off-chain storage, it is the crucial responsibility of the smart contract service to keep track of the contract details making up the `P2SH` contract, as user-wallets currently aren't capable of keeping track of contract details and are fully reliant on the app server to store this critical info.
 :::
 
 ### On-chain storage

website/docs/guides/lifecycle.md

@@ -23,7 +23,7 @@ Even if a miner sets a higher minimum fee for inclusion in his own blocks, 1 sat
 
 Before transactions are included in a block they are waiting for block inclusion in the mempool of the full nodes. Because transactions in the mempool are "seen" but not included in the blockchain yet, the latest state of the blockchain of who owns what is somewhat fuzzy.
 
-In a normal scenario it's only a matter of time before a BCH transaction in the mempool gets included in a block. Where things get more complex however is if there are **competing unconfirmed transactions**. In this scenario it is **not** necessarily the clear that a transaction is destined to be included in the blockchain. In other words, the latest state of the blockchain is still undecided.
+In a normal scenario it's only a matter of time before a BCH transaction in the mempool gets included in a block. Where things get more complex however is if there are **competing unconfirmed transactions**. In this scenario it is **not** necessarily clear that a transaction is destined to be included in the blockchain. In other words, the latest state of the blockchain is still undecided.
 
 :::tip
 This is why many BCH indexers will allow you to query UTXOs with the option to include or exclude unconfirmed transactions. By default indexers will include unconfirmed UTXOs/unconfirmed transactions in the query result.

website/docs/language/contracts.md

@@ -59,6 +59,10 @@ contract TransferWithTimeout(pubkey sender, pubkey recipient, int timeout) {
 }
 ```
 
+:::note
+The functions described here are top-level contract functions, which act as the entry points for spending from the contract. CashScript does not yet support user-defined reusable functions that can be called from within other functions. Callable functions are likely coming in CashScript v0.14, which would also allow function calls inside loops and loops inside reusable functions.
+:::
+
 ### Function Arguments
 
 Function arguments are provided by the user in the unlocking script of the transaction inputs when spending from the contract. Note that function arguments are variables and can be reassigned inside the function body.