Lecture 36: Anatomy of a Transaction: How Digital Signatures Authorize Payments

Sequentia Explores: The Mathematics of Crypto

Part VI: Building a Blockchain – The Math of a Distributed Ledger

Lecture 36: Anatomy of a Transaction: How Digital Signatures Authorize Payments

Welcome to Part VI of our series! We’ve assembled our cryptographic tools and are now ready to start building. Our goal is to understand the mathematical marvel of a blockchain. And the fundamental, indivisible “Lego brick” of any blockchain is the transaction.

When you “send” bitcoin, you aren’t sending a digital file like an email. There are no “bitcoin files” that move from one computer to another. Instead, you are creating and signing a transaction message, which is a public declaration authorizing a change in the shared ledger.

Today, we’ll dissect the anatomy of a Bitcoin transaction and see exactly how the digital signatures we learned about provide the unforgeable proof of ownership needed to authorize payments.

Shifting Your Thinking: No Accounts, Only Unspent Outputs

First, a crucial mental shift. The Bitcoin system doesn’t have “accounts” with balances in the way a bank does. Instead, the blockchain keeps track of a list of Unspent Transaction Outputs (UTXOs).

A UTXO is a chunk of bitcoin from a previous transaction that has been “sent” to your address and is now available for you to spend. Your “wallet balance” is simply the sum of all the UTXOs that your private keys can control.

When you want to send bitcoin, you aren’t debiting an account. You are creating a new transaction that consumes one or more of your existing UTXOs as inputs and creates new UTXOs as outputs.

The Core Components of a Transaction

Let’s imagine Alice wants to send 0.5 BTC to Bob. Her transaction message will have three main parts:

1. Inputs: This section specifies which of Alice’s existing UTXOs she wants to spend. She is essentially pointing to a previous transaction output on the blockchain and saying, “I want to use these funds.” For each input, she must provide proof that she is the rightful owner.
2. Outputs: This section specifies where the bitcoin is going. It creates new UTXOs. In our example, there would be at least one output:
   • Output 1: 0.5 BTC to Bob’s public address.
   • If Alice’s input UTXO was larger than 0.5 BTC (say, 1.0 BTC), there would be a second output, called “change,” sending the remainder back to one of Alice’s own addresses. Output 2: 0.5 BTC back to Alice’s change address.
3. Metadata: Other information like the version number, lock time, etc.

The core of the transaction is a simple statement: “I am using these specific unspent funds and reassigning them to these new addresses.”

But how does the network know that only Alice can spend her funds?

The Digital Signature: The Unforgeable Authorization

This is where our knowledge of hashing and digital signatures comes into play. The transaction is not valid until Alice proves her ownership of the inputs by providing a digital signature.

Here’s the simplified process:

1. Create the Transaction Data: Alice’s wallet software assembles the transaction message, specifying the inputs and outputs.
2. Hash the Transaction: The wallet then takes almost all of this transaction data and runs it through a hash function (specifically, SHA-256 applied twice). This creates a unique, fixed-size “fingerprint” of the authorization message.
3. Sign the Hash with the Private Key: Alice’s wallet uses her private key—the secret key corresponding to the public address that received the input UTXO—to encrypt this hash. This encrypted hash is the digital signature.
4. Attach the Signature and Public Key: The resulting digital signature, along with Alice’s public key, is attached to the transaction input.
5. Broadcast: The complete transaction (inputs, outputs, signature, public key) is broadcast to the Bitcoin network.

How the Network Verifies the Transaction

Now, nodes (computers) on the Bitcoin network receive Alice’s transaction and must independently verify it before including it in a block. This is the “verification” step we learned about in Lecture 30.

For each input in the transaction, a node performs the following checks:

1. Check if the Input is Unspent: The node checks the blockchain to ensure the UTXO Alice is trying to spend is actually valid and hasn’t already been spent.
2. Verify the Signature: This is the cryptographic core.
   • The node takes Alice’s public key (which was included in the transaction).
   • It uses the public key to decrypt the digital signature. The result is the original hash of the transaction, let’s call it Hash_A.
   • The node then takes the rest of the transaction data and hashes it itself, using the same double-SHA-256 process. This creates Hash_B.
3. Compare the Hashes:
   • If Hash_A is identical to Hash_B, the signature is VALID.

What Does a Valid Signature Prove?

This mathematical verification provides two absolute guarantees without needing a central authority:

• Authenticity: Because the signature could only have been successfully decrypted by Alice’s public key, it provides mathematical proof that the transaction was signed by the holder of the corresponding private key. It proves ownership.
• Integrity: The fact that the hashes match proves that the transaction data (the amounts, the recipient addresses, etc.) has not been altered in any way since Alice signed it. If an attacker tried to change Bob’s address, the hash would no longer match, and the signature would be invalid.

A Bitcoin transaction, therefore, is nothing more than a proposed update to the public ledger, authorized by an unforgeable digital signature. It is a beautiful, self-contained piece of mathematical proof, combining the one-way nature of hashing with the trapdoor magic of public-key cryptography to allow for secure, verifiable transfers of value in a trustless environment.