Bitcoin cryptography is actually a surprisingly elegant system that prioritizes security and verifiability through a few core, well-understood cryptographic primitives.

Let’s see it in action. Imagine Alice wants to send 1 BTC to Bob.

First, Alice needs a way to prove she owns the Bitcoin she wants to send. This is where private keys and public keys come in.

A private key is a very large, random number, typically 256 bits long. Think of it as a secret password that grants complete control over your Bitcoin. It’s generated using a cryptographically secure pseudorandom number generator. For example, a private key might look like this (though it’s usually represented in a more compact format like Wallet Import Format - WIF):

5J3mBbAH58CpQ3Y5tfq5whQNSdsT47yJ5Fm4i22f2U61B1f8b8m

From this private key, a corresponding public key is deterministically derived using an elliptic curve digital signature algorithm (ECDSA), specifically the secp256k1 curve. This derivation is a one-way process; you can get the public key from the private key, but you can’t get the private key from the public key. The public key is a much larger number, and it’s used to generate your Bitcoin address.

A Bitcoin address is a hashed and encoded version of the public key, making it shorter and easier to share. It’s what you give to others to receive Bitcoin. An example address might be:

1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2

Now, when Alice wants to send 1 BTC to Bob, she doesn’t "send" the Bitcoin in the traditional sense. Instead, she creates a transaction that references an existing unspent transaction output (UTXO) that she owns, and directs it to Bob’s address. This transaction is essentially a message saying, "I, Alice, am taking this specific past payment I received (which is tied to my public key) and sending it to Bob’s address."

Here’s where the magic of digital signatures happens. To prove she is authorized to spend that UTXO, Alice uses her private key to sign the transaction data. This signature is a unique piece of data that can only be generated by her private key, but it can be verified by anyone using her corresponding public key.

The signing process involves taking the transaction data, hashing it, and then applying the ECDSA algorithm with her private key. The resulting signature is appended to the transaction.

When Bob (or any node on the network) receives this transaction, they can verify its authenticity. They take the transaction data, hash it, and then use Alice’s public key (which is implicitly known because the UTXO being spent is linked to her address, and therefore her public key) and the signature to perform a verification check. If the verification passes, it proves that the transaction was indeed authorized by the owner of the private key associated with that UTXO.

So, the transaction might look something like this (simplified representation):

{
  "txid": "a1b2c3d4e5f6...",
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "previous_txid_alice_received",
      "vout": 0,
      "scriptSig": "SIG_FROM_ALICE_PRIVATE_KEY", // This is the digital signature
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": "100000000", // 1 BTC in satoshis
      "scriptPubKey": "OP_DUP OP_HASH160 BOB_PUBLIC_KEY_HASH OP_EQUALVERIFY OP_CHECKSIG" // Bob's address derivation
    },
    {
      "value": "remaining_change",
      "scriptPubKey": "ALICE_PUBLIC_KEY_HASH" // Change back to Alice
    }
  ]
}

The scriptSig here contains Alice’s signature. The scriptPubKey in the vout for Bob contains the instructions to verify that the person spending this output has the correct public key.

This entire process is what ensures that only the owner of the private key can spend Bitcoin, and that anyone can verify the legitimacy of transactions without needing to trust any central authority.

What most people don’t realize is that the Bitcoin address itself is not directly derived from the public key; it’s a hash of the public key. This hashing adds an extra layer of security and also allows for different address formats (like P2PKH, P2SH, Bech32) that can offer further benefits like reduced transaction size or improved error detection. The scriptPubKey in the output dictates how the UTXO can be spent, and this is where the verification against the public key happens.

The next concept you’ll likely encounter is how these transactions are bundled into blocks and chained together to form the blockchain, and the role of mining in this process.

Want structured learning?

Take the full Cryptography course →