## 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 - [Proof of Honesty](/content/docs/core-concepts/proof-of-honesty/index.html) — Understanding the consensus mechanism - [Validator Guide](/content/docs/validators/running-a-node/index.html) — Running a secure validator - [Cryptographic Primitives](/content/docs/technical/cryptographic-primitives/index.html) — Hash functions and digital signatures 5 min read Updated 2 months ago