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

Sikh Bitcoin · Advanced · Lesson 5 of 21

Signatures and what they authorize

A valid signature is only as meaningful as the message it covers.

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 5 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

  • Distinguish authentication from informed authorization.
  • Explain why transaction details matter to a signer.

A signature binds a key to a message

Bitcoin uses digital signatures to authorize spending under applicable script rules. BIP 340 specifies Schnorr signatures used in Taproot contexts; earlier output types use other established rules. A valid signature establishes a mathematical relation among a message, signature and public key. It does not establish that a human understood the transaction shown by an interface.

The covered data matters

Transaction signature rules determine which parts are committed to. Different signature-hash modes have different meanings. A signer must therefore inspect the actual transaction and intended policy rather than assuming that every signature authorizes exactly one intuitive payment. A request described as verification can still deserve scrutiny if its content is unclear.

Make the display useful

For a fictional hardware-signing exercise, show the recipient outputs, change recognition, network and fee before approval. If a device cannot meaningfully display what matters, that is a limitation to address, not an invitation to click through. A signature workflow should support refusal and an independent review route. This course never asks for a real signature; use a written transaction summary to practice explaining what would be authorized.

Practice on paper

A signer sees a 20,000-sat recipient payment but the proposed transaction also has an unfamiliar second external output. What is the right review question?

Reveal the worked answer

Ask what every output represents and whether change is correctly identified. A correct first output does not establish that the whole transaction matches the intended action.

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 cryptographic validity prove informed human consent?

  • Yes
  • No
Reveal answer 1

No. The human may have been shown misleading information.

2. Should unfamiliar signature modes be ignored because the wallet recognizes them?

  • Yes
  • No
Reveal answer 2

No. Their commitments need to match the intended authorization.

Take this with you

Review the message and spending effect, not merely the signature prompt.

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.