The `chainlag` is defined as the positive difference between the
height of the last block processed by the node and the best height
known by the bitcoin backend. The chainlag is positive when we are
still catching up with the blockchain, and `0` otherwise.
The `chainlag` is used as an additional offset to the CLTV values when
sending payments, allowing payments to be sent even before the chain
sync completes.
Listpeerchannels would update the local channel information setting the
liquidity in the outgoing channel to known_min=known_max=capacity,
when in fact it should be known_min=known_max=spendable.
The route-builder checks the liquidity bounds of each route one at a
time. Every route that satisfy the contraints is recorded in the
uncertainty network and produces an HTLC burden on the channels it uses,
so that the following routes cannot count on the same liquidity twice.
Routes contain only routing information and the payment they're linked
to can be obtained through the payment_hash. We remove the dependency of
route building routines from the payment itself. In order to make
plain payment information available we define a payment_info structure.
- use switch case over all possible WIRE_* errors,
- remove the virtual machine for routefail, use a simple two step
solution: 1. update the gossip and 2. handle error cases
Using enum renepay_errorcode simplifies the low level API of chan_extra and flow.
We can extract information about the nature of a function call failure
from its return value.
Routefail consist mainly of an API `routefail_start` that handles the
failure of a forwarding request (encoded in a route). Internally there
is a routefail datastructure that goes through a series of execution
steps, eg. updating the gossmap, updating the uncertainty network, etc.
Routebuilder constitute the module that builds the routes we try in the
payment. The public API is simply `get_routes`, it replaces the similar
interface for pay_flows.
Add a new implementation of the payment state machine.
This is based in the `pay` plugin concept of payment modifiers,
but here we take it to the next level.
The payment goes through a virtual machine that includes calling
functions and evaluating conditions.
We need to pass through setconfig in check mode, then we need to have libplugin
add (and use!) a `check_only` parameter to all option setting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: JSON-RPC: `check` `setconfig` on plugin options can now check the config value would be accepted.
We don't thoroughly handle `check setconfig`: it would be good to
allow this to do further checking!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to extend it to plugins, and we want it to be allowed to be async for more power,
so rather than not completing the cmd if we're checking, do it in command_check_done()
and call it.
This is cleaner than the special case we had before, and allows check to us all the
normal jsonrpc mechanisms, especially async requests (which we'll need if we want to
hand check requests to plugins!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
gcc-12 (Ubuntu 12.3.0-9ubuntu2) 12.3.0 with -O3 gives:
```
In file included from plugins/renepay/test/../mcf.c:5,
from plugins/renepay/test/run-arc.c:13:
ccan/ccan/tal/str/str.h: In function ‘minflow’:
ccan/ccan/tal/str/str.h:43:9: error: ‘errmsg’ may be used uninitialized [-Werror=maybe-uninitialized]
43 | tal_fmt_(ctx, TAL_LABEL(char, "[]"), __VA_ARGS__)
| ^~~~~~~~
plugins/renepay/test/../mcf.c:1565:15: note: ‘errmsg’ was declared here
1565 | char *errmsg;
| ^~~~~~
cc1: all warnings being treated as errors
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Creates an example package that subscribes to all notifications and logs
them. This is useful for testing the behavior of subscribing to "*".
I've also edited the Makefile to ensure that `make` builds the example
and that `make clean` removes the example
Uncommited channels are missing several fields which would normally be
populated by an active channel. This simply skips them for the purposes
of finding a route. The particular culprit was:
{
"peer_id": "038cd9f3679d5b39bb2105978467918d549572de472f07dd729e37c7a6377d41d5",
"peer_connected": true,
"state": "OPENINGD",
"owner": "lightning_openingd",
"opener": "local",
"to_us_msat": 8317559000,
"total_msat": 8317559000,
"features": [
"option_static_remotekey",
"option_anchors_zero_fee_htlc_tx"
]
}
Fixes#7197 - SEGV in direct_pay_listpeerchannels when field private missing
Changelog-Fixed: Fixed crash in pay plugin caused by parsing uncommitted dual open channels
- Updated config params and plugin
- Updated documentation
Changelog-Added: Added a new configuration for clnrest plugin to change the default Swagger UI path from `/` to custom url.
`getblockfrompeer` was introduced in v23.0.0, we want to skip this path
if the version of bitcoind used is below that.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
In the case that we have peers left in the peers array and that we could
not find the block yet, we ask the next peer for the desired block.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We introduce the peers array that contains the known set of connected
peers for future reference in case that we couldn't find the block we
are looking for.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We move the `geblock` call into a separate function. This allows us to
call if from various places in the future.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This allows us to intercept getblock on a non 0 exit when the block was
not found. We fill this with something meaningull in future commits.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
