FAQ

Common questions with direct answers. No marketing fluff.

Concept

Why not just use PKI?

PKI works and scales to billions of certificates (see public web PKI). But it has operational baggage that breaks down at IoT scale:

Certificate distribution at 10M+ devices is a logistical nightmare.
Revocation via CRL/OCSP requires always-on infrastructure.
CA is a single point of trust; compromise is catastrophic.
Certificate lifecycle (issuance, renewal, revocation) is ongoing operational cost.

IronIP is a complementary layer, not a replacement. Application-layer auth (which often uses PKI-backed tokens) is still needed for authorization. IronIP just adds network-layer identity underneath, where PKI's operational cost is highest.

Does my device need a wallet?

No. The device stores ~1.2KB of BCA Parameters and performs SHA-256 hashes. That's it. No blockchain sync, no transaction signing, no UTXOs. See Bitcoin as Infrastructure for the wallet-ownership table.

Can constrained devices run this?

Yes, with a floor. Devices need:

~1.2KB storage for BCA Parameters
SHA-256 primitive (available on all Cortex-M0+ and up)
IPv6 addressing support

This rules out 8-bit microcontrollers but comfortably fits everything from Cortex-M3 upward — which is most modern IoT silicon.

How is this different from SEND?

SEND (RFC 3971) uses CGA for address generation. CGA at meaningful security takes ~696 seconds per address. IronIP replaces CGA with a Bitcoin-anchored construction: same RFC role, same security property, but under 1ms per address. IronIP makes SEND actually viable. See IPv6 Extensions.

Bitcoin dependency

What if Bitcoin goes away?

IronIP is chain-agnostic by design — BSV, BTC, BCH all supported with a config change.
Historical anchors remain verifiable offline forever via stored block headers. You don't need Bitcoin to be live to verify an existing BCA address.
New registrations would need to move to another chain, but the verification algorithm is identical.

You're depending on a third-party blockchain explorer (WhatsOnChain)

WhatsOnChain is only needed at registration — a one-time backend operation.
Deployed devices in the field never contact WhatsOnChain. Verification is fully local.
Multiple BSV APIs exist as fallbacks (GorillaPool, TAAL/ARC, direct node RPC).
Operators can run their own BSV node if third-party dependency is unacceptable.
Registration is batchable and retryable: if the API is down, registrations queue and retry asynchronously.

What's the failure mode when Bitcoin has issues?

Fee spikes: BSV median fee is ~$0.00002. Even a 100× spike makes anchoring $0.002 — still negligible.
Chain reorgs: rare. When they happen, the anchor tx typically ends up in the replacement block; re-fetch block header. Deployed devices continue verifying — reorgs don't invalidate existing anchors.
API rate limits: handled via exponential backoff and fallback providers.
Devices don't see any of this: blockchain is never on the critical path of device operation.

Isn't the database the real source of truth, not Bitcoin?

The trust model has two distinct concerns, often conflated:

"Is this identity authentic?" — Bitcoin is the source of truth. Block header, PoW, Merkle proofs all verifiable from on-chain data alone.
"Where do I get the parameters?" — the database, or firmware, or a peer. These are distribution mechanisms, not trust sources. BCA Parameters are self-authenticating: if the 8-step verification passes, they're authentic.

If the database is lost, Bitcoin still has the anchor. The public key hash and Merkle root are recoverable from on-chain data. The only off-chain data is the modifier set, which travels with the device. So anchor + device = full recoverability.

Why not a private/consortium ledger?

No infrastructure to run. Bitcoin miners maintain the network.
No trust required. Private ledgers mean trusting whoever runs them. Bitcoin's PoW is physics.
Survives the operator. Private ledgers die with their operator.
89-bit security for free. Replicating Bitcoin's hash rate privately would cost billions.

Can you do this on BTC instead of BSV?

Yes. The construction is chain-agnostic. Trade-offs:

BSV: ~$0.00004 per anchor, 89-bit security. Current default.
BTC: ~$1.30-2.50 per anchor (fee-market dependent), ~139-bit security. Higher cost, higher security.
BCH: ~$0.002-0.007 per anchor, 89-bit security. Middle ground.

Security and compliance

Is this post-quantum?

The core construction uses SHA-256 (post-quantum secure under current understanding, with effective security halved to 128 bits against Grover's algorithm — still far beyond 89-bit ECDLP equivalent). It doesn't rely on ECDSA for verification of the BCA address itself — identity binding is hash-based via OP_RETURN.

Signed-request extensions (wallet liveness) do use ECDSA, so those would need post-quantum signature migration when the threat becomes real.

What about revocation?

Not currently built. On the roadmap as PushDrop Revocation — spend-to-revoke mechanism that makes revocation state globally consistent via Bitcoin UTXO state. Until then, revocation must happen at application layer.

How does an IronIP device pay for the services it uses?

Payment middleware is on the roadmap (Tier 6c). The vision pairs IronIP identity with BRC-103 peer-to-peer mutual authentication and BRC-29 payment channels: devices prove identity, establish authenticated sessions, and pay per-request or per-packet using BSV micropayments — all anchored to the same key that already establishes the device's network identity. Supports pay-per-API-call (HTTP 402 style), streaming pay-per-packet (payment channels), prepaid quotas, and tiered access combined with BRC-52 certificates. No accounts, no credit cards, no OAuth dance. The Bitcoin payment is the authorization.

What about FIPS 140-2 / 140-3?

IronIP uses only FIPS-approved primitives: SHA-256.
The hash function is swappable to a FIPS-validated module.
For certification-sensitive deployments, the verifier can run inside the certified boundary of an HSM or secure element.

See Compliance Notes for the detailed pathway.

Common Criteria certification impact?

BCA address generation and verification run outside the certified boundary of a CC EAL4+ secure element. The element exports a public key (as it does today); IronIP consumes that public key. No CC recertification is required for devices that add IronIP on top of an already-certified secure element.

Who would certify this?

Not yet applicable — IronIP is a research-stage implementation. For production deployment, independent security review at a top venue plus one or more reference customer deployments would typically precede formal certification. The primitives are standard (SHA-256, Merkle trees), so the certification gap is about the combination, not any individual component.

Scope and limitations

Does BCA solve source IP spoofing?

On private/controlled networks, yes. The network boundary is the trust boundary; spoofing requires physical or logical network access.

On public/shared networks, no — BCA proves the identity was registered, not this packet came from that device. Pair with IPsec or application-layer signing. See Known Limitations.

Does it replace cloud authentication?

No. IronIP is network-layer identity; cloud auth is application-layer authorization. Both are needed. IronIP makes the hardware token more valuable, not less — it becomes the root of a permanent, provider-independent identity that application auth can then build on.

Can I use this without AWS?

Yes. The 8-step verification has zero AWS dependencies. Standalone verifier script (scripts/standalone-verify.js) runs on any Node.js. Adapters for NGINX and Envoy operate without AWS. IronIP's AWS integration is for the demo deployment, not a requirement of the construction.

FAQ