AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 26 Bitcoin

bcli: convert `estimatefees` to synchronous execution

Public commit record

What the developer wrote

Authored by dovgopoly

73/100 · Adequate
bcli: convert `estimatefees` to synchronous execution

Add `command_err_badjson` helper for sync error handling, mirroring the async `command_err_bcli_badjson`. Store args string in `bcli_result` for consistent error messages.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change rewrites how Core Lightning asks Bitcoin for fee estimates, switching from an asynchronous (multi-step callback) style to a simpler synchronous style. It also adds a shared helper for reporting bad JSON responses from bitcoin-cli and fixes a typo in a log message ('32 bites' to '32 bits'). The rewrite does not obviously add or remove a vulnerability, but it changes timing and error-handling behavior in a security-sensitive area (fee estimation), so it warrants careful review.

Recommended action

Review the synchronous blocking behavior under slow bitcoind conditions and confirm that marking helpers `UNNEEDED` does not leave dead code that can be re-enabled by future patches. Verify that `command_err_badjson` does not expose sensitive backend output to RPC consumers. No immediate patch or incident response is indicated by the diff alone.

Security signals we found

01

Behavioral change in fee-estimation error path: previously a failure in one estimatesmartfee call could still allow partial results; now any failure returns an error/null response immediately, which may change fee fallback behavior.

02

New helper centralizes JSON parse/scan error messages and includes raw bitcoin-cli output; this could leak verbose backend output to RPC callers if output contains sensitive data, though no such data is evident.

03

Synchronous bitcoin-cli calls block the plugin thread; a slow or hung `estimatesmartfee`/`getmempoolinfo` could delay or deny fee responses, but this is a denial-of-service/availability concern rather than a code-execution vulnerability.

04

Old async functions marked `UNNEEDED` remain compiled; if still referenced or re-enabled accidentally they could create stale logic, but the diff shows no active references.

05

No input validation changes are visible; parameters still flow through existing `param()` and `tal_fmt()` paths.

06

Typo fix in log message ('32 bites' -> '32 bits') is benign.

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.