doc: fix typos

doc/developers-guide/app-development/rest.md

@@ -81,7 +81,7 @@ The POST method requires `rune` header for authorization.
 existing runes can be retrieved with [listrunes](https://docs.corelightning.org/reference/lightning-commando-listrunes) command.
 
 Note: in version v23.08, a parameter `Nodeid` was required to be the id of the node we're talking to (see `id (pubkey)` received 
-from [getinfo](https://docs.corelightning.org/reference/lightning-getinfo)). You can still send this for backwards compatiblity, 
+from [getinfo](https://docs.corelightning.org/reference/lightning-getinfo)). You can still send this for backwards compatibility, 
 but it is completely ignored.
 
 ### cURL

doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md

@@ -108,7 +108,7 @@ The `featurebits` object allows the plugin to register featurebits that should b
 
 The `notifications` array allows plugins to announce which custom notifications they intend to send to `lightningd`. These custom notifications can then be subscribed to by other plugins, allowing them to communicate with each other via the existing publish-subscribe mechanism and react to events that happen in other plugins, or collect information based on the notification topics.
 
-The `custommessages` array allows the plugin to tell `lightningd` to explicity allow these (unknown) custom messages: we normally disconnect with an error if we receive these.  This only makes sense if you also subscribe to the `custommsg` hook.
+The `custommessages` array allows the plugin to tell `lightningd` to explicitly allow these (unknown) custom messages: we normally disconnect with an error if we receive these.  This only makes sense if you also subscribe to the `custommsg` hook.
 
 Plugins are free to register any `name` for their `rpcmethod` as long as the name was not previously registered. This includes both built-in methods, such as `help` and `getinfo`, as well as methods registered by other plugins. If there is a conflict then `lightningd` will report an error and kill the plugin, this aborts startup if the plugin is _important_.
 

doc/developers-guide/plugin-development/event-notifications.md

@@ -372,7 +372,7 @@ _Only_ tagged on external events (deposits/withdrawals to an external party).
 - `deposit`: funds deposited
 - `withdrawal`: funds withdrawn
 - `penalty`: funds paid or gained from a penalty tx.
-- `invoice`: funds paid to or recieved from an invoice.
+- `invoice`: funds paid to or received from an invoice.
 - `routed`: funds routed through this node.
 - `pushed`: funds pushed to peer.
 - `channel_open` : channel is opened, initial channel balance

doc/developers-guide/plugin-development/hooks.md

@@ -12,7 +12,7 @@ When hooks are registered, they can optionally specify "before" and "after" arra
 
 The call semantics of the hooks, i.e., when and how hooks are called, depend on the hook type. Most hooks are currently set to `single`-mode. In this mode only a single plugin can register the hook, and that plugin will get called for each event of that type. If a second plugin attempts to register the hook it gets killed and a corresponding log entry will be added to the logs.
 
-In `chain`-mode multiple plugins can register for the hook type and they are called in any order they are loaded (i.e. cmdline order first, configuration order file second: though note that the order of plugin directories is implementation-dependent), overriden only by `before` and `after` requirements the plugin's hook registrations specify. Each plugin can then handle the event or defer by returning a `continue` result like the following:
+In `chain`-mode multiple plugins can register for the hook type and they are called in any order they are loaded (i.e. cmdline order first, configuration order file second: though note that the order of plugin directories is implementation-dependent), overridden only by `before` and `after` requirements the plugin's hook registrations specify. Each plugin can then handle the event or defer by returning a `continue` result like the following:
 
 ```json
 {
@@ -141,7 +141,7 @@ Your plugin **MUST** validate the `data_version`. It **MUST** keep track of the
 2. If the new `data_version` is **_exactly_** the same value as the previous, then the previous set of queries was not committed.
    Your plugin **MAY** overwrite the previous set of queries with the current set, or it **MAY** overwrite its entire backup with a new snapshot of the database and the current `writes`
    array (treating this case as if `data_version` were two or more higher than the previous).
-3. If the new `data_version` is **_less than_** the previous, your plugin **MUST** halt and catch fire, and have the operator inspect what exactly happend here.
+3. If the new `data_version` is **_less than_** the previous, your plugin **MUST** halt and catch fire, and have the operator inspect what exactly happened here.
 4. Otherwise, some queries were lost and your plugin **SHOULD** recover by creating a new snapshot of the database: copy the database file, back up the given `writes` array, then delete (or atomically `rename` if in a POSIX filesystem) the previous backups of the database and SQL statements, or you **MAY** fail the hook to abort `lightningd`.
 
 The "rolling up" of the database could be done periodically as well if the log of SQL statements has grown large.

doc/lightning-cli.1.md

@@ -107,7 +107,7 @@ ARGUMENTS
 Arguments may be provided positionally or using *key*=*value* after the
 command name, based on either **-o** or **-k** option. When using **-k** 
 consider prefixing all arguments of the command with their respective keyword, 
-this is to avoid having lightningd intrepret the position of an arguement. 
+this is to avoid having lightningd interpret the position of an argument. 
 
 Arguments may be integer numbers (composed entirely of digits), floating-point 
 numbers (has a radix point but otherwise composed of digits), *true*, *false*,

doc/lightning-decode.7.md

@@ -37,7 +37,7 @@ If **type** is "bolt12 offer", and **valid** is *true*:
   - **offer\_node\_id** (pubkey): public key of the offering node
   - **offer\_chains** (array of hashs, optional): which blockchains this offer is for (missing implies bitcoin mainnet only):
     - the genesis blockhash
-  - **offer\_metadata** (hex, optional): any metadata the creater of the offer includes
+  - **offer\_metadata** (hex, optional): any metadata the creator of the offer includes
   - **offer\_currency** (string, optional): ISO 4217 code of the currency (missing implies Bitcoin) (always 3 characters)
   - **currency\_minor\_unit** (u32, optional): the number of decimal places to apply to amount (if currency known)
   - **offer\_amount** (u64, optional): the amount in the `offer_currency` adjusted by `currency_minor_unit`, if any
@@ -62,7 +62,7 @@ If **type** is "bolt12 offer", and **valid** is *true*:
     - **paywindow** (object, optional): when within a period will payment be accepted (default is prior and during the period):
       - **seconds\_before** (u32): seconds prior to period start
       - **seconds\_after** (u32): seconds after to period start
-      - **proportional\_amount** (boolean, optional): amount should be scaled if payed after period start (always *true*)
+      - **proportional\_amount** (boolean, optional): amount should be scaled if paid after period start (always *true*)
   - **unknown\_offer\_tlvs** (array of objects, optional): Any extra fields we didn't know how to parse:
     - **type** (u64): The type
     - **length** (u64): The length
@@ -114,7 +114,7 @@ If **type** is "bolt12 invoice\_request", and **valid** is *true*:
     - **paywindow** (object, optional): when within a period will payment be accepted (default is prior and during the period):
       - **seconds\_before** (u32): seconds prior to period start
       - **seconds\_after** (u32): seconds after to period start
-      - **proportional\_amount** (boolean, optional): amount should be scaled if payed after period start (always *true*)
+      - **proportional\_amount** (boolean, optional): amount should be scaled if paid after period start (always *true*)
   - **invreq\_chain** (hex, optional): which blockchain this offer is for (missing implies bitcoin mainnet only) (always 64 characters)
   - **invreq\_amount\_msat** (msat, optional): the amount the invoice should be for
   - **invreq\_features** (hex, optional): the feature bits of the invoice\_request
@@ -191,7 +191,7 @@ If **type** is "bolt12 invoice", and **valid** is *true*:
     - **paywindow** (object, optional): when within a period will payment be accepted (default is prior and during the period):
       - **seconds\_before** (u32): seconds prior to period start
       - **seconds\_after** (u32): seconds after to period start
-      - **proportional\_amount** (boolean, optional): amount should be scaled if payed after period start (always *true*)
+      - **proportional\_amount** (boolean, optional): amount should be scaled if paid after period start (always *true*)
   - **invreq\_chain** (hex, optional): which blockchain this offer is for (missing implies bitcoin mainnet only) (always 64 characters)
   - **invreq\_amount\_msat** (msat, optional): the amount the invoice should be for
   - **invreq\_features** (hex, optional): the feature bits of the invoice\_request

doc/lightning-fundchannel.7.md

@@ -63,7 +63,7 @@ Returns `close_to` set to closing script iff is negotiated.
 If peer supports `option_will_fund`, indicates to them to include this
 much liquidity into the channel. Must also pass in *compact\_lease*.
 
-*compact\_lease* is a compact represenation of the peer's expected
+*compact\_lease* is a compact representation of the peer's expected
 channel lease terms. If the peer's terms don't match this set, we will
 fail to open the channel.
 

doc/lightning-funderupdate.7.md

@@ -108,7 +108,7 @@ RETURN VALUE
 On success, an object is returned, containing:
 
 - **summary** (string): Summary of the current funding policy e.g. (match 100)
-- **policy** (string): Policy funder plugin will use to decide how much captial to commit to a v2 open channel request (one of "match", "available", "fixed")
+- **policy** (string): Policy funder plugin will use to decide how much capital to commit to a v2 open channel request (one of "match", "available", "fixed")
 - **policy\_mod** (u32): The *policy\_mod* is the number or 'modification' to apply to the policy.
 - **leases\_only** (boolean): Only contribute funds to `option_will_fund` lease requests.
 - **min\_their\_funding\_msat** (msat): The minimum funding sats that we require from peer to activate our funding policy.

doc/lightning-listclosedchannels.7.md

@@ -34,7 +34,7 @@ On success, an object containing **closedchannels** is returned.  It is an array
 - **leased** (boolean): Whether this channel was leased from `opener`
 - **total\_msat** (msat): total amount in the channel
 - **final\_to\_us\_msat** (msat): Our balance in final commitment transaction
-- **min\_to\_us\_msat** (msat): Least amount owed to us ever.  If the peer were to succesfully steal from us, this is the amount we would still retain.
+- **min\_to\_us\_msat** (msat): Least amount owed to us ever.  If the peer were to successfully steal from us, this is the amount we would still retain.
 - **max\_to\_us\_msat** (msat): Most amount owed to us ever.  If we were to successfully steal from the peer, this is the amount we could potentially get.
 - **close\_cause** (string): What caused the channel to close (one of "unknown", "local", "user", "remote", "protocol", "onchain")
 - **peer\_id** (pubkey, optional): Peer public key (can be missing with pre-v23.05 closes!)

doc/lightning-listforwards.7.md

@@ -35,7 +35,7 @@ On success, an object containing **forwards** is returned.  It is an array of ob
 - **in\_msat** (msat): the value of the incoming HTLC
 - **status** (string): still ongoing, completed, failed locally, or failed after forwarding (one of "offered", "settled", "local\_failed", "failed")
 - **received\_time** (number): the UNIX timestamp when this was received
-- **in\_htlc\_id** (u64, optional): the unique HTLC id the sender gave this (not present if incoming channel was closed before ugprade to v22.11)
+- **in\_htlc\_id** (u64, optional): the unique HTLC id the sender gave this (not present if incoming channel was closed before upgrade to v22.11)
 - **out\_channel** (short\_channel\_id, optional): the channel that the HTLC (trying to) forward to
 - **out\_htlc\_id** (u64, optional): the unique HTLC id we gave this when sending (may be missing even if out\_channel is present, for old forwards before v22.11)
 - **updated\_index** (u64, optional): 1-based index indicating order this forward was changed (only present if it has changed since creation) *(added v23.11)*

doc/lightning-listpeerchannels.7.md

@@ -80,7 +80,7 @@ On success, an object containing **channels** is returned.  It is an array of ob
   - **fee\_paid\_msat** (msat, optional): Amount we paid peer at open
   - **fee\_rcvd\_msat** (msat, optional): Amount we were paid by peer at open
 - **to\_us\_msat** (msat, optional): How much of channel is owed to us
-- **min\_to\_us\_msat** (msat, optional): Least amount owed to us ever.  If the peer were to succesfully steal from us, this is the amount we would still retain.
+- **min\_to\_us\_msat** (msat, optional): Least amount owed to us ever.  If the peer were to successfully steal from us, this is the amount we would still retain.
 - **max\_to\_us\_msat** (msat, optional): Most amount owed to us ever.  If we were to successfully steal from the peer, this is the amount we could potentially get.
 - **total\_msat** (msat, optional): total amount in the channel
 - **fee\_base\_msat** (msat, optional): amount we charge to use the channel
@@ -167,8 +167,8 @@ The *state* field values (and *old\_state* / *new\_state*) are worth describing
   * `"DUALOPEND_OPEN_COMMIT_READY"`: Like `OPENINGD`, but for v2 connections which
     are using collaborative opens. You're ready to send your commitment signed
     to your peer.
-  * `"DUALOPEND_OPEN_COMMITED"`: Like `OPENINGD`, but for v2 connections which
-    are using collaborative opens. You've gotten an inital signed commitment
+  * `"DUALOPEND_OPEN_COMMITTED"`: Like `OPENINGD`, but for v2 connections which
+    are using collaborative opens. You've gotten an initial signed commitment
     from your peer.
   * `"CHANNELD_AWAITING_LOCKIN"` / `"DUALOPEND\_AWAITING\_LOCKIN"`: The peer and you have agreed on channel
     parameters and are just waiting for the channel funding transaction to

doc/lightning-listpeers.7.md

@@ -280,7 +280,7 @@ state, or in various circumstances:
 * *min\_to\_us\_msat*: A string describing the historic point at which
   we owned the least amount of funds in this channel;
   a number followed by a string unit.
-  If the peer were to succesfully steal from us, this is the amount we
+  If the peer were to successfully steal from us, this is the amount we
   would still retain.
 * *max\_to\_us\_msat*: A string describing the historic point at which
   we owned the most amount of funds in this channel;

doc/lightning-wait.7.md

@@ -81,7 +81,7 @@ If **subsystem** is "forwards":
   - **details** (object, optional):
     - **status** (string, optional): still ongoing, completed, failed locally, or failed after forwarding (one of "offered", "settled", "failed", "local\_failed")
     - **in\_channel** (short\_channel\_id, optional): unique label supplied at invoice creation
-    - **in\_htlc\_id** (u64, optional): the unique HTLC id the sender gave this (not present if incoming channel was closed before ugprade to v22.11)
+    - **in\_htlc\_id** (u64, optional): the unique HTLC id the sender gave this (not present if incoming channel was closed before upgrade to v22.11)
     - **in\_msat** (msat, optional): the value of the incoming HTLC
     - **out\_channel** (short\_channel\_id, optional): the channel that the HTLC (trying to) forward to
 

doc/lightningd-config.5.md

@@ -388,7 +388,7 @@ use the RPC call lightning-setchannel(7).
 
   Explicitly control the usage of discovered public IPs in `node_announcement` updates.
   Default: 'auto' - Only if we don't have anything else to announce.
-  Note: You also need to open TCP port 9735 on your router towords your node.
+  Note: You also need to open TCP port 9735 on your router towards your node.
   Note: Will always be disabled if you use 'always-use-proxy'.
 
 * **announce-addr-discovered-port**=*PORT*
@@ -528,7 +528,7 @@ IP discovery is only active if no other addresses are announced.
 You can instead use *addr* to override this (eg. to change the port), or
 precisely control where to bind and what to announce with the
 *bind-addr* and *announce-addr* options. These will **disable** the
-*autolisten* logic, so you must specifiy exactly what you want!
+*autolisten* logic, so you must specify exactly what you want!
 
 * **addr**=*\[IPADDRESS\[:PORT\]\]|autotor:TORIPADDRESS\[:SERVICEPORT\]\[/torport=TORPORT\]|statictor:TORIPADDRESS\[:SERVICEPORT\]\[/torport=TORPORT\]\[/torblob=\[blob\]\]|HOSTNAME\[:PORT\]*
 
@@ -691,7 +691,7 @@ is currently unspecified.
 * **clear-plugins**
 
   This option clears all *plugin*, *important-plugin*, and *plugin-dir* options
-preceeding it,
+preceding it,
 including the default built-in plugin directory. You can still add
 *plugin-dir*, *plugin*, and *important-plugin* options following this
 and they will have the normal effect.

doc/lightningd-rpc.7.md

@@ -95,7 +95,7 @@ The exact specification for (most!) commands is specified in
 part of the documentation for each command; the following types are
 referred to in addition to simple JSON types:
 
-* `hex`: an even-length string of hexidecimal digits.
+* `hex`: an even-length string of hexadecimal digits.
 * `hash`: a 64-character `hex` which is a sha256 hash.
 * `secret`: a 64-character `hex` which is a secret of some kind.
 * `u64`: a JSON number without decimal point in the range 0 to 18446744073709551615 inclusive.
@@ -247,7 +247,7 @@ The result would be:
 ```
 
 Note: `"filter"` doesn't change the order, just which fields are
-printed.  Any fields not explictly mentioned are omitted from the
+printed.  Any fields not explicitly mentioned are omitted from the
 output, but plugins which don't support filter (and some routines
 doing simple JSON transfers) may ignore `"filter"`, so you should treat
 it as an optimazation only).