Neutral

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

На русском
3 min
LND release candidate caps external Bitcoin fee estimates at 10,000 sat/vB

LND’s October 22 release candidate introduces guardrails on external fee estimates to reduce wallet risk and fixes a native SQL connection-pool deadlock. The build is pre-release and requires no database migration. Operators still need deployment-specific testing beyond binary verification.

TL;DR

  • Version: v0.21.5-beta.rc1 pre-release.
  • Fee safety: caps external fee estimates to limit extreme values.
  • Process: binary verification differs from deployment testing.

A remote estimate needs limits before it reaches the wallet

The release notes state that external fee estimates previously used a lower bound without an upper bound. The update applies the limit before estimates can influence fee-sensitive wallet operations.

The change in PR #11334 sets a ceiling of 10,000 satoshis per virtual byte and bounds the API’s minimum-relay estimate. The ceiling functions as an extreme-value guardrail, not a target fee.

Fee estimates are inputs to decisions. Services can return unusable values due to errors, format changes or compromised dependencies. Bounding inputs reduces the impact of upstream faults on wallet behavior.

This aligns with the need for clear discovery and patch pathways highlighted by Bitcoin Core’s revised disclosure process: money-handling software requires both issue detection and timely repair adoption.

A candidate build still needs evidence from its deployment setting

The GitHub release page marks the build as pre-release and notes no database migration. It provides signatures and verification steps. These confirm the download’s integrity but do not prove behavior across node configurations.

The notes also include a native SQL connection-pool deadlock fix. Reliability depends on storage as well as networking. A process that stays up while requests stall still fails dependent applications.

Testing must cover real workloads: request handling, storage access, failure handling and clean restarts. The absence of a migration removes one change class but does not guarantee unchanged interactions with existing data.

This operational focus differs from custody arrangements such as shared-key Bitcoin lending and insured custody and recovery. Securing signing authority and keeping a payment node functional are separate responsibilities. The candidate provides specific changes to evaluate. Final release and operator deployment decisions remain separate steps.

Written by the News Desk and edited by Samuel Rae.

Original publication

Authors credited by the source: NewsBTC Editorial Team

Published by Holder based on an external source.