proofnest 0.2.0__py3-none-any.whl → 0.2.1__py3-none-any.whl

.planning/research/SUMMARY.md

@@ -1,385 +0,0 @@
-# PROOFNEST Research Summary
-
-**Project:** PROOFNEST - AI Decisions You Can Prove
-**Domain:** AI trust infrastructure with cryptographic verification
-**Researched:** 2026-02-03
-**Confidence:** HIGH
-
-## Executive Summary
-
-PROOFNEST is building cryptographic trust infrastructure for AI decisions in a post-Moltbook world. The January 2026 Moltbook breach (1.5M API keys exposed through "vibe coding" security failures) created a market for trust-first alternatives. PROOFNEST's core technical foundation is solid: Dilithium3 post-quantum signatures, Bitcoin anchoring via OpenTimestamps, and hybrid cryptography are production-ready. The gaps are in enterprise integration patterns (OAuth2 M2M, webhooks, multi-tenancy) and real-time social features (WebSockets, event feeds) needed to compete with Moltbook while avoiding their failures.
-
-The recommended approach is phased evolution aligned with three milestones: (1) Production-hardened API with enterprise security, (2) Enterprise SDK and compliance dashboard for first customer, (3) AI-Human Hub with real-time collaboration. This sequencing allows proving trust capabilities before scaling social features, while the EU AI Act deadline (August 2026) creates urgency for compliance-focused features.
-
-Key risks: repeating Moltbook's security failures (mitigate: GPT-5.2 audit complete, RLS mandatory), missing EU AI Act compliance (mitigate: Article 12 audit trails are core product feature), and pilot ROI ambiguity (mitigate: quantifiable value propositions upfront). The competitive advantage is "proof-coded not vibe-coded" - security and compliance as product differentiators, not afterthoughts.
-
-## Key Findings
-
-### Recommended Stack
-
-PROOFNEST's cryptographic stack (Dilithium3, Ed25519, hybrid signatures, OpenTimestamps) is FIPS 204 compliant and production-ready per GPT-5.2 audit. The gaps are operational infrastructure, not crypto primitives.
-
-**Core technologies to add:**
-- **Gunicorn + Uvicorn**: Production WSGI/ASGI server — FastAPI deployment standard
-- **Redis**: Rate limiting, pub/sub, caching — distributed state across API instances
-- **OpenTelemetry**: Distributed tracing and metrics — observability for production incidents
-- **Kong/Traefik**: API Gateway for multi-tenancy and rate limiting — enterprise isolation
-- **authlib + python-jose**: OAuth2 Client Credentials flow — AI agent authentication standard
-- **WebSockets + Redis Pub/Sub**: Real-time event streaming — Hub social features
-- **PostgreSQL**: Multi-tenant database with RLS — production persistence (migrate from SQLite)
-
-**Critical additions by milestone:**
-- M1 (stellanium.io): Rate limiting, observability, health checks
-- M2 (first customer): OAuth2 M2M auth, webhook system, TypeScript SDK
-- M3 (AI-Human Hub): WebSockets, real-time feeds, Merkle batch verification
-
-**Confidence:** HIGH — all recommendations are industry-standard patterns with proven tooling.
-
-### Expected Features
-
-Research identified three feature tiers: table stakes (users expect), differentiators (competitive advantage), and anti-features (explicitly avoid).
-
-**Must have (table stakes):**
-- Agent registration with DID-based identity (not Moltbook's unauthenticated POST)
-- Cryptographic decision signing (every AI action has provable signature)
-- Bitcoin anchoring for tamper-proof timestamps
-- Encrypted messaging (Moltbook leaked DMs in plaintext)
-- Rate-limited registration (Moltbook: 500K fake agents from OpenClaw)
-- Basic posting, threading, voting (minimum social function)
-
-**Should have (competitive differentiators):**
-- Verifiable Credentials for agent capabilities (W3C VC standard)
-- Proof-of-Decision API (cryptographic verification, not trust)
-- EU AI Act compliance dashboard (Article 12/13/14 requirements)
-- Human-in-the-loop controls (75% of enterprises require this per KPMG)
-- On-chain reputation (not gameable like Moltbook karma)
-- Agent-to-Agent trust protocol (cross-platform interoperability)
-- Data lineage tracking (link outputs to model version + source data)
-
-**Defer to v2+:**
-- Advanced multi-agent orchestration (complex, can iterate)
-- Cross-platform A2A protocol (requires ecosystem adoption)
-- Token economics (regulatory complexity)
-
-**Anti-features to explicitly avoid:**
-- Hardcoded API keys in client code (Moltbook root cause)
-- No Row Level Security on database (anyone could read/write Moltbook DB)
-- Plaintext secret storage (Moltbook stored OpenAI keys in clear)
-- No rate limiting (enabled 500K fake agents)
-- Single admin account (no accountability)
-- Karma without proof (easily gamed)
-- "Growth over security" mindset (ship fast, fix later)
-
-### Architecture Approach
-
-PROOFNEST has a clean dual-layer architecture: Python Core (FastAPI REST API, PROOF lifecycle, DID registry, SQLite) + Go Blockchain (HotStuff-2 BFT, Dilithium3, ~2s block time). The integration challenge is bridging these layers for enterprise and Hub use cases, not redesigning the foundation.
-
-**Major components to add:**
-1. **API Gateway (Kong/Traefik)** — Multi-tenant routing, rate limiting per tenant, OAuth2 validation, sits between clients and Python Core
-2. **AI Agent Auth System** — OAuth2 Client Credentials flow with agent DID linking, JWT tokens with expiration/scopes, delegation model for "on behalf of" actions
-3. **Real-time Hub Layer** — WebSocket endpoint with JWT auth, Redis Pub/Sub for cross-server broadcasting, Hub PROOF extensions (Post/Reply/Reaction types)
-4. **Batch Verification System** — Merkle tree batching for proof anchoring (1000 proofs → 1 blockchain TX), O(log n) verification instead of per-proof chain RPCs
-
-**Critical architectural decisions:**
-- All PROOF operations through Python Core (Go is storage layer, not entry point)
-- Stateless WebSocket servers (Redis for shared state, horizontal scaling)
-- Async batch verification (synchronous chain calls create 50ms+ latency bottleneck)
-- PostgreSQL with tenant isolation (RLS mandatory on all tables)
-
-**Confidence:** MEDIUM-HIGH — patterns are proven, but Hub-specific integration needs tuning during implementation.
-
-### Critical Pitfalls
-
-Research identified pitfalls from Moltbook breach, EU AI Act requirements, and enterprise adoption barriers.
-
-1. **"Vibe Coding" Security Failures (BLOCKS LAUNCH)** — 45% of AI-generated code introduces vulnerabilities (Veracode 2025). Moltbook's breach was caused by hardcoded keys, missing RLS, unauthenticated writes. Prevention: GPT-5.2 security audit complete (done), RLS mandatory from day 1, never expose credentials client-side, treat every AI-generated line as untrusted until reviewed.
-
-2. **EU AI Act Non-Compliance (BLOCKS EU LAUNCH)** — Effective August 2, 2026. Article 12 requires automatic, tamper-resistant event logging. Article 14 requires human oversight. Penalties: EUR 35M or 7% of global turnover. Prevention: Immutable audit trails (cryptographic, append-only) are core product feature, human oversight interface as core feature, incident reporting workflow built-in. This is opportunity, not burden: PROOFNEST can be THE compliance solution.
-
-3. **API Key Management Catastrophe (BLOCKS LAUNCH)** — 95% of API attacks come from authenticated sessions (Palo Alto 2025). Moltbook leaked 1.5M keys, McHire exposed 64M records with "123456" password. Prevention: HSM for key storage, automatic key rotation, scoped revocable tokens (OAuth2, not long-lived keys), keys never in logs/frontend, rate limiting per key.
-
-4. **Scalability Afterthought (BLOCKS SCALE)** — Cryptographic audit systems hit performance walls. Real-world benchmark: 12K TPS achievable with batch processing, 87% cost reduction vs per-transaction anchoring. Prevention: Asynchronous batch audit generation, Merkle tree structures for efficient verification, hierarchical storage (hot/warm/cold), performance testing under realistic load BEFORE launch.
-
-5. **ROI Ambiguity (DEGRADES ADOPTION)** — 95% of enterprise AI pilots fail to deliver measurable P&L impact (MIT 2025), 72% of executives delay AI investments due to unclear ROI (IBM 2025). Prevention: Define ROI metric before building (audit hours saved, compliance cost avoided), pilot → production criteria defined upfront, quantifiable value propositions.
-
-## Implications for Roadmap
-
-Based on research, suggested phase structure aligned with three milestones:
-
-### Phase 1: Production Hardening (M1: stellanium.io operational)
-**Rationale:** Current Python Core works but lacks production-grade operational patterns. Must address observability, rate limiting, and health checks before any public deployment. Moltbook's breach proves market has zero tolerance for security failures.
-
-**Delivers:**
-- Production-ready API deployment (Gunicorn + Uvicorn)
-- Rate limiting with Redis (prevent DoS, enforce fair usage)
-- OpenTelemetry observability (metrics, traces, logs)
-- Health check endpoints (/health, /ready, /live for K8s)
-- PostgreSQL migration (production persistence with connection pooling)
-
-**Addresses (from FEATURES.md):**
-- Rate-limited registration (prevent fake agent floods like Moltbook)
-- Production security controls (anti-feature: avoid growth over security)
-
-**Avoids (from PITFALLS.md):**
-- CP-1: Vibe coding security (operational hardening catches deployment issues)
-- CP-3: API key management (foundational controls in place)
-
-**Research Flag:** SKIP RESEARCH — standard patterns, well-documented
-
----
-
-### Phase 2: Enterprise Security (M1 continued)
-**Rationale:** Enterprises need OAuth2, not API keys. 60% of enterprises cite lack of proper auth as blocker. Must implement before first customer conversations.
-
-**Delivers:**
-- OAuth2 Client Credentials flow for AI agents
-- Agent identity lifecycle (registration, DID linking, revocation)
-- API Gateway deployment (Kong/Traefik)
-- Multi-tenant routing with X-Tenant-ID
-- JWT token generation/validation
-
-**Uses (from STACK.md):**
-- authlib + python-jose for OAuth2
-- Kong/Traefik for gateway patterns
-- Redis for distributed rate limits
-
-**Implements (from ARCHITECTURE.md):**
-- AI Agent Authentication System component
-- Delegation model for "on behalf of" actions
-
-**Avoids (from PITFALLS.md):**
-- CP-3: API key management (OAuth2 tokens with expiration/scopes)
-- MP-2: Governance-adoption gap (auth controls built-in)
-
-**Research Flag:** LIGHT RESEARCH — OAuth2 M2M is emerging standard, may need agent-specific patterns research
-
----
-
-### Phase 3: Enterprise Integration (M2: first customer)
-**Rationale:** First enterprise customer needs SDK, webhooks, and SLA monitoring. Event-driven integration is table stakes for enterprise systems.
-
-**Delivers:**
-- TypeScript/Node SDK (official, typed, published to npm)
-- Python SDK (extract from core, publish to PyPI)
-- Webhook callback system (proof.created, proof.validated, proof.anchored events)
-- HMAC signature verification for webhook security
-- SLA monitoring (API latency p99, consensus time, uptime tracking)
-
-**Addresses (from FEATURES.md):**
-- API access as table stakes
-- Enterprise integration (not anti-feature: API-only strategy)
-
-**Implements (from ARCHITECTURE.md):**
-- Webhook event system
-- SDK retry logic with exponential backoff
-
-**Avoids (from PITFALLS.md):**
-- MP-5: Legacy integration nightmare (multiple integration patterns)
-- MP-3: ROI ambiguity (clear integration story enables pilots)
-
-**Research Flag:** MODERATE RESEARCH — Webhook patterns and SDK design need enterprise API research
-
----
-
-### Phase 4: EU AI Act Compliance (M2 continued)
-**Rationale:** August 2026 deadline creates hard boundary. Compliance dashboard is competitive differentiator AND regulatory requirement. Build it as product feature, not checkbox.
-
-**Delivers:**
-- Compliance dashboard (real-time EU AI Act Article 12/13/14 status)
-- Audit trail export (tamper-evident logs for regulators, CSV/JSON formats)
-- Human-in-the-loop controls (approval workflows with risk-based tiers)
-- Incident reporting workflow (Article 73: 2-15 day reporting)
-- AI decision explainability API (regulatory-valid proofs, not theater)
-
-**Addresses (from FEATURES.md):**
-- Compliance dashboard as differentiator
-- Human oversight controls (75% enterprise requirement)
-- Decision explainability (EU AI Act Article 13)
-
-**Avoids (from PITFALLS.md):**
-- CP-2: EU AI Act non-compliance (all Articles addressed)
-- MP-1: Explainability theater (machine-verifiable proofs)
-- MP-4: Human oversight that doesn't scale (risk-based tiers, workflows)
-
-**Research Flag:** MODERATE RESEARCH — EU AI Act specific requirements need regulatory research
-
----
-
-### Phase 5: Hub Foundation (M3: proofnest.io AI-Human Hub)
-**Rationale:** Hub needs real-time capabilities that REST API can't provide. WebSocket + event architecture enables live collaboration without polling.
-
-**Delivers:**
-- WebSocket endpoint with JWT validation
-- Redis Pub/Sub for cross-server broadcasting
-- Hub PROOF extensions (Post, Reply, Reaction types)
-- Thread linking (previous_proof chains)
-- Visibility controls (public, tenant, private)
-- Real-time feed delivery
-
-**Uses (from STACK.md):**
-- WebSockets library
-- Redis Pub/Sub
-- FastAPI WebSocket support
-
-**Implements (from ARCHITECTURE.md):**
-- Real-time Hub Layer component
-- Stateless WebSocket servers with Redis shared state
-
-**Avoids (from PITFALLS.md):**
-- Architectural anti-pattern: stateful WS servers (Redis for state)
-
-**Research Flag:** LIGHT RESEARCH — WebSocket patterns well-documented, Hub-specific UX may need research
-
----
-
-### Phase 6: Social Features (M3 continued)
-**Rationale:** Once real-time infrastructure exists, build social layer on top. These are table stakes from competitive research.
-
-**Delivers:**
-- User profiles (bio, avatar, credentials display)
-- Follow/social graph (subscribe to agents/humans)
-- Voting/reactions (upvotes, emoji reactions)
-- Direct messaging (E2E encrypted, NOT plaintext like Moltbook)
-- Notifications (real-time alerts via WebSocket)
-- Search (full-text across posts, profiles)
-
-**Addresses (from FEATURES.md):**
-- All table stakes social features
-- Encrypted DMs (anti-feature: avoid Moltbook's plaintext leak)
-
-**Avoids (from PITFALLS.md):**
-- Moltbook's DM leak (E2E encryption mandatory)
-- Vanity metrics (honest metrics: verified unique entities only)
-
-**Research Flag:** SKIP RESEARCH — standard social features, established patterns
-
----
-
-### Phase 7: Trust & Reputation (M3 continued)
-**Rationale:** PROOFNEST's differentiator vs Moltbook is cryptographically-backed trust. Reputation system must be provable, not gameable.
-
-**Delivers:**
-- Trust score API (reputation based on verified proof history)
-- Attestation system (multi-party validation, 3+ validators)
-- Proof badges (visual verification of agent authenticity)
-- Decision timeline (Git-like history of proven decisions)
-- Trust verification endpoints (verify AI output was proven, full chain to Bitcoin)
-
-**Addresses (from FEATURES.md):**
-- Reputation chain as differentiator
-- Attestation/verification system (Shipyard model)
-- Trust score (not gameable like Moltbook karma)
-
-**Implements (from ARCHITECTURE.md):**
-- Trust Verification API component
-
-**Avoids (from PITFALLS.md):**
-- Anti-feature: karma without proof (on-chain backing required)
-
-**Research Flag:** MODERATE RESEARCH — Reputation algorithms and sybil resistance need research
-
----
-
-### Phase 8: Performance & Scale (M3 final)
-**Rationale:** As proof volume grows, per-proof verification becomes bottleneck. Batch verification with Merkle trees enables 12K TPS (vs hundreds without batching).
-
-**Delivers:**
-- Merkle tree batch verification
-- Proof mempool (collect proofs before batching)
-- Batch submission to Go Blockchain (1 TX for 1000 proofs)
-- Merkle proof storage for O(log n) verification
-- Database schema extensions (batch_id, merkle_index, merkle_proof)
-- Connection pooling and query optimization
-
-**Uses (from STACK.md):**
-- Custom Merkle tree implementation
-- PostgreSQL performance tuning
-
-**Implements (from ARCHITECTURE.md):**
-- Batch Verification System component
-- Async proof anchoring
-
-**Avoids (from PITFALLS.md):**
-- CP-4: Scalability afterthought (architecture handles high volume)
-- Architectural anti-pattern: synchronous chain verification
-
-**Research Flag:** LIGHT RESEARCH — Merkle trees are standard, batching logic may need research
-
----
-
-### Phase Ordering Rationale
-
-**Security first, features second:** Phases 1-2 establish production security before any customer-facing features. This directly addresses Moltbook's failure mode (vibe-coded features without security foundation).
-
-**Enterprise before social:** Phases 3-4 enable first enterprise customer (M2) with SDK, webhooks, and compliance. This proves the trust value proposition with quantifiable ROI before investing in social scale (M3).
-
-**Real-time infrastructure before social features:** Phase 5 builds WebSocket architecture that Phases 6-7 consume. Avoids retrofitting real-time onto REST API.
-
-**Scale testing last, not scrambling:** Phase 8 addresses performance proactively based on load testing, not reactively when system is already slow. 87% cost reduction from batch verification justifies upfront investment.
-
-**EU AI Act as competitive advantage:** Phase 4 treats compliance as product feature (differentiator), not checkbox. August 2026 deadline creates urgency, but compliance-focused enterprises are high-value customers today.
-
-### Research Flags
-
-**Phases needing deeper research during planning:**
-- **Phase 2:** OAuth2 for AI agents is emerging standard (2026), may need agent-specific patterns research
-- **Phase 3:** Webhook security patterns and enterprise SDK design conventions
-- **Phase 4:** EU AI Act Article 12/13/14 specific implementation requirements
-- **Phase 7:** Reputation algorithms and sybil resistance mechanisms
-- **Phase 8:** Merkle tree batching logic and proof mempool optimization
-
-**Phases with standard patterns (skip research-phase):**
-- **Phase 1:** Production deployment patterns are well-established
-- **Phase 5:** WebSocket + Redis Pub/Sub is proven pattern
-- **Phase 6:** Social features are table stakes, many references
-
-## Confidence Assessment
-
-| Area | Confidence | Notes |
-|------|------------|-------|
-| Stack | HIGH | FIPS 204 compliance verified, production patterns well-documented |
-| Features | HIGH | Moltbook breach + W3C standards + enterprise surveys provide clear requirements |
-| Architecture | MEDIUM-HIGH | Dual-layer architecture is sound, Hub-specific integration needs validation during implementation |
-| Pitfalls | HIGH | Moltbook breach is thoroughly documented, EU AI Act requirements are clear, enterprise barriers quantified with surveys |
-
-**Overall confidence:** HIGH
-
-Research is based on multiple authoritative sources: Wiz Security's Moltbook breach analysis, official EU AI Act text, W3C DID/VC standards, NIST cryptography standards, and quantitative enterprise surveys (McKinsey, IBM, PwC, KPMG). Cryptographic foundation was audited by GPT-5.2.
-
-### Gaps to Address
-
-**Enterprise integration specifics:** SDK design conventions, webhook retry logic, and rate limiting tiers depend on actual customer requirements. Phase 3 planning should validate integration patterns with target customers before implementation.
-
-**Hub UX patterns:** Real-time feed algorithms, notification priority, and thread depth limits need UX research during Phase 5-6 planning. Research focused on technical feasibility, not user experience design.
-
-**Reputation algorithm:** Phase 7 needs research on sybil resistance and reputation calculation. Multiple approaches exist (proof-of-stake, proof-of-humanity, attestation-based), choice depends on economic model.
-
-**Regulatory interpretation:** EU AI Act Articles are clear on requirements, but interpretation for specific use cases may require legal consultation during Phase 4 planning.
-
-**Performance benchmarks:** Phase 8 assumes batch verification achieves 12K TPS based on research, but actual performance depends on Go Blockchain configuration and network topology. Load testing required before optimization.
-
-## Sources
-
-### Primary (HIGH confidence)
-- **NIST FIPS 204 (ML-DSA)** — Post-quantum signature standard, Dilithium3 compliance verification
-- **Wiz Security: Moltbook Breach Analysis** — Root cause analysis, 1.5M exposed keys, security recommendations
-- **EU AI Act Official Text (Articles 12/13/14/73)** — Regulatory requirements, audit logging, human oversight, incident reporting
-- **W3C DID Core + Verifiable Credentials** — Identity and credential standards for AI agents
-- **Go 1.24 Cryptography Roadmap** — ML-KEM support, hybrid TLS, post-quantum readiness
-
-### Secondary (MEDIUM confidence)
-- **IBM/KPMG Enterprise AI Surveys (2025-2026)** — Adoption barriers, ROI challenges, governance requirements
-- **FastAPI Production Deployment Guides** — Gunicorn/Uvicorn patterns, rate limiting, observability
-- **Kong/Traefik Multi-Tenancy Documentation** — API Gateway patterns, OAuth2 integration
-- **Microsoft/AWS AI Agent Auth Guides** — OAuth2 Client Credentials for M2M, agent identity patterns
-- **Veracode: AI-Generated Code Security (2025)** — 45% vulnerability rate, vibe coding risks
-
-### Tertiary (LOW confidence - validate during implementation)
-- **Merkle tree performance benchmarks** — Various sources claim 12K TPS, need validation for PROOFNEST's specific use case
-- **Reputation algorithm research papers** — Multiple approaches, need selection based on economic model
-- **Hub UX patterns** — Social platform best practices, need adaptation for AI-Human context
-
----
-*Research completed: 2026-02-03*
-*Ready for roadmap: yes*
-*Next step: Define detailed requirements and create phase-by-phase roadmap*

AUDIT_GPT4o_2026-02-03.md

@@ -1,65 +0,0 @@
-# PROOFNEST CORE - GPT-4o Turvaaudit
-
-**Kuupäev:** 2026-02-03
-**Mudel:** GPT-4o (OpenAI API)
-**Kontekst:** 4170 rida Python SDK
-
----
-
-## 1. Dilithium3 + SHAKE256 Valik
-
-**HINNANG: ✅ SOBIV**
-
-- **Dilithium3**: NISTi poolt soovitatud post-kvantum digitaalallkirja skeem, pakub tugevat turvalisust kvantarvutite vastu. Hea valik.
-- **SHAKE256**: Turvaline ja paindlik räsifunktsioon, NISTi poolt heaks kiidetud.
-
-**Soovitus:** Veendu, et implementatsioon vastab standarditele.
-
----
-
-## 2. HotStuff-2 67% Quorum Rünnakuvektorid
-
-| Rünnak | Risk | Leevendus |
-|--------|------|-----------|
-| **Long-range attacks** | 🟡 KESKMINE | Regulaarne võtmete uuendamine, tugev võtmete haldamine |
-| **Nothing-at-stake** | 🟢 MADAL | Vähem probleemne BFT süsteemides, stiimulite mehhanismid vajalikud |
-| **Collusion** | 🔴 KÕRGE | <34% osalejate kokkumäng võib kompromiteerida. Vaja mitmekesisust ja hajutatust |
-| **Eclipse attacks** | 🟡 KESKMINE | Mitmekesised ühendused, tugev võrguarhitektuur |
-
----
-
-## 3. DID Formaat `did:pn:{type}:{pubkey_hash}`
-
-**Probleemid:**
-1. Kui hash-funktsioon on nõrk → turvaprobleemid
-2. Kui tüübid pole selgelt määratletud → segadus
-
-**Soovitus:** Kasuta tugevat hash-funktsiooni (SHAKE256 on OK).
-
----
-
-## 4. Kriitilised Puudused
-
-1. **Konsensuse mehhanismi keerukus** - HotStuff-2 korrektne implementeerimine on kriitiline
-2. **Võtmete haldamine** - Post-kvantum võtmete suurus ja haldamine keeruline
-3. **Ankurdamise sõltuvus** - Ainult Bitcoin on riskantne
-
----
-
-## 5. Soovitused Parandamiseks
-
-| # | Soovitus | Prioriteet |
-|---|----------|------------|
-| 1 | Uuri alternatiivseid konsensuse mehhanisme | MEDIUM |
-| 2 | Mitmekesista ankurdamist (mitu plokiahelat) | HIGH |
-| 3 | Rakenda võrgutaseme kaitse (eclipse attacks) | HIGH |
-| 4 | Korralda regulaarsed turvaauditid | ONGOING |
-
----
-
-## Tegevuskava Vastuseks
-
-- [ ] Lisa key rotation mehhanism
-- [ ] Lisa mitmekordne ankurdamine (Bitcoin + Ethereum + custom chain)
-- [ ] Paranda P2P võrgu kaitse eclipse rünnakute vastu
-- [ ] Dokumenteeri konsensuse implementatsioon detailselt

AUDIT_GPT52_2026-02-03.md

@@ -1,137 +0,0 @@
-# PROOFNEST CORE - GPT-5.2 Turvaaudit
-
-**Kuupäev:** 2026-02-03
-**Mudel:** GPT-5.2 (OpenAI)
-**Staatus:** KRIITILINE - palju parandamist vaja
-
----
-
-## 1. Dilithium3 + SHAKE256 (Post-Quantum)
-
-**HINNANG: 🟡 OK, aga probleemid:**
-
-- "50+ aastat quantum-proof" on lubadus mida ei saa anda
-- Dilithium3 = NIST Level 3 (~AES-192) - miks mitte Dilithium5 suurema marginaaliga?
-- SHAKE256 on OK, AGA vaja domain separation tags igal pool
-- Suurim risk on ENGINEERING, mitte matemaatika:
-  - Dilithium allkirjad on SUURED → DoS vektor
-  - Side-channel ja fault attacks on päris
-
-**SOOVITUS:**
-- Kasuta HYBRID allkirju (ML-DSA + Ed25519) üleminekuperioodil
-- Kaalu ML-DSA-65 vs -87 kompromisse
-- Lisa algorithm agility protokolli disaini
-
----
-
-## 2. HotStuff-2 BFT 67% Quorum
-
-**RÜNNAKUVEKTORID (hästi rahastatud vastase vastu):**
-
-| # | Rünnak | Tõsidus |
-|---|--------|---------|
-| 1 | **Validator capture / cartel** | 🔴 KRIITILINE - osta/kompromiteeri 1/3 validaatoreid |
-| 2 | **Network-layer** | 🔴 Eclipse attacks, BGP hijacks, DDoS leaderi vastu |
-| 3 | **Time manipulation** | 🟡 Skewed clocks + delay → inconsistent ordering |
-| 4 | **State bloat** | 🟡 PQ allkirjad = odav luua, kallis verifitseerida |
-| 5 | **Long-range attacks** | 🔴 Kui vanad võtmed lekkivad |
-| 6 | **Client deception** | 🔴 Light clients on nõrk koht |
-
-**SOOVITUS:**
-- Defineeri validator admission ja stake mudel
-- Anti-DoS: signature batching, rate limits, fee model
-- Light-client story checkpointing'uga
-
----
-
-## 3. DID System
-
-**PROBLEEMID:**
-
-- **Key rotation:** DID = pubkey hash → uus võti = UUS identiteet (!)
-- **Recovery:** Võti kaotsi = identiteet kaotsi (julmalt aus)
-- **Sybil:** ZERO Sybil resistance - igaüks saab luua lõpmata DID-e
-- **Truncation:** 40 hex = 160 bits - miks mitte 256?
-
-**SOOVITUS:**
-- Otsusta: kas DID on stabiilne identifier või key fingerprint?
-- Kui stabiilne: vaja DID registry + document update rules + recovery
-- Kui lihtne: kutsu seda "key ID", mitte DID
-
----
-
-## 4. Puudu Productioni Jaoks
-
-| # | Puuduv | Prioriteet |
-|---|--------|------------|
-| 1 | **Formal spec** - "4170 rida Python" pole spec | 🔴 |
-| 2 | **Canonical encoding** - CBOR/Protobuf deterministic | 🔴 |
-| 3 | **Threat model** - kes on adversary, mis on trust anchor | 🔴 |
-| 4 | **Key management** - HSM tugi, constant-time crypto | 🟡 |
-| 5 | **Data availability** - kus evidence elab? | 🟡 |
-| 6 | **Light client** - verification path | 🔴 |
-| 7 | **Governance** - kuidas upgrade'id toimuvad | 🟡 |
-
----
-
-## 5. Võrdlus Teiste Projektidega
-
-| Projekt | Sarnasus | Erinevus |
-|---------|----------|----------|
-| **W3C VCs/DIDs** | Data model | Nemad ei anna konsensust |
-| **Ceramic** | Anchored history | Nemad fokusseerivad dokument streams |
-| **EAS** | Attestations | Nemad kasutavad Ethereumi turvalisust |
-
-**Brutal bottom line:**
-- Kui eesmärk on "globally verifiable attestations" → EAS/VCs lahendavad 80%
-- Kui eesmärk on "existence proofs" → OpenTimestamps üksi on raske üle lüüa
-- UUS BFT layer on mõistlik AINULT kui vaja fast finality + richer semantics
-
----
-
-## Küsimused Millele Peab Vastama
-
-1. Mida "consensus" täpselt attesteerib? (ordering, validity, uniqueness, non-equivocation, time bounds?)
-2. Kes on validators ja kuidas valitakse?
-3. Mis on light-client verification path?
-4. Mis on identity recovery story?
-5. Mis on data availability model "evidence" jaoks?
-6. Mis on täpsed cryptographic transcripts?
-
----
-
-## Tegevuskava
-
-- [x] Lisa hybrid signatures (ML-DSA + Ed25519) ✅ **DONE 2026-02-03**
-- [ ] Defineeri validator admission model
-- [ ] Lisa formal spec (CBOR deterministic encoding)
-- [ ] Lisa light-client verification
-- [x] Lisa DID Document + registry key rotation jaoks ✅ **DONE 2026-02-03**
-- [ ] Lisa Sybil resistance (stake/bonding)
-- [ ] Dokumenteeri threat model
-
-## Implementeeritud Lahendused
-
-### 1. Hybrid Signatures (proof.py)
-```python
-# Uus enum väärtus:
-SignatureAlgorithm.HYBRID_ML_DSA_ED25519
-
-# Kasutamine:
-identity, sk = Identity.generate("agent", SignatureAlgorithm.HYBRID_ML_DSA_ED25519)
-proof = Proof.create(ProofType.CLAIM, "...", identity, sk)
-# MÕLEMAD allkirjad peavad kehtima (AND, mitte OR)
-```
-
-### 2. DID Registry (did_registry.py)
-```python
-# Key rotation:
-doc = DIDDocument.create(did, public_key, recovery_public_key=recovery_pk)
-doc.rotate_key(old_key_id, new_public_key, key_type)
-
-# Registry:
-registry = DIDRegistry()
-registry.register(doc)
-registry.update(doc)
-resolved = registry.resolve(did)
-```