Open
Conversation
added 2 commits
March 16, 2026 18:36
- Zero-knowledge proof system for territorial claims - Asymmetric verification: O(N) prover, O(log² N) verifier - Root R never revealed under any circumstance - STARK proof IS the commitment (no separate field) - Goldilocks field + Poseidon2 hash (STARK-optimized) - HTTPS hosting with proof_hash integrity - Nostr kind 33333 for claim events
arkin0x
changed the title
added 13 commits
March 16, 2026 20:33
- New Section 3: How STARK Proofs Work (beginner-friendly) - Explain circuit concept, Poseidon2 vs SHA256, inside/outside circuit - Add concrete Height 4 domain example with step-by-step trace - Add temporal Cantor tree for block duration (time proof) - Work now scales with both territory size AND duration - Renumber all sections for clarity
Critical fixes: - Add pubkey to public inputs (prevents proof theft) - Fix spatial enumeration: cubic region with bit-interleaving - Add d tag for NIP-33 replaceable events - Define temporal tree padding (repeat last value) - Specify Poseidon2 parameters (t=4, R_F=8, R_P=22) - Add domain identifier serialization (16 hex chars) - Define proof binary format - Add Domain Lifecycle section (renewal, expiration, revocation) Significant updates: - Verification now checks pubkey binding - Concrete example updated for cubic volume (Height 2 = 64 leaves)
All critical and significant issues addressed: - Pubkey binding for security - Cubic volume enumeration (bit-interleaving) - d tag for NIP-33 replaceable events - Poseidon2 parameters specified - Domain lifecycle (renewal, expiration, revocation) - Conflict resolution priority rules - Security parameters mandated (min 100 bits) - Bitcoin oracle sources specified - Protocol limits (max height 30, max duration 1M blocks) - Privacy considerations added - Test vectors updated (Height 2 example) - Cantor pairing fixed (modulo p) - Status label consistent (Draft) Ready for PR #7 review on GitHub.
Key changes: - 3-axis Cantor pairing (X, Y, Z roots first) - Commitment output instead of revealing R - Updated domain event structure - Revised verification protocol - Added domain lifecycle (renewal, expiration, revocation) - Protocol limits and privacy considerations - Test vectors updated Aligning with CYBERSPACE v2 specification's 3-axis structure and confidentiality requirements.
1. Structure: 3-Axis (not volumetric tree) 2. Mathematics: Integer Cantor pairing on raw coordinates 3. Privacy: R as private witness for commitment 4. Inputs: Geometric only (base/height)
Major changes: - Add three-layer capability model (Mathematical, Protocol, Social) - Add action control / domain policy for protocol-level feature control - Add content sovereignty mechanics (owner content only in domains) - Add CP-ABE integration for role-based access (kind 33334) - Document privacy hierarchy problem (domain owner omniscience) - Remove temporal axis / expiration (knowledge is irrevocable) - Clarify discovery vs. recognition distinction The spec now comprehensively covers: - What domains are and how they work - All three enforcement layers - Protocol-level rights earned by work - Mathematical capabilities and limitations - Privacy implications for users
- Fix d tag: 64 hex chars (not 16), matches Public_Commitment - Add subject tag for human-readable domain name - Set content field to '<optional: domain description>' - Clarify h tag purpose (indexing/filtering) - Explain prefix consistency check in verification
- h tag is optional for indexing optimization - Only validate h if present - Clearer step 3 explanation in verification
- Remove spawn and scan (not yet specified) - Add internal-shard: permission to publish shards referencing domain - Add external-shard: permission to publish shards without reference - Define a tag format for domain reference: ["a", "33333:<pubkey>:<domain_id>"] - Update content sovereignty section to reference shard actions - Add concrete examples of shard filtering
- Remove content_filter field (replaced by shard actions) - Remove spawn_list check from policy verification - Simplify action enforcement (pubkey_list noted as future) - Update policy validation to be generic
Initial draft specifying: - Kind 333 derezz event with Cantor proof for spatial proximity - Temporal ordering rules (timestamp > previous + 1 second) - Domain owner advantage (knows R = instant derezz) - Kind 334 spawn event for respawning - Domain policy derezz: allow/deny for safe zones - Post-derezz state: victim can only spawn
- Add section 5.3: Domain Owner Exemption - Owner can bypass all policy restrictions in their domain - Rationale: work to compute R grants absolute authority - Update enforcement logic to check owner first - Renumber subsequent sections (5.4→5.5, 5.5→5.6)
arkin0x
changed the title
- Section 12.1: Updated prover requirements table - Section 14: Removed height limit, all heights valid - Market determines feasibility, not protocol rules - Added note about experimental testing for proof sizes at high claims (~60+) - Proof size limit marked as TBD pending testing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This DECK specifies a STARK-based proof system for territorial claims (domains) in Cyberspace.
Key Features
Protocol Design
Verification Asymmetry
Any smartphone can verify any claim in under 50 milliseconds.
Files Changed
decks/DECK-0002-stark-proofs.md— Complete production-ready specificationRelated