This is not worth optimizing that I can see. Using a non-debug build I get
the following times for tests/test_askrene.py::test_real_data
Before:
143 seconds
After:
141 seconds.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I added amount_msat_accumulate for the "a+=b" case, but I was struggling
with a name for the subtractive equivalent. After some prompting, ChatGPT
suggested deduct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is immune to things like clock changes, and has the convenient side-effect that
it will *not* be overridden when we override time for developer purposes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This doesn't happen much in real life, but it's certainly possible, so do what pay does here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8612
Changelog-Added: `xpay` will now wait if it suspects a payment failure is due to a height disagreement with the final node.
Changelog-Added: askrene-bias-node: an RPC command to set a bias on node's outgoing or incoming channels.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We add one more field to biases: "timestamp".
With the timestamp variable old biases can be removed with the
askrene-age command.
Changelog-Added: Plugins: askrene channel biases now have an associated timestamp, and are timed out by askrene-age
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
For example, `autoclean-once failedforwards` would count every non-failed forwards
as "uncleaned".
This is both technically correct and completely useless.
Changelog-Fixed: JSON-RPC: `autoclean-once` returns "uncleaned" number reflecting number of candidates which were too new to be cleaned, not all records we didn't delete.
Fixes: https://github.com/ElementsProject/lightning/issues/8632
Reported-by: @grubles and several other sharp-eyed users.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a custom request type for the on_openchannel hook to
avoid calling unwrap() during runtime. We now return cleanly from the
hook in any case.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The extra_fee tlv appended to the update_add_htlc message is set by the
LSP and should specify what was deducted from a single htlc. If it does
not match the expected amount, we log a warning message.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We nearly always want to return `{"result":"continue"}` in case that
something went wrong. This commits adds two helper macros that help us
to cleanly return from a hook while logging necessary information.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
The `on_invoice_payment` hook is called when core-lightning successfully
collected all parts to an invoice. We'll use this to clean up the the
datastore when an invoice completes.
Caveat: This will be called on every succesfull invoice payment, we may
improve this in the future.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This includes a mocked lsps2 service plugin, tests and some changes on
the client side. The client now can accept mpp payments for a
jit-channel opening from a connected LSP.
Changelog-Added: Lsps2 `fixed-invoice-mpp` mode for the lsps2 client
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We use non-anchor channels for now and make this configurable in the
future. The reason for this decission is that elements does not support
anchors.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
please `connect` tests. We need to fix this in the future. Connectd
should not tell peers about features of disabled plugins.
We need to ensure that connectd only starts once the plugins have
returned from init.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This slipped in during development but actually, we don't want to mess
with the channel reservere here.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Replace ensure_lsp_connected() by check_peer_lsp_status() which only
returns the status of the peer (connected, has_lsp_feature). This allows
us to be more tolearant about the LSP feature bit since it is only
optional according to the spec.
We still check for the feature but only return a warning in the logs.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Core-Lightning returns the feature-bits in reversed order but we don't
want to rely on the caller to reverse the u8 slice themselfs. This
commit adds a convenience function that reverses the bitmap to avoid
hard to debug mistakes.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We don't need to separately enable lsp and lsps2 services. If lsps2 is
not enabled what can we do with just the messaging layer?
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Calling lsps_jitchannel we want to pass through the label and
description parameters used to call `invoice` to keep the api close to
Core-Lightning
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Adds the full roundtrip to request a jit channel from the LSP. It
approves the jit scid returned by the LSP and returns the invoice with
the corresponding route-hint.
Changelog-Added Experimental support for LSPS2 no-MPP,
Lsps-trusts-client mode. See
https://github.com/lightning/blips/blob/master/blip-0052.md for further
details.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Adds the service side (LSP) for a simple no-mpp trusted jit channel
opening. This is only an intermediate step, we are going to add support
for multiple htlcs.
This is experimental and can drain on-chain fees from the LSP if used in
public.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
This commit adds the lsps2_get_info call defined by BLIP052. It also
adds a test policy plugin that the LSP service plugin uses to fetch the
actual fee menu from to separate the concerns of providing a spec
compliant implementation of an LSP and making business decisions about
fee prices.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We need to somehow access the peer id in the jrpc server to know where
the response should go. This seems to be the most convenient way for
now. We may unclutter this in the future if this results in performance
issues.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
They are invalid! This is because our BOLT11_FIELD_BYTE_LIMIT is not the limit,
it's one greater than the limit.
Reported-by: https://github.com/noblepayne
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `invoice` no longer accepts 640-byte descriptions (it would produce malformed invoices).
The keysend plugin previously used `> 1023` as the cutoff for
description length when inserting an invoice. This was
inconsistent with invoice.c, which enforces the BOLT11 description
field limit defined in `common/bolt11.h`.
This patch switches to using `BOLT11_FIELD_BYTE_LIMIT` directly.
As a result, keysend no longer fails on descriptions between
641–1023 bytes, which previously caused unexpected failures.
A new regression test (`test_keysend_description_size_limit`)
exercises boundary cases just below, at, and above the limit.
Changelog-Fixed: Protocol: `keysend` with descriptions of length 640-1023 bytes fixed.
Signed-off-by: Wes Payne <noblepayne@noblepayne.com>
We also document this in the listnetworkevents command itself.
The test_autoclean_once was getting repetitive, so I cleaned that
up too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: `autoclean` will remove networkevents after 30 days by default.
This makes a big difference for large tables. Consider 1.6M channelmoves,
which took 82 seconds to populate, now takes 17 seconds:
Before:
plugin-sql: Time to call listchannelmoves: 10.380341485 seconds
plugin-sql: Time to refresh channelmoves: 82.311287310 seconds
After:
plugin-sql: Time to call listchannelmoves: 9.962815480 seconds
plugin-sql: Time to refresh channelmoves: 15.711549299 seconds
plugin-sql: Time to refresh + create indices for channelmoves: 17.100151235 seconds
tests/test_coinmoves.py::test_generate_coinmoves (50,000):
Time (from start to end of l2 node): 27 seconds
Worst latency: 16.0 seconds
Changelog-Changed: Plugins: `sql` initial load for tables is much faster (e.g 82 to 17 seconds for very large channelmoves table).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we're synchronous, these only reach lightningd after we're done:
in the case of 1.6M channelmoves, that can give it major heartburn.
In practice, this reduces the first bkpr command on a fresh upgrade
from 349 to 235 seconds (but this was before other improvements we did
this release).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: Plugins: `bookkeeper` reduced logging for large imports to increase speed.
