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

psbt: add tx input and output fields in PSBTInput and PSBTOutput

Public commit record

What the developer wrote

Authored by Ava Chow

73/100 · Adequate
psbt: add tx input and output fields in PSBTInput and PSBTOutput

PSBTInput should be aware of the previous txid, output index, and
sequence numbers for inputs, extracting them from the global
unsigned tx.

PSBTOutput should be aware of the output amount and script, extracting
them from the global unsigned tx.

This prepares for PSBTv2 where these fields are serialized.
✓ Specific, 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 small internal refactor of how Bitcoin Core builds Partially Signed Bitcoin Transactions (PSBTs). It makes each PSBT input and output remember its corresponding transaction details (previous transaction ID, output index, sequence number, amount, and script) directly, instead of only storing them inside the global unsigned transaction. The change prepares the code for a future PSBT version (PSBTv2) where these fields are stored separately. There is no obvious security bug in the diff itself, but it touches serialization and RPC code paths that handle user-provided transaction data.

Recommended action

Review as normal code maintenance. Verify that the new PSBTInput/PSBTOutput fields are kept consistent with the global unsigned tx during future merges and PSBTv2 serialization, and ensure fuzz/serialization round-trips still cover edge cases such as empty vin/vout.

Security signals we found

01

Constructor signature change in PSBTInput/PSBTOutput now requires transaction-derived fields

02

Deserialization path creates PSBTInput/PSBTOutput using data from the global unsigned tx

03

RPC createpsbt/converttopsbt now rely on a single constructor instead of manual vector population

04

No bounds checks or validation logic added for the newly stored fields

05

No explicit security claim or bug fix in commit message

Risk score

Why this scored 19/100

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