This was supposed to be removed in v24.05. Finally remove it now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: lightningd: `estimatefeesv1` support for older bcli plugins (deprecated v23.05, disabled by default v24.05).
This was changed in v0.9.2 (November 2020), with a comment saying to remove.
But it turns out that the rust plugin support still uses the old
method (found this by removing it and watching everything fail!). So
simply undeprecate and document.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Removed: JSON-RPC: `close` `tx` and `txid` field (use `txs` and `txids`), deprecated v24.11.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Everyone should be using the new name.
Changelog-Removed: JSON-RPC: `listpeers` `features` array string "option_anchors_zero_fee_htlc_tx": use "option_anchors" (spec renamed it). Deprecated in 24.08.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I tried removing sign_penalty_to_us, but that comment is wrong: channeld
uses that for the watchtower, so it stays (with updated comment).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means:
1. downgrade changes (we no longer fail due to node biases).
2. various deprecations no longer are
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The code had this as 26.03, but the documentation said 26.06. The
usual deprecation period is a year, so I'm changing the documentation.
Unfortunately the documentation (fe4d5036c2) was updated separately
from the code (afb54ff8e8), so this wasn't obvious at the time!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The giant text lines make emacs ... run... slowly. Finally got around to fixing it
to see that it had already been done, just not updated!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
- Using environment variable `SOURCE_DATE_EPOCH` with fixed value will enforce a consistent timestamp for Fedora build.
. Similar to Ubuntu fix in commit 490fb0fc3b
- Locked cargo version
- Add `no-cache` to Fedora build
Changelog-Fixed: Core lightning builds for Fedora on all systems are deterministic.
- Upgraded Fedora base image from 35 to 40. The existing Cargo failures were caused by the outdated Rust toolchain in Fedora 35. Cargo lockfile format v4 was introduced in Cargo 1.84 (December 2024), while Fedora 35 provides a Rust/Cargo version from roughly 2021–2022. As a result, the system Cargo could not parse modern Cargo.lock files, making it incompatible with current Rust projects.
- Added missing build dependencies to the Dockerfile, most notably the protobuf compiler (protoc).
Changelog-None: Upgraded Fedora version to 40 for reproducible build.
Even though we don't do taproot addresses on elements yet, use the
same scheme for simplicity and for future when we *do* do taproot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The recover command checks if a node has already issued bitcoin
addresses before allowing recovery. This check only looked at
bip32_max_index, but with BIP86 wallets, newaddr() increments
bip86_max_index instead.
Also, the recover test asserted on hex but now it's asserting on codex32 instead. We should probably go in and fix the end point. @rustyrussell what do you think?
listaddrs is dev only and used in tests so it's okay if we change the API here, the usage is by positional arguments in tests so we're okay. Also changing est_option_upfront_shutdown_script to handle both old hsmsecret and the newer mnemonic one.
The signmessagewithkey RPC was failing for BIP86 (mnemonic-based)
wallets because:
1. The wallet RPC was iterating through BIP32-derived addresses only,
so it couldn't find BIP86-derived addresses.
2. The HSM's handle_bip137_sign_message always used bitcoin_key()
(BIP32 derivation) regardless of wallet type.
When a peer doesn't support OPT_SHUTDOWN_ANYSEGWIT, we fall back to P2WPKH for the shutdown script. For BIP86 wallets, we need to use bip86_pubkey for derivation (matching p2tr_for_keyidx), otherwise the resulting script won't be recognized after restart.
When using the new BIP39 mnemonic HSM secret format, the wallet uses
BIP86 derivation for taproot addresses. However, onchaind_tx_unsigned() was always using bip32_pubkey() to derive the final key for penalty transaction outputs.
This is a fix from https://github.com/rauaap who correctly diagnosed the problem:
```
Error broadcasting transaction: error code: -26\nerror message\nmempool-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation), input 0 of ...
```
The decision to use the changed derivation for all addresses, not just
taproot, came up during review. Unfortunately, the signing code
(here) was not changed to match the address generation code (in the
wallet).
Reported-by: https://github.com/postanissue
Fixes: https://github.com/ElementsProject/lightning/issues/8804
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: lightningd: we now correctly sign for non-taproot addresses given by nodes created by v25.12 or newer.
