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

tx-sync: parallelize esplora status queries

Public commit record

What the developer wrote

Authored by Max Fang

68/100 · Adequate
tx-sync: parallelize esplora status queries

The esplora sync loop awaited each HTTP query sequentially: one
get_block_status per relevant txid, 3 round trips (merkle block, tx,
block status) per watched transaction, and one get_output_status per
watched output. With many channels this pure latency dominates sync
wall-clock time, particularly during the first sync after a restart.

In async builds, run the per-block, per-transaction, and per-output
queries concurrently via buffer_unordered, bounded at 16 in-flight
requests by default and configurable via with_concurrency.
Confirmed transactions are already sorted by (height, in-block
position) before being fed to the confirmables, so completion order
does not matter. The blocking client variant remains sequential.

Also dedup block status queries by block hash (multiple relevant txids
can share a block), and drop a redundant duplicate-txid check when
iterating watched_transactions: it is a HashSet, so txids are unique.

Note that items are moved into the concurrently-polled futures as owned
values (txids copied, watched outputs cloned). Borrowing them compiles
within this crate but trips rustc's "implementation of FnOnce is not
general enough" false positive in downstream callers that box the
returned sync future.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a performance improvement, not a security fix. It speeds up how rust-lightning asks an Esplora server about transaction and block status by running many requests at once instead of one at a time. The change also removes a duplicate check and deduplicates repeated block-status lookups. There is no indication in the commit that it fixes a vulnerability or that the old code was unsafe.

Recommended action

No security action required. Treat as a normal performance improvement. Reviewers may optionally verify that buffer_unordered ordering does not affect the downstream confirmables logic (the commit notes results are sorted afterward).

Security signals we found

01

No security-relevant keywords in commit title or message

02

No mention of vulnerability, CVE, bug bounty, or security researcher

03

Change is a performance refactor with preserved behavior

04

Blocking client path unchanged; async path only adds concurrency

05

Deduplication and removed duplicate check are correctness/efficiency cleanups, not security fixes

Risk score

Why this scored 21/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 5/15
Confidence 8/10
Evidence quality 4/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.