DECK-0001: axis lines catchment area for hyperjump entry#9
Open
DECK-0001: axis lines catchment area for hyperjump entry#9
Conversation
added 17 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
- 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)
- 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
Each hyperjump coordinate emits three axis-aligned lines (X, Y, Z). An avatar may enter the hyperjump network by hopping onto any point on any of these lines, paying only the two non-free axis distances instead of all three. Changes: - Add 'Hyperjump axis line' term definition - Add normative 'Hyperjump axis lines' section defining X/Y/Z lines through each hyperjump coordinate C - Update behavioral constraints: prev_coord_hex may be C or any axis-line point of a valid hyperjump - Update verification step 4 to validate axis-line entry - Update non-normative notes: line entry is sufficient to issue a hyperjump; exit is always from destination C - Expand examples to show axis-line entry (2b), hyperjump from line point (3), and exit hop from C (4) Traversal improvement (940k HJs, 85-bit axes): - K threshold to reach C directly: ~78.4 - K threshold to reach nearest line: ~74.3 - Improvement: ~4.1 bits, ~294x less work at threshold
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
Each hyperjump coordinate emits three axis-aligned lines through its position (X-line, Y-line, Z-line). An avatar may enter the hyperjump network by hopping onto any point on any of these lines, paying only the two non-free axis distances instead of all three.
Protocol Changes
New term: Hyperjump axis line — one of three axis-aligned lines through a hyperjump coordinate. Membership is exact.
New normative section: Hyperjump axis lines defines the X, Y, and Z lines through each C, specifies exact membership, and establishes axis lines as the catchment area of a hyperjump.
Updated behavioral constraints: prev_coord_hex may now be (a) a valid hyperjump coordinate, or (b) any point on one of the three axis lines of a valid hyperjump.
Updated verification: Step 4 checks c against both options above.
Updated non-normative notes: Landing on an axis line is sufficient to issue a hyperjump — no additional hop to C required. Exit is always from destination C via standard hop.
Expanded examples: axis-line entry hop (2b), hyperjump from line point (3), exit hop from C (4).
Traversal Improvement
With ~940,000 hyperjumps and 85-bit axes: