It wasn't documented, and hopefully nobody was using it.
Changelog-Fixed: `decode` for bolt12 invoices "features" field renamed to "invoice_features" (as documentation said)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Turns out we weren't wiring them through! And libplugin wasn't reading them anyway.
Changelog-Fixed: lightningd: tell plugins our bolt12 features (so our bolt12 invoices explicitly allow MPP).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is deeply annoying, and we may have to support this properly
(using a separate algorithm entirely) if other implementations don't
fix their crap.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: xpay: suppress multi-part payment if invoice doesn't allow it (please, fix your nodes!)
This is an inefficient hack. Can you tell I really didn't want to
implement this? MPP was finalized in 2018 FFS.
We do this by adding another "auto" layer, which removes all too-small
channels, and then makes our MPP node pile all the funds into the largest
channel it chooses.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, if the total amount we're sending is less than the minimum amount
the channel insists on, we can eliminate it.
This fixes the problem that we're really trying to send a de-minumus
amount (rather than the more obscure case where we divide the amount
and then it is below the minimum).
After trying several other approaches, this was by far the cleanest!
Reported-by: https://github.com/JssDWt
Fixes: https://github.com/ElementsProject/lightning/issues/8045
Changelog-Fixed: xpay: don't simply give up if our total amount is less than htlc_minimum_msat on some channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Suggested-by: Matt Corallo
Fixes: https://github.com/ElementsProject/lightning/issues/7806
Changelog-Changed: Offers: we will use a blinded path if we have no advertized address (so payers wouldn't be able to connect directly).
I should have done this immediately after last release :(.
This turns various things off by default, even if deprecated APIs are enabled.
We remove the test of the to-be-removed params.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Deprecated: Config: `rest-port`, `rest-protocol`, `rest-host` and `rest-certs` disabled by default (use clnrest-*, or `i-promise-to-fix-broken-api-user=rest-port.clnrest-prefix` etc and PLEASE REPORT if you need this!)
Changelog-Deprecated: Config: `max-locktime-blocks` disabled by default (use `i-promise-to-fix-broken-api-user=max-locktime-blocks` and PLEASE REPORT if you need this!)
These are about to start logging warnings, so use modern versions for tests
which aren't explicitly about testing obsolete ones.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This happened in CI:
```
algrind error file: valgrind-errors.16800
==16800== Thread 4 tokio-runtime-w:
==16800== Conditional jump or move depends on uninitialised value(s)
==16800== at 0x2466BF: _ZN175_$LT$axum..middleware..from_fn..FromFn$LT$F$C$S$C$I$C$$LP$T1$C$T2$C$T3$RP$$GT$$u20$as$u20$tower_service..Service$LT$http..request..Request$LT$axum_core..body..Body$GT$$GT$$GT$4call28_$u7b$$u7b$closure$u7d$$u7d$17h4cc36de5dd56d9feE.llvm.119371497468325184 (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x57BFFA: <axum::middleware::from_fn::ResponseFuture as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x37312B: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372D8D: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372F59: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x373A88: <tower::util::map_response::MapResponseFuture<F,N> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x32100D: <tower::util::oneshot::Oneshot<S,Req> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x38E326: _ZN91_$LT$axum..routing..route..RouteFuture$LT$E$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h3f11114fc5dd51f8E.llvm.194396656150191000 (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372315: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x372C05: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x371A15: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800== by 0x373A48: <tower::util::map_response::MapResponseFuture<F,N> as core::future::future::Future>::poll (in /home/runner/work/lightning/lightning/plugins/clnrest)
==16800==
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Searches the first unused groupid and uses that number for the current
payment attempt.
We previously used the highest value of used groupid + 1, which breaks
in a few corner cases.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Change functions json_pay and json_paystatus to json_renepay
and json_renepaystatus to match the conventional naming.
This is helpful for grep searches.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
On lookup, we update the htable if any new addresses have been added.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: startup time vastly improved for large nodes with pending closes and many bitcoin addresses.
It was long obsoleted, and never appears in the DB, but we do still have
to handle old ones in the code.
We removed it from the enum in
f342630b92 (v24.02) after deprecating it
in 23.02.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From Whitslack's "startup takes 15 minutes" bug report, we can see
that wallet_can_spend is extremely slow. We exacerbate this by setting a large
bip32_max_index:
```
91.29% 0.02% lightningd lightningd [.] wallet_can_spend
|
--91.27%--wallet_can_spend
|
|--47.81%--scriptpubkey_p2tr_derkey
| |
| |--42.80%--scriptpubkey_p2tr
...
|--42.16%--bip32_key_from_parent
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In a previous [commit](https://github.com/ElementsProject/lightning/pull/8065/commits), I mistakenly removed the `lightning-` replacement logic from the base name also. This commit restores that functionality to re-enable schema checks.
Changelog-None.
When paying with injectpaymentonion we need to manually decode the error
from the onion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Always use a fake destination node, the self-payments are no longer a
corner case for the routing problem in this way. Also it is ok for
get_routes to return routes with zero length.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Use injectpaymentonion for payments with |routes|=0,
ie. self-payments and blinded paths where our node is
the first node in the blinded path.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Collect the shared secrets when making a payment request.
We would need this if we use injectpaymentonion instead of sendonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Refactor create_onion function, now we could use the same function to
build onions for sendonion and injectpaymentonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
sendonion RPC does not allow to set the total amount in lightningd's
wallet, therefore it mixing sendpay and sendonion payment parts would
not work. That means for the time being we cannot complete a payment
initialized with sendpay until we add a total_amount parameter to
sendonion.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Fix error handling since we moved from sendpay to sendonion rpc.
With sendonion once a route fails we don't get the scid and node_id that
failed along the route, so we have to deduce those from our own internal
data.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Use renesendpay to send the payment allowing to pay to BOLT12 invoices
from a higher level interface.
Changelog-Add: renepay: Add support for BOLT12 payments
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changing route.amount to route.amount_deliver
for clarity. This variable hold the value that
the route delivers to destination.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Add an rpc to renepay that is similar to sendpay that
handles BOLT11 and BOLT12 payments.
This is not the most elegant solution but it is a workaround
until we implement it into lightningd which has more development
friction.
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
