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 is important: if it's tor-only and we don't have a proxy, we will fail
to connect, but it's no indication that the node is unreachable. Same with
IPv6.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In some cases it is helpful to know who offered us the HTLC.
Changelog-Changed: Plugins: The `htlc_accepted` hook now knows the
`peer_id` of the peer that offered us the HTLC.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Okay, so I think this is what happened to me:
1) I had brew installed on my Intel Mac
2) I got an Apple Silicon Mac
3) I setup my new Mac by copying over Intel Mac harddrive
4) I now have two brew's installed on my machine:
a) /usr/local/bin/brew (for intel macs & cross-compiling)
b) /opt/homebrew/bin/brew (for (for apple silicon)
5) The wrong brew was in my path (a)
Looking through our getting started docs, we seem to reference both /usr/local/... and opt/homebrew/...
Update the installation document to mac this and related issues more clear for new users who might run into this problem.
Changelog-None
When running the integration test suite in a deeply nested directory
tree, the path name of the Unix domain socket might be longer than can
fit in a struct sockaddr_un. On Linux, we can use the /proc/self/cwd
trick to shorten the path name.
Changelog-Fixed: Integration tests no longer fail when run in a deeply nested directory on Linux.
Header changes in master broke this upon rebase :(
```
In file included from ./channeld/full_channel.h:5,
from tests/fuzz/fuzz-full_channel.c:7:
./channeld/channeld_htlc.h:13:28: error: field ‘amount’ has incomplete type
13 | struct amount_msat amount;
| ^~~~~~
./channeld/channeld_htlc.h:17:23: error: field ‘rhash’ has incomplete type
17 | struct sha256 rhash;
| ^~~~~
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Change in the fuzzing scheme of fuzz-hsm_encryption led to the
discovery of test inputs that result in greater in code coverage.
Add these inputs to the test's seed corpus.
[ Changed from fuzz-hsm_encryption to fuzz-hsm_secret --RR ]
Changelog-None: `fuzz-hsm_encryption.c` hard codes the lengths
sizeof(struct secret) as 32 and crypto_pwhash_argon2id_PASSWD_MAX
as 4294967295. Replace the latter with the former to improve
readability and maintainability.
While at it, replace the `tal_free()` call on our secret key with
`discard_key()`. This has the benefit of testing `discard_key()`.
[ Changed from fuzz-hsm_encryption to fuzz-hsm_secret --RR ]
Changelog-None: Functions defined in `channeld/full_channel.h`
contain channel operations like `ADD_HTLC`, `FULFILL_HTLC`,
`UPDATE_FEERATE`, etc.
Since they are a critical part of the HTLC state machine and may
be influenced by external agents, add a stateful test for them.
Changelog-None: `handle_onion_message()` in `connectd/onion_message.c`
is responsible for handling incoming onion messages from a peer.
Since it deals with external input, add a test for it.
This commit introduces a new field `invoice_msat` to the htlc_accepted
hook. If this field is specified it will replace the amount of the
invoice that belongs to the payment_hash of the HTLC on internal checks.
This is useful in scenarios where we actually expect a smaller amount
than initially specified in an invoice.
Changelog-Changed: Plugins: `htlc_accepted` hook can now override the
expected total amount of the invoice that belongs to the HTLC.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
Adds `expected_msat_override` to the `invoice_check_payment` check. If
it's set, it will be used to override the invoice amount as the expected
amount of the payment check.
This enables us to charge a different amount for a payment than the
amount stated on the invoice.
Signed-off-by: Peter Neuroth <pet.v.ne@gmail.com>
We're removing the hardcoded homebrew paths for openssl and sqlite as those folder paths may not be correct for all macOS users. Instead we are now calling brew --prefix to get the correct path and use that to populate the LDFLAGS and CPPFLAGS
Of course we still have to return a `bech32` for the deprecation period.
Changelog-Added: JSON-RPC: `newaddr` will now return a `p2tr` field by default.
Changelog-Deprecated: JSON-RPC: `newaddr` returning a `bech32` field if `addresstype` is not specified (use `p2tr`).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
If we failed after we register (e.g. channeld not available), we don't
mark it failed. We shouldn't register until we've definitely created
the htlc.
Changelog-Fixed: `xpay` would sometimes leave payment parts status `pending` in failure cases (as seen in listpays or listsendpays).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Fixes: https://github.com/ElementsProject/lightning/issues/8629
```
lightningd-1 2025-10-27T11:26:04.285Z **BROKEN** plugin-bcli: bitcoin-cli exec failed: Argument list too long
```
Use -stdin to bitcoin-cli: we can then handle arguments of arbitrary length.
Fixes: https://github.com/ElementsProject/lightning/issues/8634
Changelog-Fixed: plugins: `bcli` would fail with "Argument list too long" when sending a giant tx.
We call it once at the end, but calling on each allocation is
excessive, and it shows when dealing with large PSBTS. Testing a
700-input PSBT was unusably slow without this: after this the entire
test ran in 9 seconds.
Changelog-Fixed: JSON-RPC: Dealing with giant PSBTs (700 inputs!) is now much faster.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have another report of looping. This maxparts code is being completely
rewritten, but it's good to have a catchall for any other cases which might
emerge.
I had to make it customizable since our tests under valgrind are SLOW!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. We would find a flow.
2. refine_flow would reduce it so it doesn't deliver enough.
3. So we need to find another, but we are at the limit.
4. So we remove the flow we found.
5. Goto 1.
This can be fixed by disabling a channel which we caused us to reduce the flow,
so we should always make forward progress.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Plugins: `askrene` could enter an infinite loop when maxparts is restricted.
