DECK-0001 v2: Hyperspace

PR_12_DESCRIPTION.md

@@ -0,0 +1,167 @@
+## Summary
+
+This revision extends DECK-0001 to solve the **bootstrap problem**: how can a newly spawned avatar reach the hyperjump network with consumer-feasible computation?
+
+The original design required avatars to hop to the **exact** hyperjump coordinate (a 3D point), which at typical distances (LCA h≈84) requires ~10¹¹ years of computation—categorically infeasible.
+
+This proposal introduces **sector-based entry planes**:
+
+Each hyperjump defines three 2D entry planes (one per axis), each **1 sector thick** (2³⁰ Gibsons). Avatars can enter by matching the **sector** (high 55 bits) on any one axis, reducing the entry LCA from h≈84 (full Gibson match) to **h≈33** (sector match).
+
+**Result:** With ~940K Bitcoin block HJs, entry cost drops from ~$50,000 cloud compute to **~$0.09**, enabling consumer access within **~15 minutes**.
+
+## Design Evolution: Shadow HJs Removed
+
+An earlier draft of this proposal included **shadow hyperjumps** (iterative SHA256 derivation, 60x density multiplier) as an optimization layer. After analysis, shadow HJs were **removed** from the design:
+
+- **Sector planes alone are sufficient** - they already achieve h≈33 entry LCA, which is consumer-feasible
+- Shadow HJs added unnecessary complexity without solving a remaining problem
+- The 61× optimization (h≈33 → h≈27, 15min → 14sec) is nice-to-have, not required
+- Keep the protocol minimal; shadows can be layered later if needed
+
+This design principle—**solve the bootstrap problem with the simplest mechanism**—aligns with Cyberspace's ethos.
+
+## Inter-HJ Travel: Commitment + Traversal Proof
+
+To prevent free teleportation from collapsing spatial locality, hyperjump travel now has **two components**:
+
+### 1. Access Commitment (Block Height Metric)
+
+Pays the "toll" to use the HJ network. Uses **Bitcoin block height difference**:
+
+```
+block_diff = |B_to - B_from|
+commitment_height = block_diff.bit_length()
+cost = 2^commitment_height SHA256 operations
+```
+
+**Why coordinate XOR failed:** Merkle roots are random 256-bit values. XOR of two random values has popcount ≈64, costing 2^64 ≈ 10^19 ops (5.8 million years).
+
+**Why block height works:** Block numbers are ordered and linear. With ~940K blocks:
+- Median hop: Δ=271K blocks → h=19 → 524K ops → **~5ms**
+- **100% of hops are h≤20** (maximum possible with current Bitcoin history)
+
+### 2. Traversal Proof (Incremental Cantor Tree)
+
+Proves the entity **actually traveled** the path, not just paid the toll.
+
+**Mechanism:** Incremental Cantor Tree with Temporal Leaf binding.
+
+**Leaves:** `[temporal_seed, B_from, B_from+1, ..., B_to]`
+- `temporal_seed = previous_event_id (as big-endian int) % 2^256`
+- Binds proof to entity's specific chain position
+
+**Tree construction:** Sequential Cantor pairing of all leaves:
+```python
+def cantor_pair(a: int, b: int) -> int:
+    """π(a, b) = (a+b)(a+b+1)/2 + b"""
+    s = a + b
+    return (s * (s + 1)) // 2 + b
+
+# Build tree from leaves
+root = leaves[0]
+for leaf in leaves[1:]:
+    root = cantor_pair(root, leaf)
+```
+
+**Properties:**
+- **Single proof for multi-block traversal** - One Cantor root aggregates entire path
+- **Non-reusable** - Temporal seed binds to chain position (replay = equivocation)
+- **No LCA barriers** - Path leaves, not region leaves. Cost is O(path_length)
+- **Mathematical** - Bijective Cantor pairing, no hash grinding
+- **Consumer-feasible** - ~1M blocks/day (1000× less than nation-state, linear advantage)
+
+**Publication:** Kind 3333 event with `A=hyperjump` tag:
+```json
+{
+  "kind": 3333,
+  "tags": [
+    ["A", "hyperjump"],
+    ["from_height", "850000"],
+    ["to_height", "850100"],
+    ["from_hj", "<merkle_root_850000>"],
+    ["to_hj", "<merkle_root_850100>"],
+    ["prev", "<previous_event_id>"],
+    ["proof", "<cantor_root_hex>"]
+  ]
+}
+```
+
+**Verification:** Recompute tree from leaves, verify root matches. O(path_length) operations.
+
+**See:** `decks/hyperjump-traversal-proof.md` for full specification.
+
+## Coverage Projections
+
+With ~940K Bitcoin blocks (2026) and 3 planes per HJ = **2.8M effective entry targets**:
+
+| Year | Blocks | Effective Plane HJs | Median Entry LCA | Consumer Time | Cloud Cost |
+|------|--------|---------------------|------------------|---------------|------------|
+| 2026 | 940K | 2.8M | **h≈33** | ~15 minutes | ~$0.09 |
+| 2031 | 1.2M | 3.6M | h≈32.8 | ~13 minutes | ~$0.07 |
+| 2036 | 1.5M | 4.5M | h≈32.7 | ~12 minutes | ~$0.06 |
+
+**With Moore's Law** (compute doubles every 2.5 years):
+- 2026: ~15 minutes / $0.09
+- 2031: ~4 minutes / $0.02
+- 2036: ~1 minute / $0.005
+
+## Three-Layer Analysis
+
+**Mathematical:**
+- Exploits dimensionality reduction (sector matching: 55 bits vs Gibson: 85 bits)
+- Doesn't violate LCA decomposition invariant (changes target precision, not path)
+- Cantor traversal proof is bijective, entropy-preserving, no shortcuts (Rigidity Theorem)
+
+**Protocol:**
+- Entry via dedicated **enter** action (kind 3333, A=enter) with Cantor proof
+- Enter is 4th movement primitive (spawn, hop, sidestep, enter) - NOT sidestep
+- Enter uses Cantor (h≈33 feasible), sidestep uses Merkle (h>35-40 infeasible)
+- Exit always at exact merkle-root coordinate (preserves spatial meaning)
+- Traversal proof via kind 3333 (A=hyperjump) with Cantor root
+- Backward compatible: old clients can still use point entry (expensive)
+
+**Social:**
+- Democratizes access: 15 minutes vs nation-state resources
+- Aligns with "infrastructure for everyone, owned by no one"
+- Multi-hop routing emerges as skill (like physical transit planning)
+- Traversal proofs create verifiable movement history without revealing exact path
+
+## Open Questions (Resolved and Remaining)
+
+### Resolved ✅
+1. **Commitment height formula?** → **Block height bit_length** (see analysis)
+2. **Maximum commitment height?** → **No cap needed**, naturally bounded (h≤20 in 2026, h≤24 by 2100)
+3. **Traversal proof mechanism?** → **Incremental Cantor Tree with Temporal Leaf** (this PR)
+
+### Remaining
+4. **Welcome HJ for new spawns?** A predictable genesis-derived entry point? Or keep it decentralized?
+5. **Route discovery:** Built-in graph routing in clients, or third-party tools?
+6. **Bitcoin reorg handling:** Track finality depth (e.g., 6 confirmations) before accepting new HJs?
+
+See `decks/DECK-0001-finalization-summary.md` for detailed analysis and recommendations.
+
+## Implementation Checklist
+
+- [x] Community review and feedback
+- [x] Finalize directional commitment formula → Block height bit_length
+- [x] Finalize traversal proof mechanism → Incremental Cantor Tree
+- [ ] Merge DECK-0001 v2 to main branch
+- [ ] Add sector-based HJ queries to cyberspace-cli
+- [ ] Add commitment computation to hyperjump validation
+- [ ] Add Cantor tree builder for traversal proofs
+- [ ] Implement **enter** action handler (kind 3333, A=enter)
+- [ ] Update tests for enter action validation (Cantor proof + sector match)
+- [ ] Write migration guide for existing clients
+
+---
+
+**Files in this PR:**
+- `decks/DECK-0001-hyperjumps.md` - Complete spec (sector entry + block height commitment + traversal proof)
+- `decks/hyperjump-traversal-proof.md` - Full traversal proof specification
+- `decks/hyperjump-commitment-analysis.md` - Mathematical analysis of commitment metric
+- `decks/DECK-0001-finalization-summary.md` - Status report and recommendations
+
+---
+
+**This is a draft for community review.** Comments welcome via GitHub issues or Nostr DM to @arkin0x.

decks/DECISION-action-kinds.md

@@ -0,0 +1,66 @@
+# Cyberspace Protocol Decisions - Action Kind Numbers
+
+## CRITICAL RULE: All Actions Are Kind 3333
+
+**Decision Date:** 2026-04-02 (sidestep spec)
+**Authority:** sidestep-proof-formal-spec.md §8.1
+**Status:** LOCKED - Do not violate
+
+### The Rule
+
+**ALL Cyberspace movement actions use kind 3333, differentiated by the `A` tag.**
+
+Never invent new kind numbers for action types. This is not optional. This is the foundational pattern established in the sidestep specification.
+
+### Established Action Types
+
+| A Tag | Purpose | Proof Type | Spec |
+|-------|---------|------------|------|
+| `spawn` | Initial entry to cyberspace | Fixed claim | CYBERSPACE_V2.md |
+| `hop` | Local movement (within sector) | Cantor pairing tree | CYBERSPACE_V2.md |
+| `sidestep` | LCA boundary crossing (storage-infeasible) | Merkle hash tree | sidestep-proof-formal-spec.md |
+| `enter` | Hyperjump plane entry | Cantor proof (h≈33) | DECK-0001-hyperjumps.md |
+| `hyperjump` | Inter-hyperjump traversal | Cantor tree over path | hyperjump-traversal-proof.md |
+
+### Why This Pattern Exists
+
+1. **Consistency** - All movement is the same event type, validated by the same relays
+2. **Simplicity** - One kind number, action type in tags
+3. **Extensibility** - New actions don't require new kind numbers or NIPs
+4. **Established precedent** - Sidestep (kind 3333, A=sidestep) set this pattern
+
+### Anti-Pattern: What NOT to Do
+
+❌ **DON'T create kind 33340 for hyperjump_entry**
+❌ **DON'T create kind 33334 for enter**
+❌ **DON'T create any new kind number for actions**
+
+✅ **DO use kind 3333 with appropriate A tag**
+
+### Historical Context
+
+The sidestep specification (2026-04-02) established this pattern:
+```json
+{
+  "kind": 3333,
+  "tags": [["A", "sidestep"], ...]
+}
+```
+
+All subsequent action types MUST follow this pattern. Any spec that violates this is incorrect and must be fixed.
+
+### Enforcement
+
+If you see any of the following in specs or code:
+- `kind: 33340`
+- `kind=33334`
+- Any kind number other than 3333 for Cyberspace actions
+
+**Flag it as an error.** This is a protocol violation.
+
+---
+
+*This decision is locked. Do not revisit without explicit Arkinox approval.*
+
+*Created: 2026-04-15*
+*Authority: sidestep-proof-formal-spec.md §8.1, DECK-0001-hyperjumps.md*

decks/DECK-0001-finalization-summary.md

@@ -0,0 +1,124 @@
+# DECK-0001 v2 — Finalization Summary
+
+**Date:** April 15, 2026  
+**Status:** Ready for review → merge to main
+
+---
+
+## What Was Done
+
+### 1. ✅ Sector-Based Entry Planes
+
+**PR #12** (`deck-0001-plane-shadow-hyperjumps`):
+- **3 sector planes per HJ** (X, Y, Z axes), 1 sector thick (2³⁰ Gibsons)
+- Match 55-bit sector instead of 85-bit Gibson coordinate
+- Entry LCA: h≈84 → h≈33
+- Consumer cost: ~15 minutes, ~$0.09 cloud
+- **Removed** shadow HJs (unnecessary complexity)
+
+### 2. ✅ Enter Action (4th Movement Primitive)
+
+**New action type:** `enter` (kind 3333, A=enter)
+- Proves arrival at hyperjump plane via Cantor proof (h≈33 feasible)
+- Distinct from `sidestep` (which uses Merkle for h>35-40)
+- Tags: `["A", "enter"]`, `["HJ", "<target>"]`, `["axis", "X|Y|Z"]`, `["proof", "<cantor_root>"]`
+
+### 3. ✅ Hyperjump Traversal Proof
+
+**New mechanism:** Incremental Cantor Tree with Temporal Leaf
+- Single Nostr event proves multi-block traversal
+- Leaves: `[temporal_seed, B_from, B_from+1, ..., B_to]`
+- Temporal seed from `previous_event_id` prevents replay (replay = equivocation)
+- Cost: O(path_length) Cantor pairings (~1M blocks/day consumer)
+- **Supersedes** block height commitment (which was only access cost, not traversal proof)
+
+---
+
+## Current Spec Status
+
+| Mechanism | Status | Spec |
+|-----------|--------|------|
+| Sector entry planes | ✅ Solved | DECK-0001-hyperjumps.md |
+| Enter action (kind 3333, A=enter) | ✅ Solved | DECK-0001-hyperjumps.md |
+| Traversal proof (Cantor tree) | ✅ Solved | hyperjump-traversal-proof.md |
+| Exit at exact coordinate | ✅ Solved | DECK-0001-hyperjumps.md |
+
+---
+
+## Remaining Open Questions
+
+### 1. Welcome HJ for New Spawns
+
+**Question:** Should there be a predictable, low-cost entry point for newly spawned avatars?
+
+**Options:**
+- **A. Genesis-derived HJ** (e.g., block 0 merkle root)
+- **B. No special handling** (use sector planes)
+- **C. First N blocks as "beginner zone"**
+
+**Recommendation:** Option B. Sector planes already make entry consumer-feasible.
+
+---
+
+### 2. Route Discovery
+
+**Question:** Should clients have built-in graph routing for multi-hop journeys?
+
+**Recommendation:** Hybrid approach - core provides `nearest HJ` query, routing left to third parties.
+
+---
+
+### 3. Bitcoin Reorg Handling
+
+**Question:** Should implementations track Bitcoin finality depth before accepting HJs?
+
+**Recommendation:** Accept all HJs immediately, tag <6 confirmations as "unconfirmed", default to avoiding them.
+
+---
+
+## Implementation Checklist
+
+- [x] Community review and feedback
+- [x] Finalize traversal proof mechanism → Incremental Cantor Tree
+- [x] Finalize entry action → kind 3333, A=enter
+- [ ] Merge DECK-0001 v2 to main branch
+- [ ] Add sector-based HJ queries to cyberspace-cli
+- [ ] Implement enter action handler (kind 3333, A=enter)
+- [ ] Implement hyperjump traversal proof builder
+- [ ] Update tests for enter + hyperjump validation
+- [ ] Write migration guide for existing clients
+
+---
+
+## Next Steps
+
+1. **Review this summary** and updated specs
+2. **Decide on remaining open questions**
+3. **Merge PR #12** to main branch
+4. **Begin implementation** in cyberspace-cli
+
+---
+
+## Files Modified
+
+- `decks/DECK-0001-hyperjumps.md` (sector entry + enter action)
+- `decks/hyperjump-traversal-proof.md` (new - Cantor tree traversal proof)
+- `decks/DECISION-action-kinds.md` (new - locked kind 3333 pattern)
+- PR #12 description updated
+
+**Branch:** `deck-0001-plane-shadow-hyperjumps`  
+**Status:** Pushed to origin, ready for merge
+
+---
+
+## Key Insight
+
+**Entry** and **traversal** are separate concerns:
+- **Entry** pays the "toll" to board the HJ network (sector-plane, h≈33 Cantor proof)
+- **Traversal** proves the path was actually traveled (Cantor tree over block heights)
+
+The old "block height commitment" was an access toll, not a traversal proof. The new Cantor tree mechanism provides actual path verification with non-reuse guarantees.
+
+---
+
+*This summary prepared by XOR on April 15, 2026.*