Sometimes we don't know the short_channel_id yet (e.g the channel has
not been broadcasted), but we still know the channel_id from the funding
transaction. Add a channel_id filter to listpeerchannels and clarify
that id, short_channel_id and channel_id are mutually exclusive.
Changelog-Added: `listpeerchannels` now accepts a `channel_id` filter,
for cases where the `short_channel_id` is not known yet.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
For CI we want to make sure we don't rebuild. CC=false doesn't work because
we reply on the output of "$CC -dumpmachine" for the external build directory.
So we would use:
make CC=devtools/cc-nobuild CARGO=false
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The next commit makes us honor these when issuing a payment.
Changelog-Added: JSON-RPC: `offer` now has a `fronting_nodes` option to specify neighbors for payer to use to fetch invoices and make payments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is how modern plugins do it, and it has the benefit of not
requiring extra code for memleak tracking.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: libplugin: support for options which accumulate if specified more than once ("multi": true).
We remove the auxiliary RPC renesenday (only used internally) in favor
of a function that builds the onion, stores the shared secrets
needed to recover the onion reply, and calls sendonion/injectpaymentonion.
This solves a concurrency race
```
**BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
```
in which we are waiting for renesenday to return in order to record the shared
secrets but we get the a sendpay_failure notification with an onionreply
before we have secrets to decode it.
It also solves a missing JSON id seen in the logs
```
DEBUG plugin-cln-renepay: JSON reply with unknown id
```
because renesendpay was using his command variable to issue an RPC
to sendonion/injecpaymentonion and would fail or succeed the command
before those RPCs were done. This also meant that the callback
functions were silently being ignored.
Changelog-Fixed: renepay: fixes a race condition that leads to **BROKEN** plugin-cln-renepay: Unable to parse sendpay_failure
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This makes sure it cannot interfere with the parent askrene's
connection to lightningd, for example.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The fork logic itself is pretty simple, so do that directly in
askrene.c, and then call into "run_child()" almost as soon as
we do the fork.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Queue them before we query local channels, so they don't use stale
information.
Changelog-Added: Config: `askrene-max-threads` to control how many CPUs we use for routing (default 4).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Notably no access to the struct command and struct plugin.
Note: we actually *do* mess with askrene->reserves, but the previous code
used cmd to get to it. Now we need to include a non-const pointer in
struct route_query.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to make it clear when future generations edit the code, which
routines are called in the child (i.e. all the routing), and which in
the parent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is fairly simple. We do all the prep work, fire off the child,
and it continues all the way to producing JSON output (or an error).
The parent then forwards it.
Limitations (fixed in successive patches):
1. Child logging currently gets lost.
2. We wait for the child, so this code is not a speedup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We reimplemented this redundantly: hash_scid was called
short_channel_id_hash, so I obviously missed it.
Rename, and implement hash_scidd helper too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Return "not found" on any `getblockhash` exit status. Previously, only exit code 8 (block height doesn't exist) returned "not found", while other exit codes returned an error. Now any non-zero exit status returns "not found" since any failure means the block is unavailable.
Remove the asynchronous execution infrastructure no longer needed after converting all bcli commands to synchronous execution. This includes removing the async callbacks, the pending request queue, etc.
Fix missing `close(from)` file descriptor leak in `run_bitcoin_cliv`.
Changelog-Changed: bcli plugin now uses synchronous execution, simplifying bitcoin backend communication and improving error handling reliability.
Also rename command_err_badjson to generic command_err helper, since error messages aren't always about bad JSON (e.g., "command failed" for non-zero exit).
Add `command_err_badjson` helper for sync error handling, mirroring the async `command_err_bcli_badjson`. Store args string in `bcli_result` for consistent error messages.
It's used by common/gossip_store.c, which is used by many things other than
gossipd. This file belongs in common.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we can't decode something, and it decodes as a rune (and all bech32
strings do!), then we would usually just complain it was a malformed
rune. Be a big more useful, when the parameter looks like somthing else.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `decode` is now more informative with malformed strings (won't claim everything is a malformed rune!).
Changelog-Fixed: askrene: fixed a class of corner cases that cause askrene main loop to timeout instead of quickly failing, thus wasting runtime.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We would try to explain a failure by simply finding a path between
source and destination and then checking the constraints.
However, we did not add fees.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: askrene: add a new layer auto.include_fees thhat makes fees be deducted from the payment amount making in effect the receiver pay for routing fees.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
