8-Step Verification

The full algorithm for verifying a BCA address. Pure hash operations, under 1ms, no external dependencies.

Inputs

An IPv6 address to verify
The BCA Parameters associated with it (see BCA Addresses)

The 8 steps

#	Check	Why
1	collision count ≤ 2	Paper constraint. Only 0, 1, or 2 are valid.
2	subnet prefix matches address	The address's first 64 bits must match the claimed subnet.
3	SHA-256(publicKey) is in transaction's OP_RETURN	Binds the device identity to the Bitcoin anchor.
4	block header is 80 bytes	Format sanity check.
5	Merkle proof: transaction is in the block	Uses double-SHA-256 (Bitcoin's Merkle tree variant).
6	Merkle proof: modifier is in the transaction	Uses SHA-256. Root is the second 32 bytes of the OP_RETURN.
7	block header has at least 16×(sec+2) leading zero bits	This is where 89-bit security comes from. The block's proof-of-work.
8	recomputed Hash1 matches the address's interface identifier	The final binding check. All the other inputs produce this specific address.

Strict mode. IronIP adapters always run all 8 steps. If any step fails, verification fails. No "pending confirmation" bypass — pending anchors simply aren't in the active pool, so pending addresses never reach production verification.

Where the security lives

Step 7 is the one that matters. Checking that a block header has N leading zero bits is cheap (a hash comparison). Producing a block header with N leading zero bits is expensive — that's what Bitcoin miners do for billions of dollars a year in aggregate.

An attacker trying to forge a BCA address would need to produce their own block header meeting the difficulty target. At sec = 2, that's ~2⁸⁹ hash operations. Economically, this maps to millions of dollars of electricity per attempted forgery.

Security levels from the paper

sec	Leading zeros required	Effective security
0	32 bits	59 bits
1	48 bits	75 bits
2	64 bits	89 bits (BSV typical)
3	80 bits	107 bits
5	112 bits	139 bits (BTC typical)

Higher sec values require older blocks with higher relative difficulty, which costs more Bitcoin transaction value to anchor. See the paper notes for the cost/security tradeoff analysis.

Implementation

Reference implementation: src/lib/bca-core.js function verifyBCA(ipv6Address, bcaParams). Zero AWS dependencies. Uses only standard crypto primitives:

SHA-256
Double-SHA-256 (for Bitcoin Merkle tree)
No ECDSA signature verification required (the public key identity is enforced via the OP_RETURN hash check in step 3)

Zero-dependency verification

Every piece of data needed is in the BCA Parameters. No network calls. No database lookups. A standalone verifier runs on any machine with Node.js and hash primitives. See Verify an Address.