Changelog-Fixed: askrene: fix a plugin crash triggered during single path payments when a channel fees doesn't fit u32.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Rather than break the API, use total capacity here.
```
Valgrind error file: valgrind-errors.5880
==5880== Use of uninitialised value of size 8
==5880== at 0x4A390BB: _itoa_word (_itoa.c:183)
==5880== by 0x4A43C9B: __printf_buffer (vfprintf-process-arg.c:155)
==5880== by 0x4A69D90: vsnprintf (vsnprintf.c:96)
==5880== by 0x1875E6: json_out_addv (json_out.c:239)
==5880== by 0x14471E: json_add_primitive_fmt (json_stream.c:170)
==5880== by 0x144BA2: json_add_u64 (json_stream.c:282)
==5880== by 0x145E33: json_add_amount_msat (json_stream.c:619)
==5880== by 0x11DDE2: channel_hint_to_json (channel_hint.c:33)
==5880== by 0x11FE9F: channel_hint_notify_core (libplugin-pay.c:394)
==5880== by 0x11FF7A: channel_hint_notify (libplugin-pay.c:412)
==5880== by 0x1201EA: channel_hints_update (libplugin-pay.c:455)
==5880== by 0x122DAF: handle_intermediate_failure (libplugin-pay.c:1437)
==5880==
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means that we won't complain to peers which gossip about our
channels, but it does mean that our channel graph (like other nodes on
the network) will show two channels, not one, for the duration.
For this reason, we need askrene to omit local dying channels.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When paying through a direct channel, direct_pay_override() creates a
route bypassing the normal routing path, which skips the CLTV budget
check in payment_getroute(). This allows payments to succeed even when
maxdelay is set below the required min_final_cltv_expiry.
Add a check in direct_pay_override() to verify the required CLTV
doesn't exceed cltv_budget before using the direct channel shortcut.
If it exceeds, skip the direct channel and let normal routing handle
the failure with a proper error message.
Fixes: #8609
Changelog-Fixed: pay: `maxdelay` parameter now enforced for direct channel payments
Remove anyhow as a dependency from the tlv module. This allows for a
cleaner error handling
Changelog-None
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The core module shouldn't depend on anything from the cln_adapters
module. This ensures that we can switch out interfaces in the future
(e.g a different database than cln's datastore).
This change made it necessary to refactor the service plugin which
allowed us to clean it up on the go
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Separate concerns of the lsps2 modules into their respective layers:
core for tlv, as it is lightning related, not specifically
core-lightning. cln_adapters for core-lightning related types.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit separates the business logic from core-lighting behaviour
and moves the core-lightning related implementations into the
cln_adapters module.
Splits up tests as well
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This now only makes it easier to test, but also more modular. It allows
us to use any kind of storage, not only the datastore.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The ClnApi trait is way overloaded. We break things down to make it more
modular on the service side.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We replace the legacy transport by a slim custommsg hook that makes use
of the lightweight multiplexed transport and avoids deserialization and
serialization through this extra layer
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We can separate concerns here by adding a lightweight multiplexing
transport client. This helps us to clean up any direct dependencies on
CLN
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit replaces the lsps service. Therefore we add the cln_adapters
module that handles the communication with core-lightning. We add a
lightweight LspsService that wraps the router and allows handlers to
register themselves to the service/router.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This router is very lightweight and can handle routing for the lsps
service. It avoids allocations by just borrowing from the request. This
is much cleaner than what we have now and reduces the amount of
serializations by a lot.
Also it supports typed handlers which will remove serialization overhead
from the handlers in future commits
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
There is no need to communicate via a generic JsonRpcClient if all
messages are well defined and we can use the typed transport to remove a
whole lot of overhead and just pass the ResponseObjects directly to the
Transport layer
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Introducing "request" to the transport trait that uses the RequestObject
and JsonRpcResponse directly reduces some overhead and unnecessary
conversions. Why do we implement a generic transport over &str when we
already know that we are dealing with JSON-RPC 2.0 here.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
There is no need to generate the id in some client when we can actually
generate it on a lower layer as we know by LSPS0 how we have to generate
it.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
As we pass the peer_id through the transport methods, there is no need
to store the peer_id in the Bolt8Transport struct anymore
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Frankly, transport without a target doesn't make sense, so this commit
adds a PublicKey (from secp256k1) as the target to the Transport trait.
It can easily be replaced by a common PeerId without changing the api
for external implementations if needed in the future
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series of commits to make the lsps plugin crate
layered and modular for efficient reuse in external projects.
The core module is responsible for common business logic and interfaces
and acts as the intermediate layer for an actual implementation
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This makes it easier for client implementations to separate transport or
parser related issues from actuall json-rpc error responses. Also this
helps to segregate the individual responsibilities of the crates
further.
This further alows us to remove the error enum from proto/jsonrpc
completely as this now only deals as a from/to-wire module
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We can use an enum as a more idiomatic rust style to create and retreive
json-rpc responses. The actual response data is kept in the body enum
while the surrounding only holds the identifier.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
In order to create a sane dependecy structure for this crate, this
commit cleans up the jsonrpc error enum and shifts responsibilities
towards the transport client
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Split them up how they are actually defined.
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Those primitives are actually defined in lsps0
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit is part of a series that refactor the lsp plugin crate into
a modularized crate with the goal to separate the actual plugin runtime
as much as possible from library code to make it accessible for 3rd
party plugin implementations.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
describe_scidd() was labeling any channel as "the invoice's route hint"
when there was a single-hop route hint, even if the error occurred on
an unrelated intermediate channel.
Now we check the channel actually matches the route hint's
short_channel_id before using that label.
Fixes: #8252
Changelog-Fixed: xpay: error messages no longer incorrectly label intermediate channels as "the invoice's route hint".
