more eyes

"It's open source" gets used as if it settles something. It tells you the code can be read. It doesn't tell you that anyone read it, who signed the file you downloaded, whether anyone else rebuilt that file, or which code path actually runs on your machine. Open is not the same as looked at.

more eyes is where I've been working on that gap. It's a set of notes. Each one takes a common claim about software or custody, states what evidence would support it, and reads the public record against that. Each note gives the questions to ask and the artifact that would answer each one.

The notes started in my personal GitHub account in early October and moved to their own organization, more-eyes/notes, later in the month. Old links redirect.

What a Note Is

A note is a versioned, sourced document that follows one question. Every note has the same parts:

  • Start here. The questions that matter, in plain language. You don't need a technical background to use it.
  • Records. What a public source says, with the source, the date it was read, and a pinned version where one exists.
  • Unresolved. What the note did not check. Every record has this line.
  • Questions that make a claim reviewable. A claim you may hear, and the artifact to ask for.
  • References and a changelog. Every version is tagged, so every version stays citable.

The Unresolved line is the part I'd point a skeptic at first. A note says what it read and what it didn't.

What the Notes Are Not

They aren't rankings or verdicts. A note states what a public record shows and what evidence a claim needs. It doesn't say that a product or a project is safe or unsafe.

They aren't findings about anyone. No organization or person is assessed. Where a record involves a person, the note names the role, like the tagger or a maintainer account.

And they aren't the last word. A missing artifact means only that the note doesn't show the claim. The evidence may exist and not have been read yet.

The Seven Notes

Five general notes:

  • Who Can Move Your Bitcoin? (v0.18): questions to ask about any way of holding bitcoin, from a single-signature baseline through nine configurations and the full custody lifecycle. It describes kinds of arrangements and names no company.
  • What Can You Check About a Software Release? (v0.4): separates three checks (was the change public, who signed the release file, did someone else rebuild it) and reads Bitcoin Core's process beside the Linux kernel, Tor Browser, and the Debian archive. It compares processes and doesn't rank them.
  • What Can You Check About a Confidential AI Service? (v0.2): follows the chain from a hardware signature to the software that answered one request, and describes seven patterns in which a passing attestation can mean less than it appears.
  • What Does Multivendor Multisig Take for One Holder? (v0.5): the work list for one person holding bitcoin in a 2-of-3 or 3-of-5 multisig with devices from different makers, from the questions to put to each maker through making the keys, keeping the setup record, spending, practice, and upkeep.
  • What Can You Check About a Package You Install? (v0.1): follows a package from the maintainer's publish step to your machine, comparing the Python Package Index with pip and the npm registry with npm, from each registry's own documentation.

Two notes that apply the method:

  • What Can You Check About an embit Release? (v0.6): the release note's questions put to one Bitcoin library that other projects build on. It records the file on PyPI, the signed tags in the source repository, and the project's written release process. It doesn't assess the library's code.
  • Which Code Actually Runs? (v0.3): fallbacks in software that makes or uses keys, the difference between code that is present and code that is reached, and what the release checks leave open.

Each note's Start here section is the place to begin. The rest of the note is the record behind it.

How They're Made

One person maintains the notes, and that's me. The drafting and the source checks are AI-assisted, and I review every change before it's merged. Each note states what was verified and what wasn't. Treat every statement in the notes as a claim to check, not a fact to accept.

Two files in the repository hold the rules. STYLE.md has the editing rules every note follows: conditions instead of verdicts, a public source for every claim about how a mechanism works, and a condition kept in the same sentence as the claim it limits. AGENTS.md has the instructions for AI agents that draft or check notes: work on a branch, never touch a tag, open every source you cite, and never say you verified something you didn't.

Corrections Wanted

That's the reason for the name.

  • Found an error, or a source a note missed? Open an issue or a pull request. Say which note, which section, and what the source shows.
  • Maintain a project that a note describes? Say so in the issue. A correction from the people who do the work carries the most weight.
  • How a fix lands. A change to a claim, a consequence, or a citation gets a new version and a changelog row. Earlier versions stay available through their tags.

Citing a Note

The notes are licensed CC BY 4.0. You can copy, adapt, and republish them, including commercially, if you give credit. To cite one, give the note's title, its version, "more eyes", and a link to the tagged text, like this one for the custody note:

https://github.com/more-eyes/notes/blob/v0.18/who-can-move-your-bitcoin.md

A link to a tag keeps your citation fixed when the note changes. Each note's changelog links every version to its tag.

Open is not the same as looked at.