DA-03 · LESSON 06

PSBT manifests and signing inputs

KEY DEFINITIONS

Terms used in this lesson

PSBT: Partially Signed Bitcoin Transaction: a format for passing an unsigned or partly signed transaction between constructors and signers.
Sighash: The exact transaction digest and signature mode that determine which fields a Bitcoin signature authorizes.
Taproot: A Bitcoin output and spending design that can combine a public-key path with privately committed alternative scripts.
BIP341: The Bitcoin Improvement Proposal specifying Taproot output validation and the transaction signature message used by Taproot signatures.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.
BTC: The common market ticker for bitcoin.

The client prepares transaction context while signing code derives the precise sighash and Taproot context that each signer must authorize.

45 min Difficulty 4/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · ducat vaultA Ducat action moves one Bitcoin-anchored vault state to a successorSelect any state to inspect its exact role.

RELATIONSHIP MAPInputs, rule, and outputs

01
PREDECESSORCurrent vault outpoint
The current Bitcoin output anchors collateral and identifies the state being spent.
02
REQUESTPSBT manifests and signing inputs
The PSBT manifests and signing inputs workflow proposes one exact action and successor state.
03
POLICYProfile, oracle, signatures
Applicable policy, price evidence, authorization, and transaction shape are checked.
04
BITCOIN SPENDScript-valid transaction
Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules.
05
SUCCESSORNew outpoint and state
Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

Rule shown: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state.

STAGE 1 OF 5PREDECESSOR: Current vault outpoint

The current Bitcoin output anchors collateral and identifies the state being spent.

Governing relationship: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state. Complete path: 1. PREDECESSOR, Current vault outpoint. The current Bitcoin output anchors collateral and identifies the state being spent. 2. REQUEST, PSBT manifests and signing inputs. The PSBT manifests and signing inputs workflow proposes one exact action and successor state. 3. POLICY, Profile, oracle, signatures. Applicable policy, price evidence, authorization, and transaction shape are checked. 4. BITCOIN SPEND, Script-valid transaction. Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules. 5. SUCCESSOR, New outpoint and state. Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

1. State transitionWhat exists, what changes, and what results

BEFORE

A child input at index 1 spends an approved prior output and output 2 pays 0.15 BTC to Bob. Required practice uses another manifest.

MECHANISM

The builder finalizes input order, outputs, scripts, amounts, and action metadata before requesting signatures.

AFTER

Missing prior-output script or amount makes safe screening and real sighash construction impossible. Required practice uses a separate server-executed vector.

Text equivalent: Starting from A child input at index 1 spends an approved prior output and output 2 pays 0.15 BTC to Bob. Required practice uses another manifest. The mechanism begins when The builder finalizes input order, outputs, scripts, amounts, and action metadata before requesting signatures. The resulting lesson is Missing prior-output script or amount makes safe screening and real sighash construction impossible. Required practice uses a separate server-executed vector.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Freeze transaction bytes

The builder finalizes input order, outputs, scripts, amounts, and action metadata before requesting signatures.

Complete path: 1. Freeze transaction bytes: The builder finalizes input order, outputs, scripts, amounts, and action metadata before requesting signatures. 2. Attach prior-output context: Each signing input needs the previous output and the sighash rules required to derive the message. 3. Bind request fields: Action type, request identity, txids or unsigned transaction data, input indexes, group key, and policy context prevent substitution. 4. Screen, then derive the real sighash: First compare the complete request manifest. Then parse the actual PSBT, reconstruct every previous output required by BIP341, derive the covered input's real signature message, and sign only that input.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The worked case executes the named inputs and checks in the displayed order. First compare the complete request manifest. Then parse the actual PSBT, reconstruct every previous output required by BIP341, derive the covered input's real signature message, and…

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. A PSBT can request authorization for harmful final transaction bytes. Signers must verify outputs, amounts, context, and sighash before signing.

Important distinction: A PSBT is safe to sign because it is not yet a Bitcoin transaction. A PSBT can request authorization for harmful final transaction bytes. Signers must verify outputs, amounts, context, and sighash before signing.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. First compare the complete request manifest. Then parse the actual PSBT, reconstruct every previous output required by BIP341, derive the covered input's real signature message, and sign only that input. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. A PSBT can request authorization for harmful final transaction bytes. Signers must verify outputs, amounts, context, and sighash before signing.

Loading lesson visuals...

Learn the idea

A Partially Signed Bitcoin Transaction, or PSBT, carries an unsigned transaction plus the prior-output and Taproot data signers need. A signature hash, often shortened to sighash, is the exact 32-byte message Bitcoin derives for one signature under rules such as BIP341. A separate manifest digest can screen an approved request for substitutions, but it is not a Bitcoin sighash and cannot replace parsing the PSBT.

GUIDED EXPLANATION1/4 ideas inspected

Freeze transaction bytes

The builder finalizes input order, outputs, scripts, amounts, and action metadata before requesting signatures.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A PSBT is safe to sign because it is not yet a Bitcoin transaction.”

A PSBT can request authorization for harmful final transaction bytes. Signers must verify outputs, amounts, context, and sighash before signing.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.