Scoping the first three: SeedSigner, bitcoinjs-lib, Bitcoin Core

Update, October 2026: Bitcoin Core is no longer in the cut. Zeus took its place. The rest of this post is the original plan.

The OpenSats Red Team grant is for hardening Bitcoin open-source projects using AI. The first decision is which projects to point that work at.

I am starting with three: SeedSigner, bitcoinjs-lib, and Bitcoin Core. This post is the strategy. The next three are the per-project scopes. None of them is a finding.

What “initial” means

It does not mean these are the only things that matter. It means they are a first cut I can actually finish a loop on: scope, review, triage, disclose through the project’s own channel.

A quality-engineering habit that survives contact with models: do not start with the entire ecosystem. Start with a set that covers different failure modes, is legal to study, and is small enough that you can tell the difference between a real defect and a confident hallucination.

Selection rules

I only put a repo on this list if all of the following hold.

I am allowed to study it. Public source, no production services, no live user accounts, no live funds, no public-network testing I have not been authorized to do. OpenSats is explicit about that constraint; so is ordinary professional practice.

Failure has a Bitcoin cost. If the software is wrong, someone can lose coins, sign the wrong transaction, or accept an invalid view of the chain. That is the blast radius that justifies Red Team time.

The three together cut different layers. One signing device that holds keys. One library that many wallets import. One full node that defines what the network will accept. Three wallets would be the same class of bug three times.

There is a disclosure path. Bitcoin Core publishes security@bitcoincore.org. The others have public GitHub projects with a way to report issues. If I cannot name the channel, I do not start.

AI can be an instrument, not a tour. The target has to be something a model can read in pieces with a test suite or a type system nearby. That is a statement about review method, not about importance. Bitcoin Core is more important than SeedSigner. SeedSigner is a better first calibration target.

allowed     # public FOSS, no live funds or third-party systems
cost        # wrongness can move or freeze bitcoin
layer       # keys, library, or node — not three of the same
channel     # a real disclosure path
tractable   # I can finish a loop, not a press release

Why these three

SeedSigner is a DIY air-gapped signing device: Raspberry Pi hardware, a Python application, a Buildroot-based OS image, QR codes as the only I/O. The product is key handling. If the display, the decoder, or the seed path is wrong, the user signs the wrong thing. The codebase is small enough to treat as a system under test.

bitcoinjs-lib is a JavaScript/TypeScript Bitcoin library for Node and browsers. Wallets do not reimplement PSBT, address encoding, and taproot from scratch; they take a library. A defect here multiplies. The project already tells you not to trust master, not to trust npm blindly, and not to treat JavaScript crypto as a solved problem. That is a useful threat model to test against.

Bitcoin Core is the reference full node: peer-to-peer, mempool, consensus, wallet, RPC. It already has years of fuzzing, sanitizers, and a recent third-party audit. I am not going to pretend an AI pass replaces that. It is on the list because it is the root of the stack, and because a Red Team grant that never looks at Core is choosing comfort over the actual system.

The order of work is the reverse of prestige: SeedSigner, then bitcoinjs-lib, then Core. Calibrate the loop where the surface is bounded. Spend the expensive tokens after the method has a shape.

What I will not do on these targets

• Publish exploits, reproduction steps, or non-public findings.
• Test third-party hosted services, other people’s nodes, or mainnet coins.
• Treat model output as a report. Triage is the job.
• Scope “the Bitcoin ecosystem” as if that were a repo.

Each project post names the surfaces I will look at and the channel I will use if something holds up. If you maintain one of these, or you want a different Bitcoin FOSS project in a later cut, the contact section is the contact path.