Paper Notes

Annotated summary of "IPv6 Bitcoin-Certified Addresses for IoT Networks" by Mathieu Ducroux (nChain AG), arXiv:2311.15842.

Citation

Ducroux, M. (2023). IPv6 Bitcoin-Certified Addresses for IoT Networks. arXiv:2311.15842v1.

Status

Preprint. Not peer-reviewed at a top security venue. Authored by a researcher at nChain AG. No known production deployments prior to this IronIP implementation.

The problem the paper addresses

CGA (RFC 3972) was designed for SEND (RFC 3971) to let IPv6 devices prove identity at the network layer without certificates. The idea was good; the performance was fatal:

CGA security relies on a device performing its own proof-of-work to extend the hash length beyond 59 bits.
At sec = 2, this takes approximately 696 seconds per address on commodity hardware.
IoT devices can't afford this — not the time, not the energy.
Practical deployments use sec = 0 or sec = 1, giving only 59–75 bits of security.

The paper's insight

Bitcoin miners already do massive proof-of-work. What if IoT devices could borrow that work?

The construction anchors a device's public key to a Bitcoin transaction via OP_RETURN. The block header mining that transaction carries the proof-of-work. The device's IPv6 address then derives from a hash incorporating the block header, transaction, and a device-specific modifier.

The security level achievable is determined by the Bitcoin block's difficulty, not the device's CPU. At modern Bitcoin (BSV) difficulty, sec = 2 gives 89-bit security — in <1ms per address on any microcontroller.

Key definitions from the paper

Symbol	Meaning
`PK`	Device's public key
`m_i`	Modifier i (16 random bytes), i ∈ [0, 31]
`MR`	Merkle root of the 32 modifiers. Placed in the anchor tx's OP_RETURN.
`tx`	The Bitcoin anchor transaction. Contains `OP_RETURN(H(PK) ‖ MR)`.
`BH`	The 80-byte block header that includes `tx`.
`P`	Subnet prefix (/64 IPv6 prefix).
`cc`	Collision count, ∈ {0, 1, 2}.
`Hash1`	`SHA-256(m_i ‖ BH ‖ P ‖ cc ‖ tx)` — the output whose leftmost 64 bits form the interface identifier.
`sec`	Security parameter encoded in the interface ID. Determines required leading-zero bits in `SHA-256²(BH)`.

Paper Table I — security levels

sec	Leading zero bits required in BH hash	Effective security
0	32	59 bits
1	48	75 bits
2	64	89 bits
3	80	107 bits
4	96	123 bits
5	112	139 bits
6	128	155 bits
7	144	171 bits

Paper Table II — BCA Parameters

The 8 fields that travel with a device to enable offline verification. IronIP's src/lib/bca-core.js uses the same names.

modifier
publicKey
transaction
blockHeader
subnetPrefix
collisionCount
merkleProofTx — proof that tx is in the block identified by blockHeader
merkleProofMod — proof that modifier is in the Merkle tree whose root is stored in tx's OP_RETURN

Paper Section IV — verification algorithm

The 8 steps. Full walkthrough in 8-Step Verification. Key points:

Steps 1–4 are cheap format/sanity checks.
Step 5 uses double-SHA-256 (Bitcoin's Merkle tree variant).
Step 6 uses plain SHA-256 (the modifier Merkle tree is app-defined).
Step 7 is where the 89-bit security comes from: the block header's hash has ≥64 leading zero bits.
Step 8 ties everything together: recomputed Hash1 must equal the address's interface identifier.

Departures and extensions in IronIP

Strict mode. The paper allows verifiers to make policy decisions on partial verification. IronIP adapters always require all 8 steps to pass.
Anchor pool. The paper doesn't address the ~10-minute Bitcoin confirmation latency for demo UX. IronIP adds a pre-confirmed pool pattern. See Anchor Pool.
Transport adapters. The paper focuses on the address construction. IronIP adds concrete adapters for API Gateway, ALB, CloudFront, NGINX, Envoy, IoT Core, and (planned) strongSwan / WireGuard.
PushDrop revocation. The paper does not address revocation. IronIP roadmap includes a PushDrop-based revocation mechanism. See roadmap.

Open questions from the paper

Formal security analysis against adaptive adversaries — the paper proves the core construction but doesn't cover all attack surfaces.
Behavior under chain reorganization — handled in IronIP's confirm.js by re-fetching block header after reorg, but the paper doesn't specify a canonical recovery procedure.
Revocation — explicitly out of scope in the paper.
Interaction with IPsec / SEND / SAVI — discussed at a high level but no concrete protocol integration.

Why we implemented this anyway

Even as a preprint, the core contribution is solid: SHA-256, Merkle trees, and Bitcoin PoW are each battle-tested individually. The combination is novel but doesn't introduce new cryptographic assumptions. A working implementation lets us pressure-test the ideas in practice, identify gaps (like revocation and strict verification UX), and build the adapter ecosystem that the paper gestures at but doesn't concretely specify.