Skip to content

Commit

Permalink
doc: fix typos
Browse files Browse the repository at this point in the history
  • Loading branch information
shuoer86 authored and cdecker committed Feb 11, 2024
1 parent 89c7cad commit 6c04a6c
Show file tree
Hide file tree
Showing 15 changed files with 24 additions and 24 deletions.
2 changes: 1 addition & 1 deletion doc/developers-guide/app-development/rest.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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_.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
4 changes: 2 additions & 2 deletions doc/developers-guide/plugin-development/hooks.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
{
Expand Down Expand Up @@ -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.
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-cli.1.md
Original file line number Diff line number Diff line change
Expand Up @@ -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*,
Expand Down
8 changes: 4 additions & 4 deletions doc/lightning-decode.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-fundchannel.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-funderupdate.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-listclosedchannels.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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!)
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-listforwards.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)*
Expand Down
6 changes: 3 additions & 3 deletions doc/lightning-listpeerchannels.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-listpeers.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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;
Expand Down
2 changes: 1 addition & 1 deletion doc/lightning-wait.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
6 changes: 3 additions & 3 deletions doc/lightningd-config.5.md
Original file line number Diff line number Diff line change
Expand Up @@ -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*
Expand Down Expand Up @@ -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\]*

Expand Down Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions doc/lightningd-rpc.7.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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).
Expand Down

0 comments on commit 6c04a6c

Please sign in to comment.