LND release candidate caps external fee API estimates at 10,000 sat/vB
LND’s v0.21.5-beta.rc1 pre-release adds guardrails to external fee inputs and fixes node reliability issues. It sets a ceiling on remote fee estimates before they reach wallet logic and resolves a native SQL connection-pool deadlock. The build requires no database migration and includes verification guidance. Operators still need deployment-focused testing to validate behavior under real workloads.
TL;DR
- The published build is v0.21.5-beta.rc1, a pre-release.
- The fee change limits extreme estimates supplied by an external service.
- Release verification and application testing answer different questions.
A remote estimate needs limits before it reaches the wallet
The release notes report that external estimates previously had only a lower bound. The repair caps values before they reach fee-sensitive wallet operations.
The associated change applies a ceiling of 10,000 satoshis per virtual byte and bounds the API’s minimum-relay estimate. The ceiling serves as an extreme-value guardrail rather than a statement about normal or economical fees under current network conditions.
A fee estimate is an input to a decision. A service can return an unusable value due to error, changed data format or a compromised dependency. Bounding the input limits the impact of upstream problems on the wallet.
The broader operational point aligns with Bitcoin Core’s revised disclosure process: software that handles money needs a way to find defects and a channel to move fixes into production.
A candidate build still needs evidence from its deployment setting
The GitHub release page marks the build as a pre-release and states no database migration is required. It provides signature and binary-verification instructions. These steps confirm the integrity of the download, not its behavior across all node configurations.
The notes include a native SQL connection-pool deadlock fix. Node reliability depends on storage behavior as well as network communication. A running process that stops completing requests still fails dependent applications.
Testing should cover real service work: receiving requests, accessing storage, handling failures and restarting cleanly. The absence of a migration removes one change category, but it does not guarantee unchanged interactions with existing data.
For payment providers, this differs from custody controls noted in shared-key Bitcoin lending. Securing signing authority and keeping a payment node functioning are separate duties.
The same distinction explains why custody and recovery arrangements cannot replace software maintenance. This candidate provides concrete changes to evaluate. The final release decision and each operator’s deployment decision remain separate steps.
Written by the News Desk and edited by Samuel Rae.
Authors credited by the source: NewsBTC Editorial Team
Published by Holder based on an external source.
