Keys, Signatures and Bitcoin Transactions

A Bitcoin wallet helps authorise transactions using keys. Those keys do not work like a shared account password, and sending BTC does not usually mean subtracting a number from one centrally managed bank account. Bitcoin spends previously created transaction outputs. We will follow a small fictional payment to see how authorisation, change and fees fit together.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

A private key is secret signing material. A corresponding public key lets others verify appropriate signatures. An address is an encoded destination associated with spending conditions; it is not simply a public-key string in every address format. You can share a receiving address where appropriate without handing over the private key needed to authorise spending.

Wallet software may manage many keys and addresses behind one familiar interface. Different address types and spending conditions exist, including arrangements that require more than one signature. The beginner distinction is authority: a receiving address tells a sender where to create an output, while secret signing material helps satisfy the conditions for spending it. A wallet password commonly protects a local application or file. Changing that password cannot revoke a private key that someone has copied.

Think of the mailboxes in the lobby of an apartment block in Chicago. Anyone can push a letter through the slot of box 4B. Under the simplified mailbox design, a matching key opens box 4B. Copied keys or a master key would change that arrangement. The building manager never checks who you are; the lock does the checking.

Shorten the public key into an address

An address tells a sending wallet how to create a destination under a particular format. It is not always simply a shortened public key. Legacy key-hash addresses, script-hash addresses and newer witness or Taproot formats encode different spending information.

For a beginner, the mailbox picture is enough if its limit is clear: the public destination can be shared for receiving, while private signing material remains secret. A receiving address need not reveal a person's name. A valid format does not establish a trustworthy recipient.

Wallets can manage many addresses and more complex spending conditions, including multiple signatures. Do not extrapolate the simplest one-key example to every Bitcoin output or every wallet.

Sign without showing the key

On paper, you authorise a cheque or a contract with a handwritten signature. In earlier centuries, important letters were closed with a wax seal pressed from a ring only the sender owned. Both say "this came from me, and I agree to it".

A digital signature does the same job for a Bitcoin transaction. Your wallet takes the transaction's details and your private key, and produces a signature. Anyone with your public key can check that signature, but recovering a properly generated private key from it is computationally impractical under the signature scheme's assumptions.

Here the analogy stops working, in Bitcoin's favour. A handwritten signature looks much the same on every document, so it can be copied. A digital signature is different for every transaction and tied to its exact contents; copy it onto a different payment and it fails the check.

The whitepaper defines a coin as a chain of digital signatures: each owner passes it on by signing it over to the next owner's public key. To see one link in action, watch a node check it.

Watch a node check a signature

Chiara in Rome makes a fictional Bitcoin payment to David in Chicago. Later, David spends the received output. His wallet supplies the information needed to satisfy that output's spending conditions, including an appropriate signature.

Other nodes check the authorisation and the transaction's validity without learning David's private key. In the ordinary classroom signature model, the signature commits to the relevant transaction details, so changing the destination invalidates it. Bitcoin also has different signature modes and script conditions; the simple example is not an exhaustive account of them.

A valid signature establishes that the required signing authority approved the instruction. It does not establish that David understood it, that his device was clean, or that the recipient will deliver promised goods. Inspecting the request and protecting the secret are complementary jobs.

It does not prove the signer understood the request, nor that the transaction was wise.

Read what is inside a transaction

A Bitcoin transaction is a short message that says, in effect, "take these coins I control, and lock them to these new owners". It has two main lists.

Each input points back to a coin you received earlier, naming the previous transaction and which of its outputs is being spent. Each output holds an amount and a lock that only the recipient can open. Your wallet proves you may spend the inputs by attaching digital signatures; the keys and signing lesson in Level 1 explains how.

So outputs are where coins "live", and inputs are how they move on. But outputs need somewhere to be sent, which is what addresses are for.

Find out what an address is

A Bitcoin address is a string of letters and numbers that tells a wallet how to lock an output so only the intended person can spend it. It is more like a lockable letterbox slot than an account name: it doesn't carry your name, and one person can have many.

You'll see several formats. Older addresses start with 1 or 3. Newer ones start with bc1: bc1q… for SegWit addresses and bc1p… for Taproot addresses. Bitcoin Optech explains that the bc1 format uses only lowercase letters and numbers and includes error checking that catches almost all typing mistakes. That helps, but it cannot catch the case where you paste a valid address that belongs to someone else.

With outputs and addresses in place, you can see how Bitcoin keeps track of who owns what.

Pay with notes and get change back

Imagine Emma in Sydney buying a A$30 lunch with a A$50 note (invented amounts for this example). She cannot tear off A$30 of the note. She hands over the whole note and gets A$20 back in change.

Bitcoin works similarly. Your wallet doesn't hold one running balance like a bank account. It holds separate unspent outputs, each like a note of a particular value. When you pay, it spends one or more whole outputs as inputs and creates new outputs: one for the person you're paying, and usually one returning the leftover to you as change.

The developer guide explains that each output can be spent only once. That is how Bitcoin solves the double-spending problem from the Bitcoin origins lesson in Level 1: once an output is spent in a confirmed transaction, any later attempt to spend it again is invalid.

The analogy stops working in two places. Bitcoin "notes" can be any amount, not fixed denominations. And there is no till to count the change: your wallet writes the change output itself. The fee isn't a separate line either; it is whatever is left over.

That fee looks tiny written in bitcoin, which is why fees are counted in a much smaller unit.

Outputs cannot generally be spent in fractions while leaving the rest of that same output untouched; a new change output represents the remainder. The wallet may use a fresh change address, so an explorer showing two outputs does not necessarily mean there were two external purchases. Real wallets may combine several inputs and create more outputs than this simple example.

Open diagram at original size ↗

Read diagram as text

Input consumed: 0.0100 BTC.

Recipient output: 0.0030 BTC. Change output: 0.0068 BTC.

The outputs total 0.0098 BTC. Input minus outputs leaves a 0.0002 BTC fee; the fee is a difference, not an extra spendable output.

A transaction identifier, or transaction ID, identifies a transaction for lookup. An explorer can display inputs, outputs, status, block information and a fee. A pending transaction has not yet been included in an accepted block known to that explorer. Confirmation count ordinarily includes the transaction's own block and subsequent blocks on the accepted branch.

For the fictional record, total inputs are 0.0100 BTC, total outputs are 0.0098 BTC and the fee is 0.0002 BTC. Do not add the fee to outputs and call that the recipient amount. Nor should you assume every output is someone else's income. An exchange may credit a deposit only after its own confirmation requirement, and a transaction appearing on-chain does not automatically prove the service account has been credited. Read network status and provider accounting as separate records.

Bitcoin has no ordinary chargeback system for a confirmed payment. More accepted blocks above it increase the work needed for a competing valid history to remove it. That is practical, probabilistic settlement under the network's assumptions, not a promise that every theoretical reorganisation is impossible.

For a recipient, choose and apply a confirmation policy appropriate to the service. An exchange can require additional confirmations and account checks. For a sender, independently verify the destination before authorisation. A recipient's voluntary refund is a new transaction.

Bitcoin records are public, but addresses are not automatically verified personal identities. A person can use multiple addresses, and an exchange can control addresses serving many customers. Analysts may infer connections from patterns, but inferences can be incomplete or wrong. A transaction record therefore establishes activity under particular spending conditions rather than a complete description of the people involved.

Privacy can still be reduced when an address is linked to a person's name, invoice, social post or exchange account. An explorer operator may also observe your queries and related network information. Avoid publishing real addresses or transaction IDs in course exercises when they could reveal personal financial activity. Use the supplied fictional records. Later on-chain analysis lessons examine why counting addresses is different from counting people.

Everyday example

What to remember

Lesson completion check

References and further reading