fix: backport Lightning security update to rc66 for Bitkit 2.5.1

[piotr-iohk]

Apply the same three Lightning 0.2.7 dependency updates as the main-line security draft #123 to the source shipped as v0.7.0-rc.66 (190a17d). This keeps the newer coin-selection, explicit broadcast-result and prepared-payment/retry changes out of the proposed Bitkit 2.5.1 hotfix.

The base branch base/v0.7.0-rc.66 is an unchanged pointer to the released tag. This PR targets that base rather than reverting newer work on main. No Rust implementation or mobile API changes are included.

rc.66 did not commit a dependency lockfile. This draft commits the security branch’s controlled lockfile, with only the root node version adjusted to rc.66, and removes its ignore rule. That graph is a candidate for review; it is not a reconstruction of the original rc.66 binary build dependencies.

Intended node release: 0.7.0-rc.66.1, consumed by Android/iOS release-2.5.1 branches created from the app v2.5.0 tags. Version files still identify rc.66: release-version preparation, native rebuilds and publishing remain outstanding, so this draft must not be tagged or merged as a finished release.

Validation

• Dependency patch applies cleanly to the rc.66 source; its UDL is unchanged.
• Controlled dependency resolution succeeds with the existing graph; the production Lightning crates are 0.2.7.
• Android/Gradle publication and version-catalog resolution, and Swift exact-tag resolution for 0.7.0-rc.66.1, passed with local fixtures. These were version-handling checks, not LDK builds.
• Library compilation/tests, binding generation, actual package publication and app/device tests have not been performed for this backport.

Before release

• Review the dependency graph against the original build lock if available; otherwise explicitly approve the chosen graph.
• Prepare all release version files and freshly built native artifacts; verify the iOS checksum and exact Android package contents.
• Run available library/integration tests, then validate existing-wallet upgrade, sequential recovery, payments, channels and reconnect behavior on both app candidates.

Proposed release split. Android/iOS PRs will follow only after the chosen node versions are published.

[talosmachina]

No findings. Backports the lightning, lightning-liquidity and lightning-transaction-sync 0.2.7 bump onto the v0.7.0-rc.66 source and commits a lockfile for it. Reviewed 67929be, full tier (dependency manifest and lock).

What I checked, and 4 candidates I ruled out

Base: base/v0.7.0-rc.66 is 190a17d, the commit v0.7.0-rc.66 points at; outside Cargo.lock the diff is the three Cargo.toml requirements, the CHANGELOG line and the .gitignore rule.
Lockfile: production lightning* crates resolve to 0.2.7 (lightning, -liquidity, -transaction-sync); the other lightning-* 0.2.x entries are unchanged requirements. The ldk-node 0.6.2 / lightning 0.1.x entries are outside the normal dependency tree (cargo tree -e normal -i ldk-node@0.6.2 prints nothing). Apart from the root package version, the graph is identical to #123's lock.
Ran on this box, Rust 1.85 (the crate's rust-version): cargo test --lib --locked: 102 passed, 0 failed. cargo check --locked --features uniffi: passes, 6 warnings. cargo metadata --locked resolves on 1.85 and stable, so the committed lock is accepted unchanged.
Upstream: the 0.2.7 release notes list #5057 (conflicting commitment signing after a reconnect), #5042 (LSPS2 JIT intercepted-HTLC amount) and #4867 (Electrum sync pulling many transactions from a crafted funding tx); all three sit in the crates this PR bumps.
CI: no checks ran on this branch. Not run here: integration tests (bitcoind/electrs), bindgen.sh, mobile builds.

Ruled out

• Lock is not the rc.66 build graph: true, and the description says so and asks for that approval explicitly; a decision for the release owner, not a defect in the diff.
• Dropping the Cargo.lock ignore rule also exposes bindings/uniffi-bindgen/Cargo.lock: no, a lock created there still shows as untracked, not committed by accident; nothing in bindgen.sh stages it.
• 0.2.0 to 0.2.7 API or serialization drift on the rc.66 code: same minor line, the crate and its UniFFI surface compile unchanged, unit tests pass, and main already runs these versions (#123).
• Version files and CHANGELOG heading still say rc.66: stated as outstanding in the description, and nothing here tags or publishes.

Merge confidence: 4/5, a dependency change on a payments path with no CI and no integration test run against it.

[piotr-iohk]

Partial validation

Ran locally on 67929be, with locked dependencies. The PR still points to this revision.

• Rust unit tests: 102 node tests + 38 wallet-component tests passed; zero failures.
• UniFFI: cargo check --locked --features uniffi passed.
• Seven integration tests passed: start_stop_reinit, connection_restart_behavior, onchain_wallet_recovery, onchain_transaction_events_electrum, reorg_test (configured for five property cases), vss_node_restart, and vss_v0_schema_backwards_compatibility.

Integration validation remains incomplete. channel_full_cycle and channel_full_cycle_with_vss_store stalled after Failed to sign transaction: On-chain transaction signing failed / Failed signing funding transaction during splicing, and were terminated. The seven remaining variants in the grouped channel-cycle command did not execute.

A bounded control using rc.66 source and the pre-security dependency graph (Lightning 0.2.5, liquidity 0.2.3, transaction-sync 0.2.1) reproduced the same splice-signing error and stall. This points to an existing issue under that controlled graph; it is not evidence of a new regression from these three dependency bumps, nor a reconstruction of the original shipped binary's dependencies.

Environment: macOS arm64, Rust/Cargo 1.90.0, isolated Bitcoin 27.2 and electrs a33e97e1. VSS restart/schema checks used an unchanged upstream open-auth test fixture and temporary PostgreSQL 15 on localhost; they do not validate app LNURL/JWT authentication. Temporary services were cleaned up.

No independent vulnerability reproduction or Android/iOS build/device validation was performed. This is partial validation, not full integration sign-off or shipping approval.

Prepared log archive: ldk-pr124-partial-validation-67929be.zip, to be attached separately. It includes test output, both sets of splice-error evidence, the pre-security control and a results index; user-specific paths are redacted.

ldk-pr124-partial-validation-67929be.zip

[ovitrif]

@piotr-iohk I'm taking the release prep here too, after #123: version files for 0.7.0-rc.66.1, regenerated bindings, the remaining channel-cycle integration tests, then the tag and a GitHub release not marked latest. I'll post results here.

[ovitrif]

Release prep for 0.7.0-rc.66.1 is pushed; the tag and release wait for a re-review.

• 0692193 bumps the version files and regenerates the native artifacts: xcframework, Android .so and JVM dylibs. The Package.swift checksum matches the built LDKNodeFFI.xcframework.zip.
• Every built binary embeds lightning, lightning-liquidity and lightning-transaction-sync at 0.2.7 and no older version. rc.66's committed binaries show 0.2.5, 0.2.3 and 0.2.1.
• Python version is 0.7.0rc66.post1: 0.7.0-rc.66.1 isn't a valid PEP 440 version.
• /bindings/uniffi-bindgen/Cargo.lock is ignored, as on main.
• b9921ed adds packages: platform-tools to the Android SDK setup in publish-android.yml, the same fix as fix: restore android release publishing #121. Without it, publishing from this tag fails the way rc.67 and rc.68 did, because Google no longer serves the legacy tools package.

[ovi-reviewer]

Verdict: ✅ Approve

Review: diff 9 files.

Findings:
N/A

Proven at 0692193:

• Every rebuilt binary (Android .so, JVM dylibs, xcframework slices) embeds lightning, lightning-liquidity and lightning-transaction-sync 0.2.7 and no older version. The rc.66 binaries embed 0.2.5, 0.2.3 and 0.2.1.
• The Package.swift checksum matches the built LDKNodeFFI.xcframework.zip.
• The committed lockfile is the rc.71 graph plus the three bumps. Cargo.toml at rc.66 and rc.71 differ only in the version, so this graph is approved for rc.66.1.
• On Linux, at the same Rust source and lockfile (67929be), these pass: the lib tests, reorg_test, the 41 integration_tests_rust tests outside the channel cycles and the splice, and the 108 multi_address_types_tests. One electrs setup flake passed on rerun.

Not proven:

• channel_full_cycle* and splice_channel stall at splice funding signing. They stall the same way on rc.66 with 0.2.5, so this predates the PR and is tracked separately.
• The uploaded release zip and the published Android package: the zip's checksum and the AAR's crate versions wait for publishing.
• App upgrade, recovery and payment checks on the release-2.5.1 builds.

---

Reviewed by claude-opus-5-5 via gh-pr-review-loop skill
Commands: @ovi-reviewer review · test · retest

[ovitrif]

Release

• v0.7.0-rc.66.1

[ovitrif]

utAck