Hard Guarantees #8: Naming Is Architecture – Lessons from Bitcoin v0.1

When Satoshi released the first Bitcoin client in 2009, the code didn’t rely on frameworks, design patterns, or abstraction layers.

But it did rely on names.

Functions like:

ConnectBlock() CheckTransaction() GetHash()

These names weren’t just placeholders. They became architecture.

In software, we’re taught that abstractions help us manage complexity. But in Bitcoin, abstractions must also survive time, coordinate globally, and preserve consensus.

That’s why naming matters so much.

When you name a function like CheckTransaction, you’re doing more than labeling logic.

You’re setting an expectation for future developers, for auditors, and for every node on the network.

In the early days, Bitcoin v0.1 had little in the way of layered abstraction. But the lack of layers wasn’t a lack of design. It was a conscious tradeoff.

The code’s structure relied on naming to act as soft boundaries:

• Between validation and policy
• Between node behavior and consensus rules
• Between what can change and what must never change

Over time, the Bitcoin Core project has worked to explicitly reinforce these boundaries with modules, interfaces, and more formal separation of concerns.

But those early names still shape how we think.

The book SICP teaches that naming is the first step in building an abstraction. Bitcoin shows that naming is also a commitment.

Once it’s out in the network and once it’s consensus-critical, it’s forever.

In Bitcoin, naming isn’t just about clarity.

It’s about guarantees: who checks what, when, and why.

The wrong name can mislead reviewers or introduce bugs years later. The right name becomes an anchor the system can build on.

That’s why Bitcoin developers argue over names. It’s part of life cycle development risk management. And it’s part of what attempts to keep the protocol small, comprehensible, and resilient in perpetuity.