- bitcoin/chainparams.c:
- Fix mainnet RPC port 2333 → 2332 (was the P2P port)
- Fix regtest RPC port 28444 → 12443 (verified against palladiumcore)
- Add missing testnet entry (tplm, RPC 12332, P2P 19735, P2PKH 127/P2SH 115)
- Reset when_lightning_became_cool to 1 (no Bitcoin-specific block reference)
- Add operational notes: Resilience Fork at block 340,000 (2 min blocks),
Taproot via BIP9 on mainnet / ALWAYS_ACTIVE on regtest
- common/configdir.c:
- Fix --network help text to list palladium/testnet/regtest
- Fix --mainnet alias description (bitcoin → palladium)
- configure: make lowdown optional (warning, not fatal); only needed for man pages
- lightningd/: replace all remaining "bitcoind/bitcoin network" log messages
with "palladiumd/palladium network" (dual_open_control.c, opening_control.c,
peer_htlcs.c)
- .gitignore: add ccan/config.h.* (PIDs left by build system)
This commit finalizes the integration of Palladium Lightning with
the Palladium Core backend, making it trivial for developers to
spin up and test a local regtest network.
Key changes:
- Created [TESTING_PALLADIUM.md](cci:7://file:///home/davide/lightning-plm/TESTING_PALLADIUM.md:0:0-0:0) with comprehensive regtest instructions.
- Linked the new testing guide in the main [README.md](cci:7://file:///home/davide/lightning-plm/README.md:0:0-0:0).
- Ignored `/palladium-bin/` in `.gitignore` to allow developers to drop
backend binaries locally without accidentally committing them.
- Patched `contrib/startup_regtest.sh` to automatically detect and use
these local `palladiumd`/`palladium-cli` binaries if present, removing
the strict need to manually export environment variables.
- Fixed a false-positive timeout error in `startup_regtest.sh` when
parsing the absent `clnrest` plugin logs
Unfortunately the effect of leaving Nagle enabled is subtle. Here it
is in v25.12:
Normal:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 13.87s
Nagle enabled:
tests/test_connection.py::test_no_delay PASSED
====================================================================== 1 passed in 21.70s
So it's hard to both catch this issue and not have false positives. Improve the
test by deliberately running with Nagle enabled, so we can do a direct comparison.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This test restarts l2 twice. Each time, l1 is reconnecting, and backs
off. If the test is slow enough, the backoff gets extreme:
```
2026-02-19T02:13:03.7669982Z lightningd-1 2026-02-19T01:50:56.541Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-lightningd: peer_disconnected
2026-02-19T02:13:03.7670444Z lightningd-1 2026-02-19T01:50:56.547Z DEBUG 033845802d25b4e074ccfd7cd8b339a41dc75bf9978a034800444b51d42b07799a-connectd: Will try reconnect in 256 seconds
```
This isn't a bug! The backoff caps at 300 seconds, and only gets
reset if we remain connected for that long.
A manual reconnect here not only fixes the flake, but make the test
much faster, by not *doubling* the time for slow tests as shown on my
laptop (the final test using `taskset -c 1`):
Normal Valgrind Valgrind, 1 CPU
Before: 22sec 124sec 230sec
After: 18sec 102sec 191sec
These are from a single run: it could be much more in the worst case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
With the extra padding pings, we can get more!
```
# Make sure the noise is within reasonable bounds
assert tally['query_short_channel_ids'] <= 1
assert tally['query_channel_range'] <= 1
> assert tally['ping'] <= 3
E assert 4 <= 3
tests/test_gossip.py:2396: AssertionError
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
xpay can get upset if askrene goes away first:
lightningd-1 2026-02-18T02:47:44.908Z **BROKEN** plugin-cln-xpay: askrene-create-layer failed with {"code":-32601,"message":"Unknown command 'askrene-create-layer'"}
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I noticed this in the logs:
```
lightningd-1 2026-01-28T00:27:37.504Z DEBUG gossipd: gossip_store: Read 59428/118856/0/0 cannounce/cupdate/nannounce/delete from store in 45521871 bytes, now 45521849 bytes (populated=true)
lightningd-1 2026-01-28T00:27:37.504Z DEBUG gossipd: Got 118856 bad cupdates, ignoring them (expected on mainnet)
```
That's weird, and turns out it counting good updates, not bad ones!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This speeds them up, and exercises the askrene parallel code.
Before: test_real_data: 348s test_real_biases: 105s
After: test_real_data: 133s test_real_biases: 106s
And this is because much of the time is spent uncompressing the gossmap
and startup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
Add `test_bcli_concurrent` to verify bcli handles concurrent requests while the `getblockfrompeer` retry path is active, simulating a pruned node scenario where `getblock` initially fails.
Add `test_bcli_retry_timeout` to verify lightningd crashes with a clear error message when we run out of `getblock` retries.
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.
Rewrite `test_bitcoin_failure` to reflect synchronous bcli behavior: the node now crashes on invalid bitcoind responses rather than retrying. Add `may_fail` and `broken_log` to handle expected crash.
Update `test_bitcoind_fail_first` stderr check to match the new error message format from `get_bitcoin_result`.
Update test mocks to use proper error format for "block not found".
Co-authored-by: ShahanaFarooqui <shahana.farooqui@gmail.com>
Add `get_bitcoin_result` function that checks bcli plugin responses for errors and returns the result token. Previously, callbacks only detected errors when result parsing failed, ignoring the explicit error field from the plugin. Now we extract the actual error message from bcli, providing clearer reasoning when the plugin returns an error response.
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.
Since we delay the others quite a lot (up to 1 second), it's better to consider
most messages "urgent" and worth immediately transmitting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Messages are now constant.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Added: Protocol: we now pad all peer messages to make them the same length.
