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

validation: only check input scripts once

Public commit record

What the developer wrote

Authored by Anthony Towns

90/100 · Strong
validation: only check input scripts once

Previously, we would check failing input scripts twice when considering
a transaction for the mempool, in order to distinguish policy failures
from consensus failures. This allowed us both to provide a different
error message and to discourage peers for consensus failures. Because we
are no longer discouraging peers for consensus failures during tx relay,
and because checking a script can be expensive, only do this once.

Also renames non-mandatory-script-verify-flag error to
mempool-script-verify-flag-failed.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This Bitcoin Core change removes a second, redundant check of transaction scripts when a transaction is rejected from the mempool. Previously, the software ran the expensive script check twice to decide whether a failure was a policy issue (like a non-standard signature) or a consensus issue (a rule everyone must agree on). Now it only checks once and reports a single mempool error. This is mainly a performance and code-simplification improvement; it does not change which transactions are accepted or rejected, only the exact error message returned and the internal work done.

Recommended action

No immediate security action required. Operators and integrators relying on exact mempool reject-reason strings should update their parsing to recognize the new 'mempool-script-verify-flag-failed' prefix. Reviewers should confirm that the single-pass logic does not accidentally treat a pure consensus failure as policy-only in block validation paths, which the diff indicates is preserved by using different flag sets for mempool vs. block checks.

Security signals we found

01

Behavior change in error reporting for mempool script failures

02

Removal of redundant script execution path

03

Performance optimization in transaction validation

04

No change to consensus acceptance rules

05

No change to peer banning/disconnection logic for transactions

Risk score

Why this scored 24/100

Our methodology →
Potential impact 3/30
Exploitability 2/25
Stealth signal 2/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.