From IP Addresses to Public Key Hashes — Interactive Practice

Solution:

HASH160 is the composition of two hash functions applied in order:

$$K \;\xrightarrow{\text{SHA-256}}\; \text{32-byte digest} \;\xrightarrow{\text{RIPEMD-160}}\; \text{20-byte hash}$$

The inner SHA-256 produces 32 bytes. That digest is then fed into RIPEMD-160, whose output length is 20 bytes (hence the "160" — 160 bits = 20 bytes).

So the final HASH160 output is 20 bytes. This is the value that sits inside a P2PKH output script as the commitment.

Solution:

After the input script pushes <sig> and <pubkey>, the stack is [sig, pubkey]. The script now needs to do two things with the pubkey:

1. Hash it with OP_HASH160 and compare against the 20-byte commitment (OP_EQUALVERIFY). This proves the spender revealed the right key.
2. Verify the signature against the pubkey with OP_CHECKSIG.

Both OP_HASH160 and OP_CHECKSIG consume the public key — they pop it off the stack. So without OP_DUP, the first operation would destroy the key before the second operation could use it.

OP_DUP duplicates the top of the stack, leaving [sig, pubkey, pubkey]. The top copy is then consumed by the hash check, and the remaining copy is consumed by the signature check. Every opcode earns its place.

Solution: True.

In the early Bitcoin design, you didn't share your public key directly — you shared your IP address. The payment flow was:

1. Alice's node connects to the receiver's IP.
2. The receiver's node generates a fresh 65-byte public key and returns it.
3. Alice builds the P2PK transaction and broadcasts.

If the receiver was offline, behind a NAT router, or blocked by a firewall, step 2 failed and the payment never happened. That's why you couldn't put an IP address on a business card, email an invoice, or accept donations while asleep.

P2PKH fixed this by letting you publish a 20-byte hash once, through any medium, without needing an active network connection. The full public key is only revealed later, at spend time — by you.

Solution:

Let's trace the stack step by step, starting from [sig, pubkey, H(pubkey)]:

OP_EQUALVERIFY is equivalent to OP_EQUAL followed by OP_VERIFY:

• OP_EQUAL pops the top two items, compares them, and pushes 1 if equal or 0 if not.
• OP_VERIFY pops that result and aborts the script if it is 0. If it is 1, execution continues — and OP_VERIFY leaves nothing on the stack.

So the combined effect of OP_EQUALVERIFY is: pop two items, abort if unequal, otherwise continue with both popped and nothing added. The final stack is [<sig>, <pubkey>] — exactly the two items OP_CHECKSIG needs next.

❌ [<sig>, <pubkey>, 1] would be the result of a plain OP_EQUAL, not OP_EQUALVERIFY.