MASTERING-BITCOIN · Unit 6 · Video 1

Bitcoin Doesn't Move: Interactive Practice

IKey Reference

Concept Description
Transaction model Bitcoins are database entries, not objects. "Sending" means broadcasting a transaction that updates every full node's database.
Version field The first 4 bytes of a transaction. Creates protected rule zones — new consensus rules (e.g., BIP 68) only apply to transactions with the appropriate version.
Marker byte (0x00) In segwit format, sits where the input count would be in legacy format. Legacy nodes read it as "zero inputs → invalid" and reject; modern nodes recognize it as a format marker.
Flag byte (0x01) Follows the marker in segwit format. Other values are reserved for future format extensions.
Serialization order Version → [Marker, Flag] → Inputs → Outputs → [Witness] → Locktime. Brackets indicate segwit-only fields.

IIVisualization 1: Transaction Serialization Layout

A serialized Bitcoin transaction is a sequence of bytes. The legacy format and the segwit format differ by three fields: a marker byte, a flag byte, and a witness section.

Use the toggle below to compare the two formats and see exactly where the segwit-only fields appear.

⚙ interactive visualization — coming to this page format soon

Notice: In segwit format, two extra bytes (the marker 0x00 and the flag 0x01) sit between the version and the input count. These two bytes are exactly where a legacy node expects to find the input count — and that placement is no accident.

IIIVisualization 2: The Marker Byte Trick

When a node reads a transaction, the first 4 bytes are the version. The very next byte is critical:

Use the slider to set what byte appears in that position and see how each type of node reacts.

⚙ interactive visualization — coming to this page format soon

Reflect: Why is 0x00 the perfect choice for a marker byte? Try byte value 0 vs. any non-zero value. Notice that 0x00 would mean "zero inputs" in the legacy format — and a transaction with zero inputs is always invalid. So legacy nodes safely reject the transaction without crashing, while modern nodes treat the same byte as a signal to switch parsers. Invalidity itself becomes the signal.

IVVisualization 3: Version Numbers as Protected Zones

BIP 68 introduced new sequence-field constraints — but they only apply to transactions with version ≥ 2. This protects presigned version-1 transactions (used by Lightning Network) whose signing keys may have already been discarded.

Pick a transaction version and a consensus rule, and see whether the rule applies.

⚙ interactive visualization — coming to this page format soon

Notice: Each version creates an isolated rule domain. A presigned v1 transaction sitting in a Lightning channel for years stays valid no matter how many new BIPs activate at higher versions. This is what the script means by "a contract with the future."

VQuiz Questions

Question 1

Alice "sends" 0.5 BTC to Bob. Which best describes what physically happens on the network?

✅ Correct! Bitcoin ownership is a database entry, not a movable object.

❌ Not quite. Bitcoin doesn't have a central server, and no object travels between wallets. Think of how a land registry works.

Show solution

Solution:

Bitcoin works like a land registry, not like physical cash. When Alice "sends" coins:

  1. She creates a transaction (a small piece of data) and broadcasts it to the network.
  2. Every full node independently validates the transaction against consensus rules.
  3. If valid, each node updates its own copy of the ownership database.

Nothing physically moves between wallets. There is no central server. The coins themselves are just entries in a distributed database — saying "these coins are spendable by [public key]" — not discrete digital objects.

The verb "send" is useful shorthand, but the actual mechanism is persuasion: convincing thousands of independent nodes to update their records.

Question 2

In the legacy transaction format, what field comes immediately after the 4-byte version field?

✅ Correct! In legacy format, the byte after the version is the input count.

❌ Not quite. The marker, flag, and witness fields are segwit-only. They don't appear in legacy serialization at all.

Show solution

Solution:

The legacy serialization order is:

Version (4 bytes) → Input Count (varint) → Inputs → Output Count → Outputs → Locktime (4 bytes)

The marker, flag, and witness fields exist only in the segwit (extended) format. In legacy, the byte right after the version is the input count.

This is exactly why the segwit designers chose 0x00 for the marker: it sits in the same byte position where legacy nodes look for the input count. A value of zero means "zero inputs," which is always invalid, so legacy nodes reject the transaction cleanly instead of crashing.

Question 3

True or False: BIP 68's new sequence-field constraints apply to all Bitcoin transactions, including version-1 transactions that were presigned years before BIP 68 activated.

✅ Correct! BIP 68 applies only to version ≥ 2, protecting v1 presigned transactions.

❌ Not quite. If BIP 68 applied to all versions, presigned v1 transactions in Lightning channels could be invalidated — destroying funds permanently.

Show solution

Solution: False.

BIP 68's constraints apply only to transactions with version 2 or higher. Version-1 transactions are completely unaffected.

This was a deliberate engineering decision. Without this protection:

  • Lightning Network channels that contained presigned v1 transactions could suddenly violate the new rules.
  • Those funds would be permanently destroyed — the signing keys had already been discarded, so no replacement transaction could ever be created.

Version numbers therefore function as protected rule zones. Each version isolates a set of consensus rules. New constraints only enter at higher versions, ensuring that already-signed transactions remain valid forever.

This is why the script calls Bitcoin's transaction format "a contract with the future."

Question 4

Why was 0x00 specifically chosen as the segwit marker byte (rather than, say, 0x42 or 0xFF)?

✅ Correct! The genius is using invalidity as a signal — legacy nodes safely reject; modern nodes recognize the marker.

❌ Not quite. The choice of 0x00 has nothing to do with TCP/IP or compactness. Think about what 0x00 means when a legacy node reads it as the input count.

Show solution

Solution:

The marker byte sits in the exact byte position where a legacy node expects to read the input count. The designers needed a value that legacy nodes would interpret as something unambiguously invalid, so that:

  1. Legacy nodes reject the transaction safely — no crash, no confusion, no fork.
  2. Modern nodes can recognize the same byte as a signal to switch into segwit-parsing mode.

A transaction with zero inputs is always invalid by Bitcoin's consensus rules — there's no source of funds. So when a legacy node sees 0x00 as the input count, it cleanly rejects the transaction.

This technique — using invalidity itself as a signal — is what allows one byte stream to carry two compatible interpretations:

  • Legacy node: "input count = 0 → invalid → reject"
  • Modern node: "marker = 0x00 → extended format → read flag, then witness"

The flag byte that follows is currently 0x01; other values are reserved for future format extensions.

Solved: 0 / 4