Fix typos (#11)

docs/auth.md

@@ -33,7 +33,7 @@ typedef struct CkbAuthType {
 ```
 
 It is a data structure with 21 bytes. The content can be hash (blake160 or some
-other hashes) of pubic key, preimage, or some others. The blake160 hash function
+other hashes) of public key, preimage, or some others. The blake160 hash function
 is defined as first 20 bytes of [blake2b
 hash](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0022-transaction-structure/0022-transaction-structure.md#crypto-primitives).
 

docs/cardano.md

@@ -57,7 +57,7 @@ tools/ckb-auth-cli/target/debug/ckb-auth-cli cardano verify -p <Public key hash>
 ```
 
 ### Signature
-Signatures are structured using [CBOR](https://datatracker.ietf.org/doc/html/rfc7049). In order to ensure compatibility with cadrano-cli and the security of transactions, some modifications have been made to the original structure here:
+Signatures are structured using [CBOR](https://datatracker.ietf.org/doc/html/rfc7049). In order to ensure compatibility with cardano-cli and the security of transactions, some modifications have been made to the original structure here:
 The transaction hash of the Input is passed into ```generate_sighash_all``` function in ckb-auth as a hash.
 
 | byte string | length | data |

docs/ckb-auth-cli.md

@@ -1,13 +1,13 @@
 # Building ckb-auth-cli
-There are some required binaries that needs to be built in order to run [`ckb-auth-cli`](../tests/auth_rust/src/bin/ckb-auth-cli.rs).
+There are some required binaries that need to be built in order to run [`ckb-auth-cli`](../tests/auth_rust/src/bin/ckb-auth-cli.rs).
 We can run the following shell script to do so.
 ```bash
 cd ./tests/auth_rust/
 ./run.sh
 ```
 
 # Using ckb-auth-cli
-ckb-auth-cli is a command line utillity to faciliate the creation and verification of transaction
+ckb-auth-cli is a command line utility to facilitate the creation and verification of transaction
 with ckb-auth as lock script.
 
 ## Get the pub key hash with `parse` sub command.

docs/litecoin.md

@@ -1,5 +1,5 @@
 # ckb-auth litecoin interoperability
-Below uses the address `msv9GiUuCGEaoWzu7YcPDJo8hu5ij3Nzjn` whose coresponding private key is
+Below uses the address `msv9GiUuCGEaoWzu7YcPDJo8hu5ij3Nzjn` whose corresponding private key is
 `cSoKeLipWLXgdonv3pxE7XBp37yPVAnFcio3ZfGvsdjSWZa67cFJ`. See below on how to import this private
 key into the wallet.
 
@@ -17,7 +17,7 @@ with `litecoin-cli`, and then leverage ckb-auth to check the validity of this si
 See [the docs](./auth.md) for more details.
 
 # Generate and verify transaction with ckb-auth-cli
-[`ckb-auth-cli`](../tools/ckb-auth-cli) is a command line utility to easy generate and verify ckb-auth transactions. Below assume that the working directory is `tests/auth_rust`.
+[`ckb-auth-cli`](../tools/ckb-auth-cli) is a command line utility to easily generate and verify ckb-auth transactions. Below assume that the working directory is `tests/auth_rust`.
 
 ## Get the pub key hash with `parse` sub command.
 ```
@@ -116,7 +116,7 @@ Here's the output when I run that script:
 ```
 
 The legacy p2pkh addresses are normally with short length (see [How is a Litecoin address generated?](https://bitcoin.stackexchange.com/questions/65282/how-is-a-litecoin-address-generated) and [address format - litecoin constants and prefixes](https://bitcoin.stackexchange.com/questions/62781/litecoin-constants-and-prefixes) for details).
-As an rule of thumb, we can use the addresses started with m or n in litecoin testnet and addresses started with L for litecoin mainnet.
+As a rule of thumb, we can use the addresses started with m or n in litecoin testnet and addresses started with L for litecoin mainnet.
 For example, here the short addresses  `msv9GiUuCGEaoWzu7YcPDJo8hu5ij3Nzjn`
 may be used to sign message, while another short address 
 `Qe2ByfdQjU5AUZTvZ4XCrmQxHQctBXavWL` does not work.

docs/monero.md

@@ -124,7 +124,7 @@ pubkey_hash = blake2b_256(mode || pub_spend_key || pub_view_key)
 Here `mode` indicates whether we are using the spend key or the view key.
 Although there are flags `--spend` and `--view` for `monero-wallet-cli` to toggle whether to
 use spend key or view key to sign a message. We only support signing transactions with spend key.
-Thus he only valid values for `mode` is 0, which
+Thus the only valid value for `mode` is 0, which
 represents that we used spend key to sign the message.
 
 For example if the account we are using to sign messages is as above, i.e. it has
@@ -170,7 +170,7 @@ Stripping the prefix `SigV2` of `SigV2DXdetxj9qiRe6PHsch9EwZVutb1FFR38ubNuM9ef8Y
 we get the base58 representation of the signature. Note that monero's implementation of base58 is different from bitcoin's.
 See [monero-rs/base58-monero](https://github.com/monero-rs/base58-monero) for how to manipulate monero base58 data programatically.
 
-In order for ckb-auth to acutally verify the vailidity of the signature, we need to store the signature,
+In order for ckb-auth to actually verify the validity of the signature, we need to store the signature,
 the mode (only spend key mode is supported) that used to sign the transactions
 and public keys (spend key followed by view key).
 For example, to verify the signature with base65 encoding `3ZKheximq145tW14dshL17Jpqp2GJn296GfRnGqt3pMeaZU7xoEEAFr2Xm7Jc7xZjYWf6KhstZanA73to7uF6rea`
@@ -180,5 +180,5 @@ we need to use the data whose hex encoding is
 0f49fbc1bee9b7d31d3918a3753af5526a915e1f930198315da3e43bbd32f109c8a40ece34f42ff909263e16bb43f53bb14e5fe90de6c04f242b7c6a73ee320f00007caf7a553a894389dd562115b17e78ba84a5c7692677f216c54385dc5c6ff1bbcb8c902571ae1a777f7f07a023ecc5e3d83ba624d4b0ffb7eff79e8b5d10bd
 ```
 where the first 64 bytes `0f49fbc1bee9b7d31d3918a3753af5526a915e1f930198315da3e43bbd32f109c8a40ece34f42ff909263e16bb43f53bb14e5fe90de6c04f242b7c6a73ee320f` are the signature itself,
-the 65th byte is the mode for siging (here `00`, which stands for signing with spend key),
+the 65th byte is the mode for signing (here `00`, which stands for signing with spend key),
 the next 64 bytes `007caf7a553a894389dd562115b17e78ba84a5c7692677f216c54385dc5c6ff1bbcb8c902571ae1a777f7f07a023ecc5e3d83ba624d4b0ffb7eff79e8b5d10bd` are the public spend key followed by public view key.

docs/solana.md

@@ -90,8 +90,8 @@ the base58 encoding of the message, which is `5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAn
 ```bash
 solana transfer --fee-payer keypair.json --from keypair.json --blockhash G8mW5A2r4ab8gnmCB4abus21BN8vyMa3hbLg91AcsMon 6dN24Y1wBW66CxLfXbRT9umy1PMed8ZmfMWsghopczFg 0 --output json --verbose --dump-transaction-message --sign-only
 ```
-Here we construct a valid transaction with the message embedded as blockhash in the transcaction.
-When this trancation is signed by our private key, ckb-auth will recognize it as a valid transaction.
+Here we construct a valid transaction with the message embedded as blockhash in the transaction.
+When this transaction is signed by our private key, ckb-auth will recognize it as a valid transaction.
 Here the command line argument `6dN24Y1wBW66CxLfXbRT9umy1PMed8ZmfMWsghopczFg` represents the receiver account,
 and `0` represents the transaction amount. ckb-auth does not really care about the receiver account and amount,
 as long as the signature is valid and the solana message contains the message we intend to sign as blockhash.
@@ -131,7 +131,7 @@ A sample output is
 Ckb-auth requires the signature, public key and message to verify the validity of the signature.
 The signature and public key are contained in the signers of `solana transfer` output,
 and the message correponds to the field message of `solana transfer` output. 
-Signature, public key and message all together form the witness of this transction.
+Signature, public key and message all together form the witness of this transaction.
 Since the size of the witness is not static (as the message is dynamically-sized) and
 its length is relevant in computing transaction hash. We pad the whole witness to a memory region of size
 512. The first part of these memory region is a little-endian `uint16_t` integer represents the length of
@@ -173,7 +173,7 @@ For example, here is the witness that will be read by ckb-auth
 000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 ```
 
-Here the first two bytes 0x1601 = 278 in little endian represents that the length of the whole effective witness buffer.
+Here the first two bytes 0x1601 = 278 in little endian represent the length of the whole effective witness buffer.
 Then we have the real signature `33f29e94d650f5de73b84c835fa8db2c1f5a68549594a77829e845a747db96184fd80547c18e9e58374a7360b905cb8c51e00023de84595781b213bf283e3905`,
 followed by the real public key `4c0d9b63b23dc285a21f75b4a343e9b74ee2f4eb79f31a4b721d1f3d1f1a1c70` that is used to sign the message
 `02000104948d3046cc82355c0f60573ef84e5f1254d391af85a0f2d5f9387878dac6ac224c0d9b63b23dc285a21f75b4a343e9b74ee2f4eb79f31a4b721d1f3d1f1a1c70539b1bf5a7c053d0cf79ee1f3293d8cc29d3fd8794c262d97420580a0b9603ff00000000000000000000000000000000000000000000000000000000000000007e97cfe1ffbb973eceb70c3a11d94d6b2921718a5d9cce461c83e2a8d26666a301030201020c020000000000000000000000`.