Part II · The Classic Era Chapter 4

Pay to Public Key (P2PK)

On January 3, 2009, at approximately 18:15 UTC, a single computer somewhere in the world computed a SHA-256 hash below a target threshold and produced Block 0—the Genesis Block. Inside it was a coinbase transaction paying 50 BTC to a 65-byte public key, locked by the simplest possible script: push the key, check the signature. No addresses. No hashes. No redeem scripts. Just a raw public key and OP_CHECKSIG. This was P2PK—Pay to Public Key—and for the first thirteen days of Bitcoin's existence, it was the only transaction type.

Satoshi's original Bitcoin client used P2PK for two purposes: coinbase outputs (block rewards paid to the miner's public key) and IP-to-IP payments, a feature that allowed one node to send coins directly to another by requesting its public key over a TCP connection. The concept was simple: if you know someone's public key, you can create an output that only their corresponding private key can spend. No intermediate representation was needed. The public key was the identity.

What Satoshi apparently did not anticipate—or chose to accept as a reasonable trade-off—was that embedding the public key directly in the scriptPubKey exposes it to the entire network before the coins are spent. A sufficiently powerful adversary (or, someday, a quantum computer) could work backward from the public key to the private key and steal the funds. This vulnerability would motivate the transition to P2PKH within days, and it haunts Bitcoin to this day: an estimated 1.8 million BTC sits in P2PK outputs whose public keys are permanently visible on the blockchain.

4.1The P2PK Script

We have already seen the P2PK script in Chapters 1 through 3. Here we formalize its structure as a transaction type—a specific pattern of scriptPubKey and scriptSig that Bitcoin nodes recognize and validate.

4.1.1The Locking Script (scriptPubKey)

A P2PK scriptPubKey has exactly two elements:

Or, with a compressed public key (33 bytes):

In Script assembly:

<pubkey> OP_CHECKSIG

That's the entire locking condition: "provide a valid signature for this public key." No hashing, no address derivation, no multi-step verification.

4.1.2The Unlocking Script (scriptSig)

To spend a P2PK output, the scriptSig contains a single element:

In Script assembly:

<sig>

The signature is all that's needed because the public key is already in the scriptPubKey—the verifier doesn't need the spender to provide it again.

4.1.3Our Specimen: Block 170 Revisited

The Block 9 coinbase output that funded Satoshi's payment to Hal Finney is a P2PK output with a 67-byte scriptPubKey:

Bytes	Hex	Meaning
1	41	OP_PUSHBYTES_65: push the next 65 bytes
65	04 11db… b412a3	Uncompressed public key (prefix 04)
1	ac	OP_CHECKSIG
Total: 67 bytes

The 04 prefix byte marks this as an uncompressed point on the secp256k1 curve: 1 byte prefix + 32 bytes \(x\)-coordinate + 32 bytes \(y\)-coordinate = 65 bytes total.

When Satoshi spent this output in Block 170, the scriptSig contained only the DER-encoded signature (71 bytes including SIGHASH):

Bytes	Hex	Meaning
1	47	OP_PUSHBYTES_71: push the next 71 bytes
70	3044… 1d09	DER-encoded ECDSA signature
1	01	SIGHASH_ALL
Total: 72 bytes

The combined P2PK script burden—72 bytes to unlock, 67 bytes to lock—totals 139 bytes for one coin lifecycle. A P2PKH equivalent requires 107 bytes to unlock (signature plus public key in the scriptSig) but only 25 bytes to lock (a 20-byte hash), totaling 132 bytes—a modest saving overall, but with a dramatically smaller output footprint (see Chapter 5). The 65-byte public key in the P2PK output accounts for nearly half the transaction.

4.1.4Execution: The Stack in Action

Let us trace the Block 170 spend step by step through the script engine described in Chapter 2. When a node validates this input, it concatenates the scriptSig (unlocking) and the scriptPubKey (locking) into a single program:

The stack machine processes each element left to right:

Step	Operation	Stack (top → right)
0	(start)	empty
1	Push <sig>	[sig]
2	Push <pubkey>	[sig, pubkey]
3	OP_CHECKSIG	[TRUE]

1. Step 1: The signature (71 bytes of DER-encoded ECDSA + SIGHASH_ALL) is pushed onto the stack.
2. Step 2: The public key (65 bytes, uncompressed, starting with 04) is pushed on top.
3. Step 3: OP_CHECKSIG pops both values. The node computes the sighash—a SHA-256d digest of the transaction data serialized according to the SIGHASH type (Chapter 3)—and verifies the ECDSA signature against the public key. If the signature is valid, TRUE is pushed; otherwise FALSE.

The script succeeds because exactly one element remains on the stack and it is TRUE. This is the simplest possible script execution in Bitcoin: two pushes and one verification. Every later transaction type adds layers between these pushes—hashing, equality checks, witness segregation—but the final step is always the same: OP_CHECKSIG (or its variants) consuming a signature and a key.

4.2The Genesis Block Coinbase

The very first P2PK output ever created was the Genesis Block's coinbase, paying 50 BTC to a public key that belongs to Satoshi Nakamoto:

The coinbase scriptSig (77 bytes, varint 4d) contains three encoded elements:

1. 04 ffff001d — The compact difficulty target (4 bytes, pushed by OP_PUSHBYTES_4).
2. 01 04 — An extra nonce byte (pushed by OP_PUSHBYTES_1).
3. 45 followed by 69 bytes — The famous message, pushed by OP_PUSHBYTES_69:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

This is the most famous coinbase message in history—a headline from The Times of London, serving simultaneously as a timestamp proof (the block was mined on or after January 3, 2009) and a philosophical statement about why Bitcoin exists.

The scriptPubKey of the Genesis coinbase uses a different public key than the one in Block 9. Comparing the first 8 bytes of each:

Block	Public Key (first 16 hex chars)
Block 0 (Genesis)	04 678afdb0fe5548
Block 9	04 11db93e1dcdb8a

Each block reward went to a different key. The original Bitcoin software generated a new key pair for each coinbase output—a pattern later dubbed the Patoshi pattern by researcher Sergio Demian Lerner, who identified a distinctive nonce-scanning behavior in approximately 22,000 early blocks that likely belong to Satoshi's miner.^†

4.3The Block 9 Coinbase

For a cleaner specimen, consider the Block 9 coinbase—the transaction whose output Satoshi spent three days later in Block 170. At only 134 bytes, it is a minimal coinbase transaction:

Compare this to the Genesis Block: the coinbase scriptSig is only 7 bytes (04ffff001d0134) instead of 77—no embedded newspaper headline, just the compact difficulty target and an extra nonce byte. The scriptPubKey is identical in structure (67 bytes: 41 + 65-byte key + ac), and the public key matches the one that appears in Block 170's outputs—confirming that Satoshi used the same key for Block 9's coinbase reward and for the change output when sending coins to Hal Finney.

4.4IP-to-IP Payments

Why did Satoshi design P2PK at all? The answer lies in a feature that no longer exists: IP-to-IP payments.

The original Bitcoin client (version 0.1, released January 9, 2009) included a payment protocol that worked like this:

1. Alice enters Bob's IP address into her Bitcoin client.
2. Alice's client opens a TCP connection to Bob's node on port 8333.
3. Bob's node generates a fresh key pair and sends the public key to Alice.
4. Alice constructs a transaction with a P2PK output paying to Bob's key.
5. Alice broadcasts the transaction to the network.

In this model, P2PK made perfect sense: the recipient provided their public key directly, so the sender used it directly. There was no need for an intermediate hash or address encoding—the public key was the address.

4.5The 130-Character "Address"

Under the original protocol, there was no such thing as a Bitcoin "address" in the sense we use the word today. To pay someone, you needed their entire uncompressed public key—a 65-byte blob rendered as 130 hexadecimal characters:

04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f

That is the Genesis coinbase "address"—Satoshi's public key, displayed exactly the way a 2009 user would have had to copy it from one place to another. The 04 prefix marks it as an uncompressed point on secp256k1; the next 32 bytes are the x-coordinate; the final 32 bytes are the y-coordinate. As a medium for human communication, it has every problem you can imagine:

• No checksum. A single typo produces a different valid-looking hex string. Send coins to the mistyped key and they are permanently burned—no one will ever hold the matching private key.
• No version byte. There is no way to tell whether a hex blob is a mainnet key, a testnet key, a compressed key, an uncompressed key, or unrelated random data. Every interpretation has to be inferred from length and the leading byte.
• No visual distinction. Two different keys look like two identical walls of hex to the human eye. There is no easy way to compare the first and last few characters the way users later would with Base58Check addresses.
• No compact form. Even the 33-byte compressed form (introduced later) is still 66 hex characters—beyond what fits on a business card, an early QR code, or an email signature without line wrapping.
• No error detection at all. Bitcoin's scriptPubKey does not validate that the public key is well-formed until someone tries to spend the output. You learn about a corrupted "address" only by losing the funds.

This was workable only because P2PK was never meant for humans to handle directly. Under IP-to-IP payments, Alice's client received the key automatically over TCP from Bob's node—no typing, no copying, no reading aloud. The moment that assumption broke—when IP-to-IP was deprecated and users had to share payment destinations out-of-band, over email or instant message—the raw public key became unusable, and the need for a real address format became urgent.

Chapter 5 is the answer. Every failure listed above is something P2PKH addresses fix: a checksum catches typos, a version byte distinguishes networks, Base58 produces strings that are visually comparable and short enough to read aloud, and the familiar leading 1 gives every mainnet address an instantly recognizable shape.

4.6The Exposed Key Problem

The defining vulnerability of P2PK is that the public key is visible in the scriptPubKey from the moment the output is created—before anyone attempts to spend it. This has two consequences:

4.6.1Classical Threat: Key Reuse Linkability

If the same public key appears in multiple P2PK outputs, all of those outputs are trivially linked. An observer can see that the same entity controls all of them. This is a privacy concern, though not a security one—no classical algorithm can recover the private key from the public key (the ECDLP is hard for classical computers).

4.6.2Quantum Threat: Key Recovery

A sufficiently powerful quantum computer running Shor's algorithm could solve the elliptic curve discrete logarithm problem in polynomial time, recovering the private key from the public key. For P2PK outputs, the public key is permanently visible, giving a quantum attacker unlimited time to work on the problem.

4.6.3The Numbers

As of 2026, approximately 1.8 million BTC remains locked in P2PK outputs—the vast majority from early coinbase rewards. This includes:

• 1.1 million BTC attributed to the Patoshi miner (likely Satoshi), untouched since 2009–2010.
• Coinbase rewards from early miners who used the original Bitcoin client, which generated P2PK outputs by default.
• Outputs from IP-to-IP payments (a much smaller amount).

At any given Bitcoin price, these P2PK outputs represent a significant fraction of the total supply that is permanently quantum-vulnerable. Various proposals have been floated to address this—from ignoring the problem ("quantum computers are decades away") to soft-forking the protocol to invalidate unspent P2PK outputs after a transition period—but no consensus has emerged.

4.7Compressed vs. Uncompressed Keys in P2PK

All early P2PK outputs used uncompressed public keys (65 bytes, prefix 04). Later software introduced compressed keys (33 bytes, prefix 02 or 03):

The compression works because secp256k1 is defined by \(y^2 = x^3 + 7 \pmod{p}\). For any valid \(x\)-coordinate, there are exactly two valid \(y\) values: \(y\) and \(p - y\). One is even, one is odd. The prefix byte encodes which one:

• 02: \(y\) is even.
• 03: \(y\) is odd.

The receiver computes \(y\) from \(x\) using the equation and selects the correct root based on the prefix. This saves 32 bytes per output—significant when every byte is stored by every full node forever.

4.8P2PK Size Analysis

How much space does a P2PK transaction consume compared to later types? Let's calculate for a minimal 1-input, 2-output transaction (like Block 170):

Field	Bytes	Notes
Version	4	Always 01000000
Input count (varint)	1
Previous txid	32
Previous vout	4
ScriptSig length	1	48 = 72
ScriptSig	72	Push opcode + DER sig + SIGHASH
Sequence	4
Output count (varint)	1
Output 0 value	8
Output 0 scriptPubKey length	1	43 = 67
Output 0 scriptPubKey	67	Push + 65-byte key + ac
Output 1 value	8
Output 1 scriptPubKey length	1	43 = 67
Output 1 scriptPubKey	67	Push + 65-byte key + ac
Locktime	4
Total	275

The two scriptPubKey fields consume \(2 \times 67 = 134\) bytes—nearly half the entire transaction. With compressed keys, these would be \(2 \times 35 = 70\) bytes, saving 64 bytes. With P2PKH (Chapter 5), they would be \(2 \times 25 = 50\) bytes, saving 84 bytes.

This size overhead was one of several motivations for the transition to P2PKH—not the primary one (that was the security benefit of hashing the key), but a meaningful secondary benefit as the blockchain grew.

4.9P2PK in the Modern Era

P2PK stopped being used for regular transactions almost immediately after P2PKH was introduced (Block 728, January 16, 2009—just thirteen days after genesis). However, it continued to appear in coinbase transactions because many mining software implementations retained the original P2PK format for block rewards well into 2011–2012.

Today, P2PK is effectively a museum piece. No modern wallet software creates P2PK outputs, and no commonly used address format corresponds to P2PK (since P2PK predates Bitcoin addresses entirely). But the protocol still supports it: any node will validate a P2PK spend, and the estimated 1.8 million BTC in unspent P2PK outputs remains a live part of the UTXO set.

4.10Exercises

Litmus

1. What is the complete P2PK scriptPubKey for a 65-byte uncompressed public key? How many bytes is it?
2. What is the P2PK scriptSig? How many elements does it contain?
3. True or false: the Genesis Block's 50 BTC can be spent by anyone who derives the private key for its public key.
4. Why does the public key prefix 04 indicate an uncompressed key, while 02/03 indicate compressed?
5. How many bytes does a P2PK scriptPubKey save by using a compressed key instead of an uncompressed key?

Hands-On

1. Parse the Genesis Block coinbase transaction (204 bytes, hex given in this chapter) field by field. Identify the version, input count, null input, coinbase scriptSig (including the "Times" message), output count, value, scriptPubKey, and locktime.
2. Extract the public key from the Genesis Block's scriptPubKey. Using the secp256k1 curve equation \(y^2 = x^3 + 7 \pmod{p}\), verify that the \(x\)-coordinate in the key is a valid point on the curve (compute \(x^3 + 7 \pmod{p}\) and check that the result is a quadratic residue).
3. Compare the Block 9 coinbase (134 bytes) to the Genesis Block coinbase (204 bytes). What accounts for the 70-byte difference? (Hint: compare the coinbase scriptSig lengths.)
4. The Block 170 transaction has two P2PK outputs. Using the public keys from both outputs, compute the RIPEMD-160(SHA-256(key)) hash for each. These hashes are what P2PKH would have used as the locking condition. What are the corresponding Base58Check addresses? (You'll verify these in Chapter 5.)

Proofs

1. Compressed key correctness. Prove that for any point \((x, y)\) on secp256k1, the value \(p - y\) is also a valid \(y\)-coordinate for \(x\), and that exactly one of \(\{y, p-y\}\) is even. (Use the fact that \(p\) is odd and \((-y)^2 = y^2\).)
2. P2PK script security. Prove that a valid P2PK scriptSig can only be produced by someone who knows the private key \(d\) (assuming ECDSA is secure). Specifically, show that the only way to produce a signature \((r, s)\) that passes OP_CHECKSIG against public key \(Q = dG\) is to know \(d\) or break the ECDLP.
3. P2PK vs. P2PKH space savings. For a transaction with \(n\) inputs (each spending a P2PK output) and \(m\) outputs (each creating a P2PK output), derive the total transaction size. Compare to the same transaction using P2PKH. At what ratio of inputs to outputs does the size difference become most significant?

Connections

1. Satoshi's coins and the quantum threat. Research the current state of quantum computing. IBM's Condor processor (2023) has 1,121 qubits; breaking secp256k1 requires an estimated 2,330 logical qubits (or millions of physical qubits with current error rates). How many years might it take to reach this capability? What options does the Bitcoin community have to protect P2PK outputs before then?
2. P2PK in other contexts. P2PK appears in contexts beyond early Bitcoin: some altcoins use it, and the Lightning Network's funding transactions originally used a variant (2-of-2 multisig with raw keys). Research one non-Bitcoin-mainnet use of P2PK-style outputs and explain why that context chose raw keys over hashed keys.

Bridge

1. The address question. P2PK has no addresses. P2PKH introduced the concept of encoding a hash of the public key as a human-readable string. Before reading Chapter 5, work through the following: take the Block 9 coinbase public key, apply SHA-256, then RIPEMD-160, prepend version byte 0x00, compute a 4-byte checksum (first 4 bytes of SHA-256d of the versioned payload), and Base58-encode the result. What address do you get? (Chapter 5 will verify your answer.)
2. From one key to many. P2PK locks funds to a single public key. What if you want to require multiple keys to sign? The next evolutionary step—bare multisig—uses OP_CHECKMULTISIG to require \(m\) of \(n\) signatures. But this creates enormous scriptPubKeys (each key is 65 or 33 bytes, and \(n\) can be up to 20). How does P2SH (Chapter 6) solve this problem? (Hint: hash the entire script.)

4.11Solutions

Litmus Solutions

L1. The complete P2PK scriptPubKey is: 41 <65-byte pubkey> ac. That's OP_PUSHBYTES_65 (1 byte), the uncompressed public key (65 bytes), and OP_CHECKSIG (1 byte) = 67 bytes total. With a compressed key: 21 <33-byte pubkey> ac = 35 bytes.

L2. The P2PK scriptSig is: <push_opcode> <DER_signature + SIGHASH>. It contains exactly one element: the signature. The public key is not needed in the scriptSig because it's already in the scriptPubKey.

L3. False. The Genesis Block's 50 BTC cannot be spent by anyone, regardless of key knowledge. The coinbase transaction was hardcoded into Bitcoin's source code and was never added to the UTXO set. The node software will reject any transaction that tries to spend it because it cannot find the output in the UTXO database.

L4. The prefix byte indicates the key encoding format: 04 means both coordinates (\(x\) and \(y\)) follow (65 bytes total). 02 means only \(x\) follows and \(y\) is even; 03 means only \(x\) follows and \(y\) is odd. The receiver recovers \(y\) from the curve equation \(y^2 = x^3 + 7 \pmod{p}\) and selects the root matching the parity indicated by the prefix.

L5. An uncompressed P2PK scriptPubKey is 67 bytes. A compressed P2PK scriptPubKey is 35 bytes. The savings: \(67 - 35 = 32\) bytes per output (exactly the \(y\)-coordinate that was removed, plus the 32-byte difference between the 65-byte and 33-byte key representations: \(65 - 33 = 32\)).

Hands-On Solutions

H1. Parsing the 204-byte Genesis Block coinbase:

Field	Bytes	Value
Version	4	01000000 (version 1)
Input count	1	01 (1 input)
Prev txid	32	00… 00 (coinbase null)
Prev vout	4	ffffffff (coinbase marker)
ScriptSig length	1	4d = 77 bytes
ScriptSig	77	Difficulty + "The Times…"
Sequence	4	ffffffff
Output count	1	01 (1 output)
Value	8	00f2052a01000000 = 5,000,000,000 sats
scriptPubKey length	1	43 = 67 bytes
scriptPubKey	67	41 04678a… 1d5f ac (P2PK)
Locktime	4	00000000
Total	204

H2. The Genesis Block public key's \(x\)-coordinate (hex):

678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb6

To verify: compute \(x^3 + 7 \pmod{p}\) where \(p = 2^{256} - 2^{32} - 977\). If the result is a quadratic residue modulo \(p\) (i.e., has a square root), then \(x\) is a valid curve point. This can be checked using Euler's criterion: \(a^{(p-1)/2} \equiv 1 \pmod{p}\) iff \(a\) is a QR. (Use Python's pow(x**3 + 7, (p-1)//2, p) — it should return 1.)

H3. The 70-byte difference is entirely in the coinbase scriptSig: the Genesis Block's scriptSig is 77 bytes (varint 4d) including the newspaper headline, while Block 9's scriptSig is only 7 bytes (varint 07). The scriptPubKey lengths are identical (67 bytes each), and all other fields are the same size. Difference: \(77 - 7 = 70\) bytes.

H4. Applying RIPEMD-160(SHA-256(pubkey)) to each 65-byte uncompressed key:

Output 0 (10 BTC to Hal Finney, key prefix 04ae1a62…):

Hash160: fc916f213a3d7f1369313d5fa30f6168f9446a2d

Prepend version byte 00, compute 4-byte checksum (SHA-256d), Base58-encode:

1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3

Output 1 (40 BTC change to Satoshi, key prefix 0411db93…):

Hash160: 11b366edfc0a8b66feebae5c2e25a7b6a5d1cf31

Base58Check address:

12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

These are the P2PKH addresses that block explorers display as "associated addresses" for these P2PK outputs. You can verify both on mempool.space by looking up the Block 170 transaction (f4184fc5…). Chapter 5 will trace the full derivation pipeline—SHA-256, RIPEMD-160, version byte, checksum, Base58 encoding—step by step.

Proofs Solutions

P1. Let \((x, y)\) be a point on secp256k1, so \(y^2 \equiv x^3 + 7 \pmod{p}\). Then \((p-y)^2 = p^2 - 2py + y^2 \equiv y^2 \equiv x^3 + 7 \pmod{p}\), so \((x, p - y)\) is also on the curve.

For parity: \(p\) is odd (it's a large prime \(> 2\)). If \(y\) is even, then \(p - y\) is odd (odd minus even = odd). If \(y\) is odd, then \(p - y\) is even. So exactly one of \(\{y, p-y\}\) is even, and the prefix byte (02 for even, 03 for odd) uniquely identifies which \(y\)-value to use.

P2. Assume ECDSA is secure (the ECDLP is hard). The P2PK scriptPubKey contains public key \(Q = dG\), and OP_CHECKSIG verifies that the scriptSig contains a valid ECDSA signature \((r, s)\) on the sighash \(z\) under key \(Q\).

By the security of ECDSA, producing a valid \((r, s)\) for a given \((z, Q)\) requires either: (a) knowledge of the private key \(d\), or (b) an algorithm that solves the ECDLP (computing \(d\) from \(Q = dG\)). Since we assumed the ECDLP is hard, only (a) is feasible.

Note: this argument assumes the hash function (SHA-256d) is collision-resistant. If an attacker could find a collision in the sighash, they could potentially reuse a signature from a different transaction—but this would require breaking SHA-256, not ECDSA.

P3. For a P2PK transaction with \(n\) inputs and \(m\) outputs (uncompressed keys):

• Fixed overhead: 4 (version) + 1 (input count varint, assuming \(n < 253\)) + 1 (output count varint) + 4 (locktime) = 10 bytes.
• Per input: 32 (txid) + 4 (vout) + 1 (scriptSig length) + 72 (scriptSig) + 4 (sequence) = 113 bytes.
• Per output: 8 (value) + 1 (scriptPubKey length) + 67 (scriptPubKey) = 76 bytes.

Total P2PK: \(10 + 113n + 76m\) bytes.

For P2PKH (Chapter 5 preview):

• Per input: 32 + 4 + 1 + 107 (scriptSig with key + sig) + 4 = 148 bytes.
• Per output: 8 + 1 + 25 (scriptPubKey) = 34 bytes.

Total P2PKH: \(10 + 148n + 34m\) bytes.

Difference: \((113n + 76m) - (148n + 34m) = -35n + 42m\).

P2PK is smaller per input (113 vs. 148, because the scriptSig only needs the signature, not the public key) but larger per output (76 vs. 34, because the scriptPubKey stores the full key instead of a 20-byte hash). The break-even point is \(35n = 42m\), or \(n/m = 6/5\). Transactions with more outputs than inputs (common for batch payments) benefit most from P2PKH's compact outputs.

Connections Solutions

C1. As of 2026, the most powerful quantum processors have 1,000–1,200 physical qubits (IBM Condor: 1,121; Atom Computing: 1,180). Breaking secp256k1's 256-bit ECDLP requires an estimated 2,330 logical qubits using Shor's algorithm.^† With current error rates, each logical qubit requires thousands of physical qubits for error correction, putting the total requirement at millions of physical qubits.

Optimistic estimates (e.g., Google's Willow chip roadmap) suggest fault-tolerant quantum computers with millions of qubits could arrive by the late 2030s or 2040s. More conservative estimates place this in the 2050s or beyond.

The Bitcoin community has several options: (1) do nothing and rely on the timeline being long; (2) implement quantum-resistant signature schemes (lattice-based, hash-based) via soft fork; (3) migrate UTXOs to quantum-resistant address types, potentially with a deadline after which unspent P2PK outputs are frozen or burned. Each option has trade-offs in complexity, urgency, and political feasibility.

C2. Lightning Network funding transactions use 2-of-2 multisig with raw (unhashed) public keys in the witness script. The reason: Lightning requires both parties to construct and sign transactions before the funding transaction is broadcast. The internal scripts (commitment transactions, HTLCs) reference the raw keys because the parties already know each other's keys from the channel opening protocol. Hashing the keys would add no security benefit (both parties already know the keys) and would increase the witness size. The trade-off is that the public keys are revealed when the channel closes on-chain, but since Lightning channels are meant to be ephemeral, the quantum exposure window is limited.

Bridge Solutions

B1. Starting with the Block 9 coinbase public key (0411db93… b412a3):

1. SHA-256 of the 65-byte key: a 32-byte intermediate hash.
2. RIPEMD-160 of the SHA-256 result: a 20-byte hash ("Hash160").
3. Prepend version byte 00: 21 bytes.
4. Checksum: first 4 bytes of SHA-256d(versioned payload).
5. Base58-encode(versioned payload + checksum): the P2PKH address.

Starting from the 65-byte key 0411db93e1dcdb8a… b412a3:

1. SHA-256 produces a 32-byte intermediate hash.
2. RIPEMD-160 of that hash: 11b366edfc0a8b66feebae5c2e25a7b6a5d1cf31 (20 bytes).
3. Prepend 00: 0011b366edfc0a8b66feebae5c2e25a7b6a5d1cf31 (21 bytes).
4. SHA-256d of the 21-byte payload; first 4 bytes = checksum.
5. Base58-encode(21 bytes + 4-byte checksum):

12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S

This is the same address computed in H4 for Satoshi's change output—because the Block 9 coinbase and the Block 170 change both use the same public key. Chapter 5 will trace each of these steps in detail and explain the design choices behind Base58Check encoding.

B2. Bare multisig places all \(n\) public keys directly in the scriptPubKey: OP_m <key1> <key2> … <key_n> OP_n OP_CHECKMULTISIG. For a 2-of-3 with uncompressed keys, this is \(1 + 66 + 66 + 66 + 1 + 1 = 201\) bytes—far larger than P2PK's 67 bytes. P2SH solves this by replacing the entire multisig script with its 20-byte hash in the scriptPubKey: OP_HASH160 OP_PUSHBYTES_20 <20-byte hash> OP_EQUAL (23 bytes: a9 14 + 20 bytes + 87). The full script (the "redeem script") is provided in the scriptSig when spending. This moves the storage cost from output creation to spending, and keeps output sizes constant regardless of script complexity.