Updated Scripts

doc/lightning-bkpr-listbalances.7.md

@@ -9,11 +9,9 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-The **bkpr-listbalances** RPC command is a list of all current and historical account balances. An account is either the on-chain *wallet* or a channel balance.
-Any funds sent to an *external* account will not be accounted for here.
+The **bkpr-listbalances** RPC command is a list of all current and historical account balances. An account is either the on-chain *wallet* or a channel balance. Any funds sent to an *external* account will not be accounted for here.
 
-Note that any channel that was recorded will be listed. Closed channel balances
-will be 0msat.
+Note that any channel that was recorded will be listed. Closed channel balances will be 0msat.
 
 RETURN VALUE
 ------------

doc/lightning-checkrune.7.md

@@ -25,6 +25,9 @@ On success, an object is returned, containing:
 
 [comment]: # (GENERATE-FROM-SCHEMA-END)
 
+ERRORS
+------
+
 The following error codes may occur:
 
 - RUNE\_NOT\_AUTHORIZED (1501): rune is not for this node (or perhaps completely invalid)
@@ -34,8 +37,7 @@ The following error codes may occur:
 AUTHOR
 ------
 
-Shahana Farooqui <<[email protected]>> is mainly responsible
-for consolidating logic from commando.
+Shahana Farooqui <<[email protected]>> is mainly responsible for consolidating logic from commando.
 
 SEE ALSO
 --------
@@ -46,4 +48,5 @@ RESOURCES
 ---------
 
 Main web site: <https://github.com/ElementsProject/lightning>
+
 [comment]: # ( SHA256STAMP:977acf366f8fde1411f2c78d072b34b38b456e95381a6bce8fe6855a2d91434a)

doc/lightning-commando.7.md

@@ -18,8 +18,11 @@ provided you with a *rune* which allows it.
 RETURN VALUE
 ------------
 
+[comment]: # (GENERATE-FROM-SCHEMA-START)
 On success, the return depends on the *method* invoked.
 
+[comment]: # (GENERATE-FROM-SCHEMA-END)
+
 ERRORS
 ------
 

doc/lightning-decode.7.md

@@ -300,14 +300,13 @@ SEE ALSO
 
 lightning-pay(7), lightning-offer(7), lightning-fetchinvoice(7), lightning-sendinvoice(7), lightning-commando-rune(7)
 
+RESOURCES
+---------
+
 [BOLT #11](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md)
 
 [BOLT #12](https://github.com/rustyrussell/lightning-rfc/blob/guilt/offers/12-offer-encoding.md) (experimental, [bolt](https://github.com/lightning/bolts) #798)
 
-
-RESOURCES
----------
-
 Main web site: <https://github.com/ElementsProject/lightning>
 
 [comment]: # ( SHA256STAMP:d62327dbe56d27e5e82d5ad2599d3d88495cc8360d84ff02fca59d08ab7fa14e)

doc/lightning-decodepay.7.md

@@ -63,12 +63,11 @@ SEE ALSO
 
 lightning-pay(7), lightning-getroute(7), lightning-sendpay(7).
 
-[BOLT
-\#11](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md).
-
 RESOURCES
 ---------
 
+[BOLT #11](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md)
+
 Main web site: <https://github.com/ElementsProject/lightning>
 
 [comment]: # ( SHA256STAMP:14c7dd565178078d7073e2837ad283a1e811affb5017e72c69e69d9f8c2baabd)

doc/lightning-deldatastore.7.md

@@ -29,6 +29,9 @@ On success, an object is returned, containing:
 
 [comment]: # (GENERATE-FROM-SCHEMA-END)
 
+ERRORS
+------
+
 The following error codes may occur:
 
 - 1200: the key does not exist

doc/lightning-delpay.7.md

@@ -32,6 +32,7 @@ EXAMPLE JSON REQUEST
 }
 ```
 
+
 RETURN VALUE
 ------------
 

doc/lightning-emergencyrecover.7.md

@@ -9,22 +9,17 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-The **emergencyrecover** RPC command fetches data from the emergency.recover
-file and tries to reconnect to the peer and force him to close the channel.
-The data in this file has enough information to reconnect and sweep the funds.
+The **emergencyrecover** RPC command fetches data from the emergency.recover file and tries to reconnect to the peer and force him to close the channel. The data in this file has enough information to reconnect and sweep the funds.
 
-This recovery method is not spontaneous and it depends on the peer, so it should
-be used as a last resort to recover the funds stored in a channel in case of severe
-data loss.
+This recovery method is not spontaneous and it depends on the peer, so it should be used as a last resort to recover the funds stored in a channel in case of severe data loss.
 
 RETURN VALUE
 ------------
 
 On success, an object is returned, containing:
 
-- **stubs** (array of hexs):
-  - Each item is the channel ID of the channel successfully inserted
-
+- **stubs** (array of strings)
+  - Channel IDs of channels successfully inserted.
 
 AUTHOR
 ------
@@ -41,4 +36,4 @@ RESOURCES
 
 Main web site: <https://github.com/ElementsProject/lightning>
 
-[comment]: # ( SHA256STAMP:9cfaa9eb4609b36accc3e3b12a352c00ddd402307e4461f4df274146d12f6eb0)
+[comment]: # ( SHA256STAMP:678c253c9bbd957d0d7f458d4697a66cad4cd7dc4c64b5f650e0e6a1c32d4c9f)

doc/lightning-fetchinvoice.7.md

@@ -19,32 +19,6 @@ If **fetchinvoice-noconnect** is not specified in the configuation, it
 will connect to the destination in the (currently common!) case where it
 cannot find a route which supports `option_onion_messages`.
 
-*amount\_msat* is required if the *offer* does not specify an amount
-at all, otherwise it is optional (but presumably if you set it to less
-than the offer, you will get an error from the issuer).
-
-*quantity* is is required if the *offer* specifies
-*quantity\_max*, otherwise it is not allowed.
-
-*recurrence\_counter* is required if the *offer*
-specifies *recurrence*, otherwise it is not allowed.
-*recurrence\_counter* should first be set to 0, and incremented for
-each successive invoice in a given series.
-
-*recurrence\_start* is required if the *offer*
-specifies *recurrence\_base* with *start\_any\_period* set, otherwise it
-is not allowed.  It indicates what period number to start at.
-
-*recurrence\_label* is required if *recurrence\_counter* is set, and
-otherwise is not allowed.  It must be the same as prior fetchinvoice
-calls for the same recurrence, as it is used to link them together.
-
-*timeout* is an optional timeout; if we don't get a reply before this
-we fail (default, 60 seconds).
-
-*payer\_note* is an optional payer note to ask the issuer to include
-in the fetched invoice.
-
 RETURN VALUE
 ------------
 

doc/lightning-fundchannel.7.md

@@ -4,75 +4,23 @@ lightning-fundchannel -- Command for establishing a lightning channel
 SYNOPSIS
 --------
 
-**fundchannel** *id* *amount* [*feerate*] [*announce*] [*minconf*]
-[*utxos*] [*push\_msat*] [*close\_to*] [*request\_amt*] [*compact\_lease*]
-[*reserve*]
+**fundchannel** *id* *amount* [*feerate*] [*announce*] [*minconf*] [*push_msat*] [*close_to*] [*request_amt*] [*compact_lease*] [*utxos*] [*mindepth*] [*reserve*]
 
 DESCRIPTION
 -----------
 
-The **fundchannel** RPC command opens a payment channel with a peer by
-committing a funding transaction to the blockchain as defined in BOLT
-\#2.
-If not already connected, **fundchannel** will automatically attempt
-to connect if C-lightning knows a way to contact the node (either from
-normal gossip, or from a previous **connect** call).
-This auto-connection can fail if C-lightning does not know how to contact
-the target node; see lightning-connect(7).
-Once the
-transaction is confirmed, normal channel operations may begin. Readiness
-is indicated by **listpeers** reporting a *state* of `CHANNELD_NORMAL`
-for the channel.
-
-*id* is the peer id obtained from **connect**.
-
-*amount* is the amount in satoshis taken from the internal wallet to
-fund the channel (but if we have any anchor channels, this will always leave at least `min-emergency-msat` as change). The string *all* can be used to specify all available
-funds (or 16777215 satoshi if more is available and large channels were not negotiated with the peer). Otherwise, it is in
-satoshi precision; it can be a whole number, a whole number ending in
-*sat*, a whole number ending in *000msat*, or a number with 1 to 8
-decimal places ending in *btc*. The value cannot be less than the dust
-limit, currently set to 546, nor more than 16777215 satoshi (unless large
-channels were negotiated with the peer).
-
-*feerate* is an optional feerate used for the opening transaction and
-(unless *option\_anchors\_zero\_fee\_htlc\_tx* is negotiated), as initial feerate
-for commitment and HTLC transactions (see NOTES in lightning-feerates(7)).
-The default is *normal*.
-
-*announce* is an optional flag that triggers whether to announce this
-channel or not. Defaults to `true`. An unannounced channel is considered
-private.
-
-*minconf* specifies the minimum number of confirmations that used
-outputs should have. Default is 1.
-
-*utxos* specifies the utxos to be used to fund the channel, as an array
-of "txid:vout".
-
-*push\_msat* is the amount of millisatoshis to push to the channel peer at
-open. Note that this is a gift to the peer -- these satoshis are
-added to the initial balance of the peer at channel start and are largely
-unrecoverable once pushed.
-
-*close\_to* is a Bitcoin address to which the channel funds should be sent to
-on close. Only valid if both peers have negotiated `option_upfront_shutdown_script`.
-Returns `close_to` set to closing script iff is negotiated.
-
-*request\_amt* is an amount of liquidity you'd like to lease from the peer.
-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
-channel lease terms. If the peer's terms don't match this set, we will
-fail to open the channel.
-
-*reserve* is the amount we want the peer to maintain on its side of the channel.
-Default is 1% of the funding amount. It can be a whole number, a whole number
-ending in *sat*, a whole number ending in *000msat*, or a number with 1 to 8
-decimal places ending in *btc*.
+The **fundchannel** RPC command opens a payment channel with a peer by committing a 
+funding transaction to the blockchain as defined in BOLT #2.
 
+If not already connected, **fundchannel** will automatically attempt to connect if 
+Core Lightning knows a way to contact the node (either from normal gossip, or from 
+a previous **connect** call).
 
+This auto-connection can fail if Core Lightning does not know how to contact the 
+target node; see lightning-connect(7).
+
+Once the transaction is confirmed, normal channel operations may begin. Readiness 
+is indicated by **listpeers** reporting a *state* of `CHANNELD_NORMAL` for the channel.
 
 This example shows how to use lightning-cli to open new channel with peer 03f...fc1 from one whole utxo bcc1...39c:0
 (you can use **listfunds** command to get txid and vout):
@@ -82,17 +30,17 @@ This example shows how to use lightning-cli to open new channel with peer 03f...
 RETURN VALUE
 ------------
 
-[comment]: # (GENERATE-FROM-SCHEMA-START)
 On success, an object is returned, containing:
 
 - **tx** (hex): The raw transaction which funded the channel
 - **txid** (txid): The txid of the transaction which funded the channel
 - **outnum** (u32): The 0-based output index showing which output funded the channel
-- **channel\_id** (hex): The channel\_id of the resulting channel (always 64 characters)
-- **close\_to** (hex, optional): The raw scriptPubkey which mutual close will go to; only present if *close\_to* parameter was specified and peer supports `option_upfront_shutdown_script`
+- **channel_id** (hex): The channel_id of the resulting channel (always 64 characters)
+- **close_to** (hex, optional): The raw scriptPubkey which mutual close will go to; only present if *close_to* parameter was specified and peer supports `option_upfront_shutdown_script`
 - **mindepth** (u32, optional): Number of confirmations before we consider the channel active.
 
-[comment]: # (GENERATE-FROM-SCHEMA-END)
+ERROR
+------
 
 The following error codes may occur:
 
@@ -103,18 +51,16 @@ The following error codes may occur:
 - 303: Broadcasting of the funding transaction failed, the internal call to bitcoin-cli returned with an error.
 - 313: The `min-emergency-msat` reserve not be preserved (and we have or are opening anchor channels).
 
-Failure may also occur if **lightningd** and the peer cannot agree on
-channel parameters (funding limits, channel reserves, fees, etc.).
+Failure may also occur if **lightningd** and the peer cannot agree on channel parameters (funding limits, channel reserves, fees, etc.).
 
 SEE ALSO
 --------
 
-lightning-connect(7), lightning-listfunds(), lightning-listpeers(7),
-lightning-feerates(7), lightning-multifundchannel(7)
+lightning-connect(7), lightning-listfunds(), lightning-listpeers(7),lightning-feerates(7), lightning-multifundchannel(7)
 
 RESOURCES
 ---------
 
 Main web site: <https://github.com/ElementsProject/lightning>
 
-[comment]: # ( SHA256STAMP:a8329cdb3f13f5bd0047824bed82c2e10516af2735dc59aa2cd71e4cc4f0250a)
+[comment]: # ( SHA256STAMP:8f80263a6a56f45168d90a73ed72735ae53dbc7db64729aa38117959d8dfb54c)