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

sign_psbt: use shared signing tx validation code

Public commit record

What the developer wrote

Authored by Jon Griffiths

68/100 · Adequate
sign_psbt: use shared signing tx validation code

This means we don't have to find the fee ourselves, and ensures that
the checks we perform (e.g. duplicate fees) are consistent whether we
are signing a tx or psbt.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how the Blockstream Jade hardware wallet checks transaction fees when signing a PSBT. Previously, the fee was calculated and validated inside the PSBT-specific code. Now it uses a shared validation routine that is also used for regular transaction signing. The goal is consistency: the same duplicate-fee and fee-validation checks apply regardless of whether the user is signing a raw transaction or a PSBT. The commit removes several local fee checks (such as rejecting blinded fee outputs or unexpected fee asset IDs) and relies on the shared function instead. This is a code-quality and consistency improvement, not a clear-cut security fix, but it touches security-critical fee logic.

Recommended action

Review the implementation of params_txn_validate() to confirm it enforces every constraint removed from validate_outputs(), especially for Liquid: fee outputs must be unblinded, must use the policy asset, and must not be duplicated. Ensure JADE_ASSERT-only replacements are acceptable for production builds. Run regression tests on Liquid PSBTs with blinded outputs, wrong asset IDs, and duplicate fee outputs.

Security signals we found

01

Refactoring of security-critical fee validation logic

02

Removal of explicit runtime checks for Liquid fee outputs (blinding, asset ID, fee tallying)

03

Replacement of runtime checks with debug-only JADE_ASSERT assertions

04

Introduction of shared validation routine params_txn_validate()

05

Potential for behavioral change if shared routine does not enforce all previously checked constraints

Risk score

Why this scored 44/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 5/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.