How we think about building on Bitcoin

When two applications follow the same published format, each can read the other's bytes without asking. That is much of the value of a shared ledger, and a private format gives it away.

We call a pattern settled once two projects have implemented it on their own and read each other's bytes, ideally in two different contexts. Where a standard is silent, we decide locally, write the gap down, and send it to the standard's authors.

In practice: Bitblocks serves proofs as BEEF (BRC-62), and tests its BAP index against vectors shared with a wallet project. The BRCs are the first place we look.

Use the wallet's own identity key, and prove it with a signature. The same wallet then gives the same key to every application, and no application's name becomes part of anyone's identity.

Keep what's hard apart from what's soft. A signature either verifies or it doesn't, and the chain settles that. "This is Alice's current key" is a rule that readers apply to bytes that never change, so a rule like that needs writing down, naming and versioning, like a protocol.

In practice: our BAP index writes its rules down. It accepts a key rotation signed by the root or by the outgoing key, because real identities are published both ways.

The work should come to the key, and the key should never move. BRC-100 is the best answer we know to that: a list of what a website may ask a wallet to do, with one interface across wallets.

So ask for actions, not transactions. Say what you want, and let the wallet pick the coins, sign, and show the person a description they can read. Let proof travel with a payment too, so the receiver can check it against block headers alone.

When we need a reference for wallet behaviour we follow Yours Wallet, and its names and shapes are our default vocabulary. Bitblocks itself holds no keys, because it only reads.

This is the thing that's great if we all build it: a payment that travels with its own proof. Any wallet can send it, any app can accept it, and anyone can check it without asking a company.

Interoperability and value exchange are essential, because a payment only one app can read isn't worth much to anyone else. The specs exist: BEEF, BUMP and BRC-100. What's missing is proof that they work together.

In practice: our interoperability kit publishes test vectors that need no key, along with what a sender and a receiver each do. It has been tried against one SDK and no live wallet so far, so this is a beginning, and we'd welcome company.

People build on what they can trust, and a clear "unknown" earns more trust than a confident guess. Bitblocks says which block its answers reach, and calls an output unspent only when it knows.

Treat Bitcoin as the mechanism rather than the admission ticket. A person came to pay, sell, prove or play, so the bitcoin can stay quiet until it helps them.

Show the real thing rather than a mockup, and make each claim something a reader can open.

The chain is the source of truth, and an application is a projection of it. One app writing and another reading the same transaction is the strongest test we know.

Start small: pay, then note, then prove. A note needs no counterparty, only a record that can't change. Proving is where two parties point at the same transaction and neither one's database has to be believed.

Put anything you need to change in a spendable output. Spending an output is the one update the chain enforces, and everything else is appending.

Primary sources age best, and this ecosystem publishes plenty of them. These are where we go first.

• BRCs

  The published standards, in one repository.

• Bitcom

  unwriter's convention for protocols as addresses, with its commands and spec.

• BSV Skills Center

  Documentation on the whole system, from quick starts to running a node.

• BSV Radar

  A public directory of Bitcoin applications.

Our own transaction types page is a good companion: what each kind of transaction is, with real examples.

• Bitcom, still

  A protocol is an address, and an address is a user. It's a small idea that still holds up, which is why we run a live registry of it.

• 1Sat Ordinals

  An object lives in a one-satoshi output, so owning it and moving it are plain Bitcoin.

• One wallet interface

  Wallets and applications meeting at BRC-100, with the tooling built in the open.

• Teranode

  A new node implementation, developed in the open, with a Docker quick start.

• Digital product passports

  A standard with specifications, test fixtures and a reference implementation, which is a good way to publish one.

Rexxies belong here too: the chain still holds an app's objects, and we can still follow them, long after the tools that made them moved on.