Composable Bitcoin Verification Review

Composable Bitcoin Verification: Hostile Review

Document Type: Critical Technical Review Purpose: Identify weaknesses, unstated assumptions, and potential failure modes

Review Approach

This document subjects the “Composable Bitcoin Verification” framework to hostile analysis. We assume an adversarial reviewer attempting to find flaws, edge cases, and unstated assumptions.

Critique 1: “Independence” is Weaker Than Claimed

The Claim

“The two verification layers are cryptographically independent… Neither assumption weakens the other.”

The Problem

While the cryptographic primitives are independent, the operational security is not:

Shared Infrastructure Attack: If the same infrastructure serves both Bitcoin headers and Zenon state, a single point of failure compromises both.

Timing Correlation: An adversary observing both networks can correlate Bitcoin header requests with Zenon account activity, breaking privacy.

Implementation Coupling: A bug in the SPV verification code could be exploited to compromise account state, even though the primitives are theoretically independent.

Severity: Medium

The independence claim is cryptographically correct but operationally misleading.

Critique 2: The Attestation Model Introduces Trust

The Claim

“Pattern 1: Account verifies locally, publishes attestation”

The Problem

This pattern introduces exactly the trust dependency the document claims to minimize:

If Account A attests "tx verified"
And Account B relies on A's attestation
Then B trusts A's:
- Implementation correctness
- Operational security
- Honest behavior

This is functionally equivalent to an oracle, with all associated trust assumptions.

The Worse Problem

The document doesn’t clearly distinguish when you MUST trust an attestation vs. when you CAN verify directly. This ambiguity could lead developers to introduce unnecessary trust dependencies.

Severity: High

The trust model section is incomplete.

Critique 3: Header Availability is Hand-Waved

The Claim

“Headers must be available from somewhere. Options: [list of options]. This is the main practical challenge, not cryptographic.”

The Problem

This dismisses the hardest part of the system. In practice:

Eclipse Attack Surface: Every header source is a potential eclipse attack vector. The document lists “multi-source aggregation” but doesn’t specify:

• How many sources constitute safety?
• How to handle disagreement?
• What if all sources are compromised?

Liveness Dependency: If header availability fails, verification fails. The document doesn’t address:

• What happens to pending verifications?
• How long can the system tolerate header unavailability?
• What’s the degradation mode?

Economic Attacks: Header provision has costs. Who pays? If relayers aren’t compensated:

• Service may not exist
• Service may be low-quality
• Service may be monopolized

Severity: Critical

You cannot build a system on “this is the main practical challenge” and then not address it.

Critique 4: Finality Analysis is Incomplete

The Claim

“Deeper confirmations = more security:

• 6 confirmations: ~0.1% attack probability”

The Problem

This analysis assumes:

1. Static attacker hashpower
2. No selfish mining strategies
3. Attacker doesn’t know transaction value
4. No timing attacks

Real-world considerations:

Value-Dependent Attacks: If a Zenon bridge holds 1000 BTC, an attacker might temporarily rent hashpower for a double-spend. The 0.1% figure assumes a 30% adversary; rented hashpower can temporarily exceed 50%.

Observation Window: An attacker can observe the Zenon transaction and then decide whether to attack Bitcoin. This is a timing advantage not captured in static analysis.

Reorg Propagation: If Zenon acts on a Bitcoin transaction that is later reorged, what happens? The document doesn’t address state rollback.

Severity: Medium-High

The finality analysis needs adversarial scenarios, not just probability tables.

Critique 5: “No Amplification” is False

The Claim

“Composing these primitives does not amplify attack vectors”

The Problem

Composition DOES amplify certain attacks:

Attack Surface Addition:

• Standalone Zenon: Attack surface = Zenon
• Standalone Bitcoin: Attack surface = Bitcoin
• Composed: Attack surface = Zenon + Bitcoin + bridge logic

The attack surface is strictly larger.

Complexity-Induced Bugs: Complex cross-chain interactions create novel failure modes that don’t exist in either system alone. Examples:

• Race conditions between chains
• State inconsistency during reorgs
• Unexpected interaction between consensus mechanisms

Economic Amplification: If Zenon state depends on Bitcoin state, an attacker might profit on Zenon by attacking Bitcoin. This creates economic amplification: the attacker’s profit might exceed the cost of attacking Bitcoin.

Severity: Medium

The “no amplification” claim is misleading at best.

Critique 6: Script Verification Gap is Underplayed

The Claim

“SPV proves inclusion, not script validity. This matters for complex Bitcoin scripts but not for simple transfers.”

The Problem

“Simple transfers” is doing a lot of work here:

P2SH and P2WSH: Many “simple” Bitcoin transactions use script hashes. SPV cannot verify:

• That the spend conditions were met
• That the witness data was valid
• That the script didn’t fail

Multisig Wallets: A 2-of-3 multisig looks like a “simple transfer” but could be spent incorrectly (e.g., with invalid signatures that miners accept due to bugs).

Replace-By-Fee (RBF): A transaction can be included in the mempool, observed by SPV-watching systems, and then replaced with a conflicting transaction. This is “simple” but exploitable.

What’s Actually Safe

Only very specific transaction types are safe to verify via SPV:

• Already-spent outputs (historical verification)
• Outputs with timelock that has passed
• Outputs you control (you know the spend conditions)

Severity: High

The document should explicitly enumerate what transaction types are safe to verify.

Critique 7: Missing Incentive Analysis

Not Addressed

The document doesn’t analyze:

• Why would anyone run header relayers?
• What’s the cost/benefit for attestation providers?
• How does the system bootstrap without centralized infrastructure?
• What prevents a race to the bottom in relay quality?

Without incentives, the system depends on altruism, which is not a security model.

Severity: High

Critique 8: Threshold Verification Doesn’t Help

The Claim

“Multiple accounts verify, quorum required: 2-of-3 agree on result”

The Problem

If all 3 accounts receive headers from the same source, they’ll all be wrong together. Threshold verification protects against:

• Individual account compromise
• Random implementation bugs

It does NOT protect against:

• Shared dependency compromise
• Systemic header source failure
• Coordinated attack on all verifiers

What Would Help

Diversity requirements:

• Different header sources per verifier
• Different code implementations
• Different geographic/network locations

The document doesn’t specify any of this.

Severity: Medium

Summary of Issues

Recommendations

1. Don’t ship this as-is: The header availability problem alone makes this incomplete.

2. Trust model rewrite: Clearly separate “trustless verification” from “trusted attestation.”

3. Adversarial scenarios: Add explicit attack scenarios with mitigations.

4. Incentive design: Add economic analysis before any implementation.

5. Scope limitations: Explicitly state what this does NOT solve.

Review Status: Significant issues identified Recommendation: Major revisions required before use as implementation guide