Composable Bitcoin Verification

Composable Bitcoin Verification on Zenon

This document examines how Schnorr signatures (on Zenon) and Bitcoin SPV (for Bitcoin state) can compose to form a trust-minimized verification framework. It is not a specification but an architectural outline.

The Composition

Zenon uses EdDSA (Ed25519) for account signatures. Bitcoin SPV uses SHA256 for proof-of-work and Merkle verification. These are independent cryptographic primitives that can compose as follows:

Layer 1: Bitcoin Facts (SPV)

• Verifies: Transaction included in Bitcoin blockchain
• Primitive: SHA256 + Merkle proofs
• Trust: Bitcoin’s proof-of-work majority

Layer 2: Zenon Facts (Signatures)

• Verifies: Account authorized an action
• Primitive: Ed25519 signatures
• Trust: Account’s private key

Layer 3: Composed Facts

• “Account X attests that Bitcoin transaction Y is verified”
• Combines both layers

Why Composition Works

Independence

The two verification layers are cryptographically independent:

1. Bitcoin SPV security depends on SHA256 preimage resistance and Bitcoin’s PoW majority
2. Zenon signature security depends on discrete log hardness (Ed25519 curve)

Neither assumption weakens the other.

Binding

When an account signs a statement about a Bitcoin fact:

Statement: "I verified tx 0x123... at depth 6"
Signature: Ed25519(private_key, statement)

The composition binds:

• The Bitcoin fact (via SPV proof)
• The account’s attestation (via signature)
• The Zenon state transition (via Momentum inclusion)

No Amplification

Composing these primitives does not amplify attack vectors:

• An attacker compromising Bitcoin PoW cannot forge Zenon signatures
• An attacker compromising a Zenon account cannot create valid Bitcoin proofs

Trust Model

What You’re Trusting

Combined Trust

The combined system requires:

• Bitcoin is secure (for the Bitcoin fact)
• Zenon is secure (for the Zenon fact)
• The account correctly performed verification

An attacker must compromise the relevant layer for each component.

Architectural Patterns

Pattern 1: Attestation Model

Account verifies locally, publishes attestation:

Account A:
1. Receives SPV proof
2. Verifies locally
3. Publishes signed statement: "tx 0x123 verified"
4. Other accounts can read A's attestation

Trust: You trust Account A’s verification

Pattern 2: Direct Verification

Each interested account verifies independently:

Account B:
1. Receives same SPV proof
2. Verifies independently
3. Records own state update
4. Does not depend on A's attestation

Trust: You trust your own verification

Pattern 3: Threshold Verification

Multiple accounts verify, quorum required:

Accounts A, B, C all verify
Consensus: 2-of-3 agree on result
Action: Proceed if threshold met

Trust: Majority of verifiers are honest

Practical Considerations

Header Availability

SPV verification requires Bitcoin headers. Headers must be available from somewhere. Options:

• Dedicated header relay service
• P2P header gossip
• External API sources
• Multi-source aggregation

This is the main practical challenge, not cryptographic.

Verification Cost

Each verification costs:

• ~50 SHA256 operations (for headers + Merkle)
• ~1 signature verification (for attestation)

Total: Sub-millisecond on any modern hardware.

State Size

Per verified fact:

• Transaction hash: 32 bytes
• Block reference: 32 bytes
• Depth at verification: 4 bytes
• Account signature: 64 bytes

Total: ~132 bytes per fact

What This Enables

Cross-Chain Triggers

“When Bitcoin tx 0x123 is confirmed, execute Zenon action Y”

SPV provides the trigger, Zenon signature authorizes the action.

Proof of Payment

“I paid 0.1 BTC to address X”

SPV proves the payment, account signature binds it to identity.

Bitcoin-Backed Assets

“This ZTS token is backed by locked Bitcoin”

SPV proves the lock, Zenon state tracks the asset.

Limitations

No Bitcoin Script Verification

SPV proves inclusion, not script validity. A transaction could be:

• Included in a block (provable via SPV)
• Invalid due to script failure (NOT verified by SPV)

This matters for complex Bitcoin scripts but not for simple transfers.

Finality Depends on Depth

SPV security is probabilistic. Deeper confirmations = more security:

• 1 confirmation: ~11% attack probability (q=0.3)
• 6 confirmations: ~0.1% attack probability
• 100 confirmations: Effectively zero

Applications must choose appropriate depth.

Eclipse Attacks

If an account’s header source is compromised, it may verify against a minority fork. Mitigation:

• Multiple header sources
• Threshold agreement on chain tip
• External verification for high-value actions

Summary

Schnorr (Ed25519) and Bitcoin SPV compose cleanly:

• Independent cryptographic assumptions
• No trust amplification
• Clear separation of concerns

The combination enables Zenon accounts to make verifiable statements about Bitcoin state with well-understood security properties.

Document Type: Architectural Overview Status: Analysis complete Dependencies: Standard cryptographic primitives