LND caps external Bitcoin fee estimates at 10,000 sat/vB in release candidate

3 min

LND’s October 22 release candidate highlights a wallet-risk vector: overly generous external fee estimates. Version v0.21.5-beta.rc1 introduces an upper bound for remote fee data and includes reliability fixes. The build is a pre-release.

Key points

Version: v0.21.5-beta.rc1, pre-release, no database migration required.
Fees: caps external fee estimates at 10,000 sat/vB and bounds minimum-relay estimates to prevent extreme inputs from affecting wallet operations.
Security model: external fee data is an input to a decision. Bounding values reduces impact from upstream errors, format changes, or compromised dependencies.
Stability: includes a native SQL connection-pool deadlock fix that affects node reliability beyond networking.
Verification vs testing: signature and binary checks confirm provenance; deployment testing must validate behavior in real node configurations.

Fee estimate ceilings reduce exposure to upstream faults

The release notes document that previous external fee handling enforced a lower bound but lacked an upper bound. The patch introduces a ceiling of 10,000 sat/vB and bounds the minimum-relay value from the API. The ceiling is a guardrail, not guidance on typical or economical fees. Bounding external inputs limits how an API glitch, data-format change, or dependency compromise can propagate into fee-sensitive wallet actions. This aligns with broader operational practices highlighted in Bitcoin Core’s disclosure updates: systems that handle money need mechanisms to detect issues and deploy fixes.

Pre-release status: verify artifacts and test in live-like environments

The GitHub page marks the build as a pre-release and provides signature and binary verification instructions. These steps confirm download integrity but do not guarantee behavior across diverse node setups. The version also fixes a native SQL connection-pool deadlock, which affects availability: a process can appear healthy while requests stall if storage interactions deadlock.

Effective candidate testing must exercise real workloads: request handling, storage access, failure scenarios, and clean restarts. The absence of a database migration removes one change category, but it does not imply that all interactions with existing data remain unchanged. Operational testing differs from custody considerations such as shared-key lending or insured custody arrangements. Maintaining node software and ensuring service reliability are distinct from key management and recovery planning. The candidate provides concrete changes to evaluate before both final release and operator deployment decisions.

Written by the News Desk and edited by Samuel Rae.