Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 14 of 21

PSBT: separate construction from signing

Follow a portable transaction through distinct responsibilities.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 14 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Identify the main PSBT roles.
  • Explain why a signer must still review the transaction.

A container for collaboration

A Partially Signed Bitcoin Transaction carries a proposed transaction and supporting data so multiple tools can participate. BIP 174 describes roles such as creator, updater, signer, combiner, finalizer and extractor. One application may perform several roles, but the separation helps explain where data is added and where spending authorization occurs.

Portable does not mean trustworthy

A coordinator can prepare a PSBT without being allowed to spend. A signer must check the transaction and sufficient supporting information rather than assuming the coordinator is honest. Combining signatures does not authorize a different economic purpose. The final extracted transaction still needs broadcast and reconciliation; a complete signature set is not a confirmation.

Design for refusal and recovery

In a fictional two-person treasury, one person prepares a payment request and two authorized signers review their own displays. A mismatch stops the workflow. Logs can preserve the approved purpose and final transaction identifier without storing private keys. Test the recovery path if the coordinator disappears: can another compatible tool reconstruct the policy and complete the process? This lesson does not ask you to sign or upload any real PSBT.

Practice on paper

A coordinator says a PSBT is “ready.” Name three checks a signer should understand before authorizing it.

Reveal the worked answer

Check recipient outputs and amounts, correct recognition of change, and the fee/network/policy context. The exact review depends on the wallet and script. “Ready” is a workflow label, not proof that the proposal matches human intent.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does a PSBT require the coordinator to hold private keys?

  • Yes
  • No
Reveal answer 1

No. Construction and signing can be separated.

2. Does finalizing a PSBT prove on-chain settlement?

  • Yes
  • No
Reveal answer 2

No. Broadcast and settlement checks come afterward.

Take this with you

Keep preparation, authorization and settlement independently understandable.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.