Threat Model

Assumptions

What We Assume

  • All counterparty proposals must be verifiable before transacting
  • All validators are potentially hostile
  • Agents will attempt to spoof users and nodes
  • Networks may become partitioned
  • DDoS may require rate-limiting
  • Nation-state actors will attack the network
  • Encryption upgrades require coordination

What We Do NOT Assume

  • Validators are honest
  • Networks are always reliable
  • Users are honest
  • Coordinating decentralized parties is possible

⚠️ Warning: Geeq is designed to resist all adversarial attacks, including nation-state attacks and spoofing by agents.

Adversary Capabilities

Adversary Can

  • Control up to 99.9% of validators without triggering reset
  • Delay network messages
  • Submit invalid transactions
  • Attempt double-spend attacks
  • Analyze all public blockchain data
  • Run multiple nodes (Sybil attack attempts)

Adversary Cannot

  • Break specific chain's cryptography
  • Permanently partition the network
  • Spend others' tokens without private keys
  • Avoid detection when behaving dishonestly

Defense Mechanisms

Transaction Finality

2-Block Finality Guarantee

  • Transaction will not be reversed (unlike two-stage optimistic / challenge proofs)
  • No probabilistic finality
  • No need to trust third parties (provers, sequencers, etc.)

✅ Success: Transactions confirmed in 2 block intervals are final. Block intervals are a parameter per chain, 1-10 seconds recommended, depending on latency and bandwidth. Compare to Bitcoin (60 minutes) and Ethereum (13 minutes).

Byzantine Fault Tolerance

Tolerance Level

  • Tolerates up to 99.9% dishonest validators
  • If 100% network takeover, fallback to last provably honest block is possible
  • Detection: Edge discovery via transaction and/or block hash comparison
  • Audit: Automatically triggered by protocol, dishonest validators ejected

Attack Analysis

51% Attack

Geeq Resistance

ℹ️ Info: The term "51% attack" doesn't apply to Geeq. Resistant to completely adversarial attacks.

Why This Works

  • Every validator is required to add its signature to each stage of block construction
  • Every validator independently validates, constructs its own block
  • Queries for missing transactions occur before validation
  • Dishonesty is provable by honest validators in the next block
  • Applications or users can confirm proof of validity exists or not
  • Independent verifiability consists of hashing only (easy)
  • Dishonest validators lose stake and reputation
  • Network failures (partitions) do not receive necessary validator signatures, can catch up later without coordination

Attack Cost Analysis

To attack Geeq: Any attempt is possible, attacks result in provably invalid states.

  1. Acquire 2/3 of validator stakes
  2. Coordinate dishonest behavior
  3. Accept: Immediate detection
  4. Accept: Loss of all stake
  5. Accept: Permanent reputation destruction

Gain: One fraudulent transaction before detection in the next block, then ejection.

Result: Economically irrational.

Network Partition Attack

Attack Scenario

  • Attacker splits network into two groups
  • Different groups see different transactions
  • Partitioned group becomes stalled

Geeq Response

Partition occurs:

  • Group A: Continues validating in non-partitioned group
  • Group B: Continues validating in partitioned group without access to necessary rotating network signatures

Resolution:

Groups merge: Conflict resolution via proofs + network signatures, canonical branch choice is pre-determined.

  1. Compare block timestamps
  2. Earlier timestamp wins
  3. Later blocks reorganize
  4. Applications notified of reorganization

⚠️ Warning: Deep network partitions may cause temporary inconsistencies. Applications should monitor partition alerts from internet outages.

Long-Range Attack

Attack Scenario

  • Attacker acquires old validator keys
  • Attempts to rewrite blockchain history from genesis

Defense

  • Validators sign each block with current keys
  • Applications checkpoint recent blocks
  • Historical rewriting requires finding appropriate collisions for each block to satisfy per transaction, per block proofs

Result: Long-range attacks on a single chain are practically infeasible, even with quantum, and successful tampering is contained to that chain.

Transaction Censorship

Attack Scenario

  • Malicious validators refuse to process certain transactions
  • Target specific users or applications

Defense

Monitoring for transaction, submit to different active validator.

Censorship Cost

  • Assume any validator may attempt to censor
  • Detection: Applications notice unresponsive validators
  • Penalty: Validator loses business
  • Alternative: Applications switch to different validators

Result: Censorship requires silence from all validators. Each validator is paid to validate any honest transaction. Once a transaction is validated by one validator, omission is detectable.

Cryptographic Security

All hash functions and keys are upgradeable for new chains. Keys only affect signature blocks, which are modular. Validation criteria and protocol rules are unchanged.

Quantum Transition Plan

  • Upgrade via new chain releases with desired encryption standards
  • Audit trails and per-transaction proofs have backwards and forwards compatibility
  • Users and applications migrate to desired chains
  • Old chains may continue to run if quantum-resistant keys are too expensive for purpose (e.g. micropayments)

Hash Function Security

SHA-256 Security Level

  • Collision resistance: 2^128 operations (128-bit security)
  • Preimage resistance: 2^256 operations (256-bit security)
  • Current capability: <2^80 operations feasible
  • Margin of safety: >10^14 times current capability

Attack Vectors

  • No known practical attacks against SHA-256
  • Quantum computers: Grover's algorithm reduces to 2^128 (still secure)
  • Collision attacks: Requires more energy than exists in solar system

Digital Signature Security

Ed25519 Security Level

  • Discrete logarithm security: ~128-bit
  • No known classical attacks
  • Quantum attacks: Shor's algorithm breaks Ed25519
  • Timeline: 10-20 years until practical quantum computers

Compliance & Regulations

Data Privacy

GDPR Compliance

  • Right to erasure: Off-chain data, application-level responsibility
  • Data minimization: Only hashes on-chain
  • Privacy by design: User chooses optional encryption

CCPA Compliance

  • Consumer rights respected
  • Data access controls: User chooses selective revelation
  • Deletion procedures for off-chain data, application-level responsibility

Financial Regulations

AML/KYC

  • Application-level responsibility
  • Validator level: No KYC required
  • Exchange integrations: Full KYC support

Securities Laws

  • GEEQ token: Utility token
  • Validator participation: Service provision
  • Governance: Decentralized voting

Next Steps

5 min read

Updated 2 months ago