From acc35b7a412cc38a1793d988f2358c6bdbc46106 Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 17:52:02 -0500 Subject: [PATCH 01/11] Add DECK-0001 v2 draft: Plane-based hyperjump access with shadow derivation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proposed extension to DECK-0001 solving the bootstrap problem: - Plane-based entry: Each HJ has 3 entry planes (X, Y, Z), reducing entry LCA from h≈84 (3D point) to h≈57 (1D plane, best axis) - Shadow HJ derivation: SHA256 iteration creates 60x more HJs at exponentially increasing cost (2^N multiplier, N ≤ 60) - Directional Cantor commitment: Hyperjump cost scales with XOR distance, single-use, prevents locality collapse - Coverage analysis: 00 cloud entry cost in 2026 → 5 by 2041 (with Moore's Law) - Preserves all Five Properties with explicit layer analysis (math/protocol/social) This is a draft for community review. See open questions in the spec for discussion points. --- decks/DECK-0001-plane-shadow-v2.md | 339 +++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 decks/DECK-0001-plane-shadow-v2.md diff --git a/decks/DECK-0001-plane-shadow-v2.md b/decks/DECK-0001-plane-shadow-v2.md new file mode 100644 index 0000000..12d243b --- /dev/null +++ b/decks/DECK-0001-plane-shadow-v2.md @@ -0,0 +1,339 @@ +# DECK-0001 (Draft v2): Plane-Based Hyperjump Access with Shadow Derivation + +**DECK:** 0001 +**Title:** Plane-Based Hyperjump Access with Shadow Derivation +**Status:** Proposal (supersedes 2026-02-28 draft) +**Created:** 2026-04-08 +**Author:** Arkinox +**Requires:** `CYBERSPACE_V2.md` v2.x + +--- + +## Abstract + +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 two mechanisms: + +1. **Plane-based entry**: Each hyperjump defines three 2D entry planes (one per axis). Avatars can enter by reaching *any* point on one plane, reducing the sidestep from 3D (h≈84) to 1D (h≈57-63). + +2. **Shadow hyperjump derivation**: Each base hyperjump coordinate can be iteratively hashed to derive "shadow" hyperjumps at exponentially increasing entry cost. This multiplies effective HJ density by ~60x, further reducing entry LCA to h≈50-57. + +**Result:** With ~940K Bitcoin block HJs + 60x shadow derivation = **56M effective plane HJs**, the entry cost drops from ~$50,000 cloud compute to **~$800**, enabling consumer access within a 1-year budget. + +--- + +## Layer Analysis (Math / Protocol / Social) + +### Mathematical Layer + +The Cantor pairing tree's **decomposition invariant** (Property 5) proves that *every* path between two points contains at least one hop with LCA ≥ the bit position where they differ. This is absolute for movement within the Cantor metric. + +**However**, plane-based entry does NOT violate this theorem. It changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D plane where *one* coordinate matches. The LCA is computed on a **single axis**, not all three. + +- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 +- **1D plane entry:** LCA = min(LCA_x, LCA_y, LCA_z) ≈ 57-63 (best of 3 axes) + +This is not a cheat—it's exploiting the geometric fact that a plane has lower dimensionality than a point in 3D space. The theorem still holds *within* each dimension; we're simply choosing the cheapest dimension. + +Shadow derivation uses SHA256 as a deterministic expansion function. Each iteration produces a new pseudo-random coordinate. The entry cost doubles per iteration (2^N), creating a natural economic tier system. + +### Protocol Layer + +The protocol must define: +- How plane entry is validated (prove you're on the plane) +- How shadow HJs are derived and verified +- How inter-hyperjump travel cost is computed (the **hyperjump-cost problem**) + +Critically, **exit** from a hyperjump always occurs at the exact merkle-root coordinate. This preserves spatial meaning and prevents planes from being "free teleportation." + +### Social Layer + +Plane-based entry democratizes access. Without it, only entities with nation-state resources could reach *any* hyperjump. With it, consumers spending ~$1,000 on cloud compute can reach their first HJ within a year of parallel computation. + +This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no one**. The thermodynamic cost remains—it's just amortized over a larger set of entry points. + +--- + +## Specification + +### 1. Plane-Based Entry (Normative) + +#### Definition + +For a hyperjump at coordinate **H = (Hx, Hy, Hz, Hp)**, three entry planes are defined: + +- **X-plane**: All coordinates where **X = Hx** (covers (Hx, *, *, *)) +- **Y-plane**: All coordinates where **Y = Hy** (covers (*, Hy, *, *)) +- **Z-plane**: All coordinates where **Z = Hz** (covers (*, *, Hz, *)) + +The plane bit **Hp** is inherited from the hyperjump coordinate (plane 0 = dataspace, plane 1 = ideaspace). + +#### Entry Validation + +To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate on that plane. This is done via a standard **sidestep movement event** (`A=sidestep`) with: + +- Destination coordinate **D** where the chosen axis matches the hyperjump's axis value +- Standard sidestep Merkle proof for all three axes + +Example (entering via Y-plane): +```json +{ + "kind": 3333, + "tags": [ + ["A", "sidestep"], + ["C", ""], // Y value matches HJ's Y + ["proof", ""], + ["Y_matches_HJ", "true"] // Optional hint for validators + ] +} +``` + +After reaching the plane, the avatar publishes a **hyperjump entry event** (new event kind, see below) to signal they are now "on" the hyperjump network. + +#### Exit Behavior + +When exiting a hyperjump (after a `A=hyperjump` action), the avatar **always** arrives at the exact merkle-root coordinate **(Hx, Hy, Hz, Hp)**. The plane entry advantage applies only to *entering*, not exiting. + +This ensures: +- Spatial meaning is preserved (you can't "teleport around" distance) +- Navigation FROM the exit point to a final destination still costs work +- The plane mechanism doesn't collapse locality + +--- + +### 2. Shadow Hyperjump Derivation (Normative) + +#### Derivation Function + +Given a base hyperjump coordinate **H₀** (from Bitcoin block merkle root), shadow coordinates are derived iteratively: + +``` +H₀ = merkle_root_as_coord256 +H₁ = SHA256(H₀) // reinterpret 32-byte hash as coord256 +H₂ = SHA256(H₁) +... +Hₙ = SHA256(Hₙ₋₁) +``` + +Each **Hₙ** is a valid **shadow hyperjump** at **iteration depth N**. + +#### Entry Cost + +Entering a shadow hyperjump at depth **N** costs **2^N** times the base sidestep cost. This is enforced by requiring the avatar to include the **iteration count N** in their entry proof, and validators recompute the expected LCA penalty. + +Practical limits: +- **N ≤ 20**: Consumer-feasible (2²⁰ ≈ 1M multiplier, adds ~20 to LCA) +- **N ≤ 40**: Cloud-feasible (~$100-500) +- **N ≤ 60**: Nation-state feasible (~$10,000+) +- **N > 60**: Prohibitively expensive + +Implementations SHOULD reject shadow entries with N > 60. + +#### Validation + +Block anchor events MUST include an optional **shadow depth tag**: +- `shadow` tag: `["shadow", ""]` where `` is a base-10 integer (0 for base HJ, 1+ for shadows) + +If omitted, depth is assumed to be 0. + +To validate a shadow hyperjump entry: +1. Derive Hₙ from base H₀ using N iterations +2. Verify the avatar's destination coordinate matches Hₙ (or is on Hₙ's plane) +3. Apply entry cost multiplier 2^N to the sidestep proof validation + +--- + +### 3. Hyperjump-Cost Problem (Proposed Specification) + +#### The Problem + +The current DECK-0001 defines hyperjump as **free teleportation** between any two hyperjumps. This creates a graph where all nodes are equidistant (cost=0), which: +- Collapses spatial meaning +- Makes "distance" irrelevant once on the network +- Violates Property 1 (locality) at the protocol layer + +We need a cost function that: +1. Scales with spatial distance (preserves locality) +2. Costs meaningful work (not arbitrary fees) +3. Cannot be reused (no amortization) +4. Is consumer-feasible for reasonable distances + +#### Proposed Solution: Directional Cantor Commitment + +When making a hyperjump from **H_from** to **H_to**, the avatar must compute a **directional Cantor commitment**: + +``` +direction_vector = H_to XOR H_from // 256-bit directional signature +commitment_height = popcount(direction_vector >> 128) // 0-128, based on high bits +commitment = compute_cantor_prefix(direction_vector, commitment_height) +``` + +The **commitment** is a partial Cantor tree computation (not a full hop proof) that: +- Costs 2^commitment_height operations +- Is unique to this specific (from, to) pair +- Cannot be reused for a different destination +- Expires after use (single-use commitment) + +#### Cost Scaling + +| Distance (hamming XOR) | Commitment Height | Compute Time (consumer) | Cloud Cost | +|------------------------|-------------------|-------------------------|------------| +| < 64 bits (nearby) | 8-16 | < 1 second | <$0.01 | +| 64-96 bits (same sector band) | 16-24 | 1 min - 1 hour | $0.01-1 | +| 96-128 bits (cross-sector) | 24-32 | 1 hour - 1 day | $1-10 | +| 128-160 bits (far) | 32-40 | 1 day - 1 week | $10-100 | +| 160-192 bits (very far) | 40-48 | 1 week - 1 month | $100-1000 | +| 192-224 bits (across space) | 48-56 | 1 month - 1 year | $1000-10k | +| > 224 bits (opposite corners) | 56-64 | 1-10 years | $10k-100k | + +This preserves the **graph structure** of the hyperjump network while maintaining spatial locality. Nearby HJs are cheap to reach; distant ones cost more. + +#### Non-Reuse Mechanism + +The commitment includes: +- Previous movement event ID (binds to specific position in chain) +- Timestamp of hyperjump event +- Destination coordinate + +This ensures the commitment is **single-use** and **non-transferable**. Validators reject any hyperjump event where the commitment doesn't match the specific (from, to, timestamp) tuple. + +#### Open Questions + +1. **Should commitment height be continuous or tiered?** Continuous is more precise; tiered is simpler to implement. + +2. **Can commitments be precomputed?** Yes, but they're still single-use. Precomputation is an optimization, not an amortization. + +3. **What prevents farming cheap short hops to "build up" to a long hop?** Nothing—this is intended! Strategic multi-hop routing is a valid use case and mirrors physical transit networks. + +4. **Should there be a maximum commitment height?** Suggest N=64 (same as shadow limit). Beyond that, the hop is effectively impossible for consumers. + +--- + +## Coverage and Accessibility Analysis + +### Assumptions + +- Bitcoin block production: 52,560 blocks/year (~10 min average) +- Current blocks (2026): ~940,000 +- Shadow multiplier: 60x (N ≤ 60 practical limit) +- Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 +- Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` + - 85-bit axis space = 2⁸⁵ sectors + - With 169M plane HJs: LCA ≈ log₂(2⁸⁵ / 1.69×10⁸) ≈ **log₂(2.2×10¹⁷) ≈ 57.5** + +### Spawn-to-HJ LCA Projection (1D, best-of-3 axes) + +| Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | +|------|--------|---------------------|---------|---------------|---------------------------| +| 2026 | 940K | 169M | 57.5 | ~13 years | ~$800 | +| 2031 | 1.2M | 216M | 56.8 | ~8 years | ~$500 | +| 2036 | 1.5M | 270M | 56.2 | ~5 years | ~$350 | +| 2046 | 2.0M | 360M | 55.3 | ~2.5 years | ~$180 | +| 2056 | 2.5M | 450M | 54.6 | ~1.3 years | ~$100 | + +**With Moore's Law (compute doubles every 2.5 years):** + +| Year | Compute Multiplier | Effective LCA Reduction | Time to First HJ | +|------|-------------------|-------------------------|------------------| +| 2026 | 1× | baseline | 13 years / $800 | +| 2031 | 4× | -0.5 | 3.3 years / $200 | +| 2036 | 16× | -1.0 | 0.8 years / $50 | +| 2041 | 64× | -1.5 | **2.5 months / $15** | +| 2046 | 256× | -2.0 | **3 weeks / $4** | + +### Total Cyberspace Coverage + +| Metric | Value | +|--------|-------| +| Total coord256 space | 2²⁵⁶ ≈ 1.16×10⁷⁷ points | +| Total sector space (85-bit axes) | 2²⁵⁵ ≈ 5.8×10⁷⁶ sectors | +| HJ coverage (2026) | 169M / 5.8×10⁷⁶ = **2.9×10⁻⁶⁹** (negligible) | +| Interpretation | HJs are **vanishingly sparse**—they don't "cover" space, they provide strategic waypoints | + +**Key insight:** Cyberspace doesn't "collapse" as HJ density increases. It transitions from **impossible** → **nation-state only** → **cloud-feasible** → **consumer-accessible**. The spatial structure remains; only accessibility changes. + +--- + +## Events Specification + +### New Event Kind: Hyperjump Entry Announcement + +**Kind:** 33340 (CSEP-33340) +**Purpose:** Signal that an avatar has reached a hyperjump plane and is now on the HJ network + +**Required tags:** +- `A`: `["A", "hyperjump_entry"]` +- `e`: `["e", "", "", "previous"]` +- `c`: `["c", ""]` (coordinate on the entry plane) +- `HJ`: `["HJ", ""]` (the target HJ being entered) +- `axis`: `["axis", "X"|"Y"|"Z"]` (which plane was used) + +**Optional tags:** +- `shadow`: `["shadow", ""]` (if entering a shadow HJ) + +**Validation:** +1. Verify previous event was a valid sidestep to a plane coordinate +2. Verify the plane coordinate matches the target HJ on the specified axis +3. If shadow depth > 0, verify entry cost multiplier is applied + +--- + +## Backward Compatibility + +- Existing hyperjump coordinates (merkle roots) are unchanged +- Existing `kind=321` block anchor events remain valid +- Old clients that don't support plane entry can still use **point entry** (3D hop)—it just costs more +- Shadow HJs are opt-in: validators that don't recognize shadow depth=0 only + +--- + +## Security Considerations + +### Plane Entry Does Not Reveal Information + +Knowing an avatar is "on the X-plane of HJ H" reveals only that their X coordinate equals Hx. Their Y and Z coordinates remain hidden. This is strictly less information than revealing the full 3D point. + +### Shadow Derivation Is Trustless + +Anyone can derive shadow HJs from public Bitcoin data. No trusted setup or coordination required. The 2^N cost scaling is mathematical, not policy-based. + +### Directional Commitment Prevents Free Teleportation + +By binding the commitment cost to the XOR distance between specific (from, to) pairs, the protocol prevents: +- **Reuse:** Commitment is single-use +- **Amortization:** Can't "build up" credit for long hops +- **Distance cheating:** Far hops cost more, always + +--- + +## Open Questions for Discussion + +1. **What should the commitment height formula be?** Current proposal uses popcount of high 128 bits. Alternatives: + - Full Hamming distance / 4 + - LCA height of (from, to) coordinates + - Precomputed distance tier table + +2. **Should there be a "welcome HJ" for new spawns?** A predictable low-cost entry point (e.g., derived from genesis block) could help onboard users. But this introduces a "central" point, which may violate decentralization ethos. + +3. **How should clients discover optimal multi-hop routes?** This is a graph routing problem. Should it be built into the CLI, or left to third-party tools? + +4. **What happens if Bitcoin forks or has a deep reorg?** HJs derived from reorged blocks become invalid. Should implementations track Bitcoin finality depth before accepting HJs? + +--- + +## Implementation Checklist + +- [ ] Update DECK-0001 with plane entry spec +- [ ] Add shadow derivation function to cyberspace-cli +- [ ] Implement plane-based HJ queries (filter cache by single axis) +- [ ] Add directional commitment computation to hyperjump validation +- [ ] Create `kind=33340` event handler +- [ ] Update tests for new validation rules +- [ ] Write migration guide for existing clients + +--- + +*This DECK draft is for community review. Comments welcome via GitHub issues or Nostr DM to @arkin0x.* From 2440655ed5505acac63a168e2e9fb09e0952a41f Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 18:32:41 -0500 Subject: [PATCH 02/11] Correct: planes are 1 sector wide (2^30 Gibsons thick), not 1 Gibson wide MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Entry LCA: h≈57 (Gibson match) -> h≈27-35 (sector match) Consumer time: ~13 years -> ~3 hours Cloud cost: ~00 -> ~/usr/bin/bash.05 This makes HJ network instantly accessible to consumers in 2026. --- decks/DECK-0001-plane-shadow-v2.md | 42 +++++++++++++++--------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/decks/DECK-0001-plane-shadow-v2.md b/decks/DECK-0001-plane-shadow-v2.md index 12d243b..e34bed3 100644 --- a/decks/DECK-0001-plane-shadow-v2.md +++ b/decks/DECK-0001-plane-shadow-v2.md @@ -1,6 +1,7 @@ # DECK-0001 (Draft v2): Plane-Based Hyperjump Access with Shadow Derivation **DECK:** 0001 +**Version:** 2.1 (corrected for sector-wide planes) **Title:** Plane-Based Hyperjump Access with Shadow Derivation **Status:** Proposal (supersedes 2026-02-28 draft) **Created:** 2026-04-08 @@ -15,7 +16,7 @@ This revision extends DECK-0001 to solve the **bootstrap problem**: how can a ne 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 two mechanisms: +This proposal introduces two mechanisms (with sector-wide entry planes): 1. **Plane-based entry**: Each hyperjump defines three 2D entry planes (one per axis). Avatars can enter by reaching *any* point on one plane, reducing the sidestep from 3D (h≈84) to 1D (h≈57-63). @@ -33,8 +34,9 @@ The Cantor pairing tree's **decomposition invariant** (Property 5) proves that * **However**, plane-based entry does NOT violate this theorem. It changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D plane where *one* coordinate matches. The LCA is computed on a **single axis**, not all three. -- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 -- **1D plane entry:** LCA = min(LCA_x, LCA_y, LCA_z) ≈ 57-63 (best of 3 axes) +- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 (full 85-bit Gibson space) +- **1D sector-plane entry:** LCA ≈ log₂(2⁵⁵ / HJs) ≈ 29-35 (55-bit sector space) +- **With 60x shadow:** LCA ≈ log₂(2⁵⁵ / 56M) ≈ 29 (consumer: ~3 hours, cloud: ~$0.05) This is not a cheat—it's exploiting the geometric fact that a plane has lower dimensionality than a point in 3D space. The theorem still holds *within* each dimension; we're simply choosing the cheapest dimension. @@ -220,29 +222,27 @@ This ensures the commitment is **single-use** and **non-transferable**. Validato - Current blocks (2026): ~940,000 - Shadow multiplier: 60x (N ≤ 60 practical limit) - Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 -- Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` - - 85-bit axis space = 2⁸⁵ sectors - - With 169M plane HJs: LCA ≈ log₂(2⁸⁵ / 1.69×10⁸) ≈ **log₂(2.2×10¹⁷) ≈ 57.5** +- Average 1D LCA gap formula for sector matching: `LCA ≈ log₂(2⁵⁵ / effective_HJs)` + - **55-bit sector space** = 2⁵⁵ sectors per axis (plane is 1 sector = 2³⁰ Gibsons thick) + - With 169M plane HJs: LCA ≈ log₂(2⁵⁵ / 1.69×10⁸) ≈ **log₂(2.1×10⁸) ≈ 27.7** ### Spawn-to-HJ LCA Projection (1D, best-of-3 axes) | Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | |------|--------|---------------------|---------|---------------|---------------------------| -| 2026 | 940K | 169M | 57.5 | ~13 years | ~$800 | -| 2031 | 1.2M | 216M | 56.8 | ~8 years | ~$500 | -| 2036 | 1.5M | 270M | 56.2 | ~5 years | ~$350 | -| 2046 | 2.0M | 360M | 55.3 | ~2.5 years | ~$180 | -| 2056 | 2.5M | 450M | 54.6 | ~1.3 years | ~$100 | - -**With Moore's Law (compute doubles every 2.5 years):** - -| Year | Compute Multiplier | Effective LCA Reduction | Time to First HJ | -|------|-------------------|-------------------------|------------------| -| 2026 | 1× | baseline | 13 years / $800 | -| 2031 | 4× | -0.5 | 3.3 years / $200 | -| 2036 | 16× | -1.0 | 0.8 years / $50 | -| 2041 | 64× | -1.5 | **2.5 months / $15** | -| 2046 | 256× | -2.0 | **3 weeks / $4** | +| 2026 | 940K | 169M | 27.7 | ~3 hours | ~$0.05 | +| 2031 | 1.2M | 216M | 27.4 | ~2 hours | ~$0.03 | +| 2036 | 1.5M | 270M | 27.2 | ~1.5 hours | ~$0.02 | +| 2046 | 2.0M | 360M | 26.9 | ~1 hour | ~$0.01 | +| 2056 | 2.5M | 450M | 26.7 | ~45 minutes | < $0.01 | + +**With Moore's Law (compute doubles every 2.5 years) — already trivial in 2026:** + +| Year | Compute Multiplier | Time to First HJ | Cloud Cost | +|------|-------------------|------------------|------------| +| 2026 | 1× | ~3 hours | ~$0.05 | +| 2031 | 4× | ~45 minutes | ~$0.01 | +| 2036 | 16× | ~10 minutes | <$0.01 | ### Total Cyberspace Coverage From 378dcfea789d7b7cac8093c9ca7c73a9c39cc87f Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 18:48:10 -0500 Subject: [PATCH 03/11] Add blocks-only analysis: sector planes alone are sufficient --- decks/DECK-0001-plane-shadow-v2.md | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/decks/DECK-0001-plane-shadow-v2.md b/decks/DECK-0001-plane-shadow-v2.md index e34bed3..9a7e496 100644 --- a/decks/DECK-0001-plane-shadow-v2.md +++ b/decks/DECK-0001-plane-shadow-v2.md @@ -22,7 +22,9 @@ This proposal introduces two mechanisms (with sector-wide entry planes): 2. **Shadow hyperjump derivation**: Each base hyperjump coordinate can be iteratively hashed to derive "shadow" hyperjumps at exponentially increasing entry cost. This multiplies effective HJ density by ~60x, further reducing entry LCA to h≈50-57. -**Result:** With ~940K Bitcoin block HJs + 60x shadow derivation = **56M effective plane HJs**, the entry cost drops from ~$50,000 cloud compute to **~$800**, enabling consumer access within a 1-year budget. +**Result:** With ~940K Bitcoin block HJs and sector-wide planes, entry cost drops from ~$50,000 to **~$0.09 cloud** (**~15 minutes consumer**). Adding 60x shadow derivation makes it essentially instant (~14 sec, ~$0.001). + +The key innovation is **sector-wide planes**, not shadow HJs. Shadows are a 61× optimization layer, but blocks-only already solves the bootstrap problem. --- @@ -244,6 +246,27 @@ This ensures the commitment is **single-use** and **non-transferable**. Validato | 2031 | 4× | ~45 minutes | ~$0.01 | | 2036 | 16× | ~10 minutes | <$0.01 | + +### Critical Finding: Sector Planes Alone Are Sufficient + +**Shadow HJs are an optimization, NOT a requirement.** + +| Configuration | Median LCA | Consumer Time | Cloud Cost | +|--------------|------------|---------------|------------| +| **Blocks only** (no shadows) | h=33 | ~15 minutes | ~$0.09 | +| **+ 60x shadows** | h=27 | ~14 seconds | ~$0.001 | +| **Improvement** | 6 bits easier | 61× faster | 61× cheaper | + +This means: +- **Sector-wide planes solve the bootstrap problem** (15 min is very feasible) +- **Shadow HJs provide "instant" access** (seconds, pennies) as an optimization layer +- The design is robust — it works with or without shadow derivation + +In practice: +- 2026 consumers: blocks-only (15 min) is acceptable for first HJ access +- Power users: use +60x shadows for instant entry +- Future: as Bitcoin accumulates more blocks, even blocks-only becomes faster + ### Total Cyberspace Coverage | Metric | Value | From be06d8ad83e3fbc74b23ad8c3a40da761550d723 Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 19:45:46 -0500 Subject: [PATCH 04/11] Revert to clean sector-plane base (no shadow) --- decks/DECK-0001-plane-shadow-v2.md | 25 +------------------------ 1 file changed, 1 insertion(+), 24 deletions(-) diff --git a/decks/DECK-0001-plane-shadow-v2.md b/decks/DECK-0001-plane-shadow-v2.md index 9a7e496..e34bed3 100644 --- a/decks/DECK-0001-plane-shadow-v2.md +++ b/decks/DECK-0001-plane-shadow-v2.md @@ -22,9 +22,7 @@ This proposal introduces two mechanisms (with sector-wide entry planes): 2. **Shadow hyperjump derivation**: Each base hyperjump coordinate can be iteratively hashed to derive "shadow" hyperjumps at exponentially increasing entry cost. This multiplies effective HJ density by ~60x, further reducing entry LCA to h≈50-57. -**Result:** With ~940K Bitcoin block HJs and sector-wide planes, entry cost drops from ~$50,000 to **~$0.09 cloud** (**~15 minutes consumer**). Adding 60x shadow derivation makes it essentially instant (~14 sec, ~$0.001). - -The key innovation is **sector-wide planes**, not shadow HJs. Shadows are a 61× optimization layer, but blocks-only already solves the bootstrap problem. +**Result:** With ~940K Bitcoin block HJs + 60x shadow derivation = **56M effective plane HJs**, the entry cost drops from ~$50,000 cloud compute to **~$800**, enabling consumer access within a 1-year budget. --- @@ -246,27 +244,6 @@ This ensures the commitment is **single-use** and **non-transferable**. Validato | 2031 | 4× | ~45 minutes | ~$0.01 | | 2036 | 16× | ~10 minutes | <$0.01 | - -### Critical Finding: Sector Planes Alone Are Sufficient - -**Shadow HJs are an optimization, NOT a requirement.** - -| Configuration | Median LCA | Consumer Time | Cloud Cost | -|--------------|------------|---------------|------------| -| **Blocks only** (no shadows) | h=33 | ~15 minutes | ~$0.09 | -| **+ 60x shadows** | h=27 | ~14 seconds | ~$0.001 | -| **Improvement** | 6 bits easier | 61× faster | 61× cheaper | - -This means: -- **Sector-wide planes solve the bootstrap problem** (15 min is very feasible) -- **Shadow HJs provide "instant" access** (seconds, pennies) as an optimization layer -- The design is robust — it works with or without shadow derivation - -In practice: -- 2026 consumers: blocks-only (15 min) is acceptable for first HJ access -- Power users: use +60x shadows for instant entry -- Future: as Bitcoin accumulates more blocks, even blocks-only becomes faster - ### Total Cyberspace Coverage | Metric | Value | From cc6c4199dd2eeec80df4fa102e77f90b8e516b8b Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 19:47:22 -0500 Subject: [PATCH 05/11] DECK-0001 v2: Sector-based hyperjump entry (no shadow HJs) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Clean rewrite focusing on sector-matching planes as the bootstrap solution. Key changes: - Remove all shadow hyperjump derivation - Sector planes alone: h≈33, ~15 min, /usr/bin/bash.09 cloud - Improvement: 51 bits easier than point entry (10^14× cheaper) - Directional Cantor commitment for inter-HJ travel cost - New event kind 33340 (hyperjump entry announcement) Shadow HJs were a 61x optimization, not a requirement. Sector planes solve the bootstrap problem elegantly on their own. --- ...2.md => DECK-0001-plane-shadow-v2.md.orig} | 42 +-- decks/DECK-0001-plane-shadow-v2.md.rej | 32 ++ decks/DECK-0001-sector-entry-v2.md | 347 ++++++++++++++++++ 3 files changed, 400 insertions(+), 21 deletions(-) rename decks/{DECK-0001-plane-shadow-v2.md => DECK-0001-plane-shadow-v2.md.orig} (91%) create mode 100644 decks/DECK-0001-plane-shadow-v2.md.rej create mode 100644 decks/DECK-0001-sector-entry-v2.md diff --git a/decks/DECK-0001-plane-shadow-v2.md b/decks/DECK-0001-plane-shadow-v2.md.orig similarity index 91% rename from decks/DECK-0001-plane-shadow-v2.md rename to decks/DECK-0001-plane-shadow-v2.md.orig index e34bed3..12d243b 100644 --- a/decks/DECK-0001-plane-shadow-v2.md +++ b/decks/DECK-0001-plane-shadow-v2.md.orig @@ -1,7 +1,6 @@ # DECK-0001 (Draft v2): Plane-Based Hyperjump Access with Shadow Derivation **DECK:** 0001 -**Version:** 2.1 (corrected for sector-wide planes) **Title:** Plane-Based Hyperjump Access with Shadow Derivation **Status:** Proposal (supersedes 2026-02-28 draft) **Created:** 2026-04-08 @@ -16,7 +15,7 @@ This revision extends DECK-0001 to solve the **bootstrap problem**: how can a ne 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 two mechanisms (with sector-wide entry planes): +This proposal introduces two mechanisms: 1. **Plane-based entry**: Each hyperjump defines three 2D entry planes (one per axis). Avatars can enter by reaching *any* point on one plane, reducing the sidestep from 3D (h≈84) to 1D (h≈57-63). @@ -34,9 +33,8 @@ The Cantor pairing tree's **decomposition invariant** (Property 5) proves that * **However**, plane-based entry does NOT violate this theorem. It changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D plane where *one* coordinate matches. The LCA is computed on a **single axis**, not all three. -- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 (full 85-bit Gibson space) -- **1D sector-plane entry:** LCA ≈ log₂(2⁵⁵ / HJs) ≈ 29-35 (55-bit sector space) -- **With 60x shadow:** LCA ≈ log₂(2⁵⁵ / 56M) ≈ 29 (consumer: ~3 hours, cloud: ~$0.05) +- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 +- **1D plane entry:** LCA = min(LCA_x, LCA_y, LCA_z) ≈ 57-63 (best of 3 axes) This is not a cheat—it's exploiting the geometric fact that a plane has lower dimensionality than a point in 3D space. The theorem still holds *within* each dimension; we're simply choosing the cheapest dimension. @@ -222,27 +220,29 @@ This ensures the commitment is **single-use** and **non-transferable**. Validato - Current blocks (2026): ~940,000 - Shadow multiplier: 60x (N ≤ 60 practical limit) - Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 -- Average 1D LCA gap formula for sector matching: `LCA ≈ log₂(2⁵⁵ / effective_HJs)` - - **55-bit sector space** = 2⁵⁵ sectors per axis (plane is 1 sector = 2³⁰ Gibsons thick) - - With 169M plane HJs: LCA ≈ log₂(2⁵⁵ / 1.69×10⁸) ≈ **log₂(2.1×10⁸) ≈ 27.7** +- Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` + - 85-bit axis space = 2⁸⁵ sectors + - With 169M plane HJs: LCA ≈ log₂(2⁸⁵ / 1.69×10⁸) ≈ **log₂(2.2×10¹⁷) ≈ 57.5** ### Spawn-to-HJ LCA Projection (1D, best-of-3 axes) | Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | |------|--------|---------------------|---------|---------------|---------------------------| -| 2026 | 940K | 169M | 27.7 | ~3 hours | ~$0.05 | -| 2031 | 1.2M | 216M | 27.4 | ~2 hours | ~$0.03 | -| 2036 | 1.5M | 270M | 27.2 | ~1.5 hours | ~$0.02 | -| 2046 | 2.0M | 360M | 26.9 | ~1 hour | ~$0.01 | -| 2056 | 2.5M | 450M | 26.7 | ~45 minutes | < $0.01 | - -**With Moore's Law (compute doubles every 2.5 years) — already trivial in 2026:** - -| Year | Compute Multiplier | Time to First HJ | Cloud Cost | -|------|-------------------|------------------|------------| -| 2026 | 1× | ~3 hours | ~$0.05 | -| 2031 | 4× | ~45 minutes | ~$0.01 | -| 2036 | 16× | ~10 minutes | <$0.01 | +| 2026 | 940K | 169M | 57.5 | ~13 years | ~$800 | +| 2031 | 1.2M | 216M | 56.8 | ~8 years | ~$500 | +| 2036 | 1.5M | 270M | 56.2 | ~5 years | ~$350 | +| 2046 | 2.0M | 360M | 55.3 | ~2.5 years | ~$180 | +| 2056 | 2.5M | 450M | 54.6 | ~1.3 years | ~$100 | + +**With Moore's Law (compute doubles every 2.5 years):** + +| Year | Compute Multiplier | Effective LCA Reduction | Time to First HJ | +|------|-------------------|-------------------------|------------------| +| 2026 | 1× | baseline | 13 years / $800 | +| 2031 | 4× | -0.5 | 3.3 years / $200 | +| 2036 | 16× | -1.0 | 0.8 years / $50 | +| 2041 | 64× | -1.5 | **2.5 months / $15** | +| 2046 | 256× | -2.0 | **3 weeks / $4** | ### Total Cyberspace Coverage diff --git a/decks/DECK-0001-plane-shadow-v2.md.rej b/decks/DECK-0001-plane-shadow-v2.md.rej new file mode 100644 index 0000000..e2d3a8d --- /dev/null +++ b/decks/DECK-0001-plane-shadow-v2.md.rej @@ -0,0 +1,32 @@ +--- DECK-0001-plane-shadow-v2.md ++++ DECK-0001-plane-shadow-v2.md +@@ -61,12 +63,14 @@ This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no + + ### Entry Validation + +-To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate on that plane. This is done via a standard **sidestep movement event** (`A=sidestep`) with: ++To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. ++ ++This is done via a standard **sidestep movement event** (`A=sidestep`) with: + + - Destination coordinate **D** where `sector(chosen_axis) = sector(HJ_axis)` + - Standard sidestep Merkle proof for all three axes + +-Example (entering via Y-plane): ++Example (entering via Y-plane, matching sector not exact coordinate): + ```json + { + "kind": 3333, +@@ -166,10 +170,10 @@ Validators reject any hyperjump event where the commitment doesn't match the spe + + ### Coverage and Accessibility Analysis + + ### Assumptions + +-- Bitcoin block production: 52,560 blocks/year (~10 min average) ++- Bitcoin block production: 52,560 blocks/year (~10 min average) + - Current blocks (2026): ~940,000 + - Shadow multiplier: 60x (N ≤ 60 practical limit) +-- Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 ++- Effective plane HJs: blocks × 3 sector-planes × 60 shadows = **169M** by 2026 + - Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` diff --git a/decks/DECK-0001-sector-entry-v2.md b/decks/DECK-0001-sector-entry-v2.md new file mode 100644 index 0000000..ce570a8 --- /dev/null +++ b/decks/DECK-0001-sector-entry-v2.md @@ -0,0 +1,347 @@ +# DECK-0001 (Draft v2): Sector-Based Hyperjump Entry + +**DECK:** 0001 +**Title:** Sector-Based Hyperjump Entry +**Status:** Proposal (supersedes 2026-02-28 draft) +**Created:** 2026-04-08 +**Author:** Arkinox +**Requires:** `CYBERSPACE_V2.md` v2.x + +--- + +## Abstract + +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**. + +--- + +## Layer Analysis (Math / Protocol / Social) + +### Mathematical Layer + +The Cantor pairing tree's **decomposition invariant** (Property 5) proves that *every* path between two points contains at least one hop with LCA ≥ the bit position where they differ. This is absolute for movement within the Cantor metric. + +**However**, sector-plane entry changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D sector-slab where *one* axis sector matches. The LCA is computed on the **sector bits** (55 bits), not the full Gibson value (85 bits). + +- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 (full 85-bit Gibson space) +- **1D sector-plane entry:** LCA ≈ log₂(2⁵⁵ / HJs) ≈ 33 (55-bit sector space) +- **Improvement:** 51 bits easier → 2⁵¹ ≈ 2×10¹⁵ times cheaper + +This is not a cheat—it's exploiting the geometric fact that matching a sector (1 in 2³⁰ Gibsons) is vastly cheaper than matching an exact Gibson coordinate. The theorem still holds *within* each dimension; we're simply lowering the precision requirement for entry. + +### Protocol Layer + +The protocol defines: +- How sector planes are specified (1 sector thick per axis) +- How plane entry is validated (prove sector match, not Gibson match) +- How inter-hyperjump travel cost is computed (directional Cantor commitment) + +Critically, **exit** from a hyperjump always occurs at the exact merkle-root coordinate. This preserves spatial meaning and prevents planes from being "free teleportation." + +### Social Layer + +Sector-plane entry democratizes access. Without it, only entities with nation-state resources could reach *any* hyperjump. With it, consumers spending ~15 minutes of computation (~$0.09 cloud) can reach their first HJ. + +This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no one**. The thermodynamic cost remains—it's just amortized over a larger set of entry points. + +--- + +## Specification + +### 1. Sector-Based Entry Planes (Normative) + +#### Definition + +For a hyperjump at coordinate **H = (Hx, Hy, Hz, Hp)**, three entry planes are defined: + +- **X-plane**: All coordinates where **sector(X) = sector(Hx)** (covers all (X, *, *, *) matching the sector) +- **Y-plane**: All coordinates where **sector(Y) = sector(Hy)** (covers all (*, Y, *, *) matching the sector) +- **Z-plane**: All coordinates where **sector(Z) = sector(Hz)** (covers all (*, *, Z, *) matching the sector) + +Each plane is **1 sector thick** (2³⁰ Gibsons). The plane bit **Hp** is inherited from the hyperjump coordinate (plane 0 = dataspace, plane 1 = ideaspace). + +Sector extraction: `sector(coord) = coord >> 30` (high 55 bits) + +#### Entry Validation + +To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. + +This is done via a standard **sidestep movement event** (`A=sidestep`) with: + +- Destination coordinate **D** where `sector(chosen_axis) = sector(HJ_axis)` +- Standard sidestep Merkle proof for all three axes + +Example (entering via Y-plane): +```json +{ + "kind": 3333, + "tags": [ + ["A", "sidestep"], + ["C", ""], // sector(Y) matches HJ's sector(Y) + ["proof", ""] + ] +} +``` + +After reaching the plane, the avatar publishes a **hyperjump entry announcement** (kind 33340, see below) to signal they are now "on" the hyperjump network. + +#### Exit Behavior + +When exiting a hyperjump (after a `A=hyperjump` action), the avatar **always** arrives at the exact merkle-root coordinate **(Hx, Hy, Hz, Hp)**. The sector-plane advantage applies only to *entering*, not exiting. + +This ensures: +- Spatial meaning is preserved (you can't "teleport around" distance) +- Navigation FROM the exit point to a final destination still costs work +- The plane mechanism doesn't collapse locality + +--- + +### 2. Hyperjump-Cost Problem (Normative) + +#### The Problem + +The original DECK-0001 defines hyperjump as **free teleportation** between any two hyperjumps. This creates a graph where all nodes are equidistant (cost=0), which: +- Collapses spatial meaning +- Makes "distance" irrelevant once on the network +- Violates Property 1 (locality) at the protocol layer + +We need a cost function that: +1. Scales with spatial distance (preserves locality) +2. Costs meaningful work (not arbitrary fees) +3. Cannot be reused (no amortization) +4. Is consumer-feasible for reasonable distances + +#### Proposed Solution: Directional Cantor Commitment + +When making a hyperjump from **H_from** to **H_to**, the avatar must compute a **directional Cantor commitment**: + +``` +direction_vector = H_to XOR H_from // 256-bit directional signature +commitment_height = popcount(direction_vector >> 128) // 0-128, based on high bits +commitment = compute_cantor_prefix(direction_vector, commitment_height) +``` + +The **commitment** is a partial Cantor tree computation (not a full hop proof) that: +- Costs 2^commitment_height operations +- Is unique to this specific (from, to) pair +- Cannot be reused for a different destination +- Expires after use (single-use commitment) + +#### Cost Scaling + +| Distance (hamming XOR on high 128 bits) | Commitment Height | Compute Time (consumer) | Cloud Cost | +|----------------------------------------|-------------------|-------------------------|------------| +| < 32 bits (nearby) | 8-16 | < 1 second | <$0.01 | +| 32-48 bits (same sector band) | 16-24 | 1 min - 1 hour | $0.01-1 | +| 48-64 bits (cross-sector) | 24-32 | 1 hour - 1 day | $1-10 | +| 64-80 bits (far) | 32-40 | 1 day - 1 week | $10-100 | +| 80-96 bits (very far) | 40-48 | 1 week - 1 month | $100-1000 | +| 96-112 bits (across space) | 48-56 | 1 month - 1 year | $1000-10k | +| > 112 bits (opposite corners) | 56-64 | 1-10 years | $10k-100k | + +This preserves the **graph structure** of the hyperjump network while maintaining spatial locality. Nearby HJs are cheap to reach; distant ones cost more. + +#### Non-Reuse Mechanism + +The commitment includes: +- Previous movement event ID (binds to specific position in chain) +- Timestamp of hyperjump event +- Destination coordinate + +This ensures the commitment is **single-use** and **non-transferable**. Validators reject any hyperjump event where the commitment doesn't match the specific (from, to, timestamp) tuple. + +#### Open Questions + +1. **Should commitment height be continuous or tiered?** Continuous is more precise; tiered is simpler to implement. + +2. **Can commitments be precomputed?** Yes, but they're still single-use. Precomputation is an optimization, not an amortization. + +3. **What prevents farming cheap short hops to "build up" to a long hop?** Nothing—this is intended! Strategic multi-hop routing is a valid use case and mirrors physical transit networks. + +4. **Should there be a maximum commitment height?** Suggest N=64 (reasonable upper bound). Beyond that, the hop is effectively impossible for consumers. + +--- + +## Coverage and Accessibility Analysis + +### Assumptions + +- Bitcoin block production: 52,560 blocks/year (~10 min average) +- Current blocks (2026): ~940,000 +- Planes per HJ: 3 (X, Y, Z) +- Effective plane HJs: blocks × 3 planes = **2.8M** by 2026 +- Average 1D LCA gap formula for sector matching: `LCA ≈ log₂(2⁵⁵ / effective_HJs)` + - **55-bit sector space** = 2⁵⁵ sectors per axis (plane is 1 sector = 2³⁰ Gibsons thick) + - With 2.8M plane HJs: LCA ≈ log₂(2⁵⁵ / 2.8×10⁶) ≈ **log₂(1.3×10¹⁰) ≈ 33.6** + +### Spawn-to-HJ LCA Projection (1D sector match, best-of-3 axes) + +| Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | +|------|--------|---------------------|---------|---------------|---------------------------| +| 2026 | 940K | 2.8M | 33.0 | ~15 minutes | ~$0.09 | +| 2031 | 1.2M | 3.6M | 32.8 | ~13 minutes | ~$0.07 | +| 2036 | 1.5M | 4.5M | 32.7 | ~12 minutes | ~$0.06 | +| 2046 | 2.0M | 6.0M | 32.5 | ~10 minutes | ~$0.05 | +| 2056 | 2.5M | 7.5M | 32.4 | ~9 minutes | ~$0.04 | + +**With Moore's Law (compute doubles every 2.5 years):** + +| Year | Compute Multiplier | Time to First HJ | Cloud Cost | +|------|-------------------|------------------|------------| +| 2026 | 1× | ~15 minutes | ~$0.09 | +| 2031 | 4× | ~4 minutes | ~$0.02 | +| 2036 | 16× | ~1 minute | ~$0.005 | + +### Blocks-Only Analysis + +**Sector-wide planes alone solve the bootstrap problem.** + +| Configuration | Median LCA | Consumer Time | Cloud Cost | +|--------------|------------|---------------|------------| +| **Sector planes** (this proposal) | h=33 | ~15 minutes | ~$0.09 | +| Original HJ design (point entry) | h=84 | ~10¹¹ years | ~$50,000+ | +| **Improvement** | **51 bits easier** | **10¹⁴× faster** | **500,000× cheaper** | + +This demonstrates that the geometric insight (sector matching vs point matching) is what solves the bootstrap problem. Future work can layer additional optimizations on top. + +### Total Cyberspace Coverage + +| Metric | Value | +|--------|-------| +| Total coord256 space | 2²⁵⁶ ≈ 1.16×10⁷⁷ points | +| Total sector space (85-bit axes) | 2²⁵⁵ ≈ 5.8×10⁷⁶ sectors | +| HJ coverage (2026) | 2.8M / 5.8×10⁷⁶ = **4.8×10⁻⁷¹** (vanishingly sparse) | +| Interpretation | HJs are **vanishingly sparse**—they don't "cover" space, they provide strategic waypoints | + +**Key insight:** Cyberspace doesn't "collapse" as HJ density increases. It transitions from **impossible** → **nation-state only** → **cloud-feasible** → **consumer-accessible**. The spatial structure remains; only accessibility changes. + +--- + +## Events Specification + +### Block Anchor Events (Existing, Unchanged) + +**Kind:** 321 (CSEP-321) + +Existing block anchor events remain valid. No changes required. + +### Hyperjump Entry Announcement (New) + +**Kind:** 33340 (CSEP-33340) +**Purpose:** Signal that an avatar has reached a hyperjump sector-plane and is now on the HJ network + +**Required tags:** +- `A`: `["A", "hyperjump_entry"]` +- `e`: `["e", "", "", "previous"]` +- `c`: `["c", ""]` (coordinate on the entry plane) +- `HJ`: `["HJ", ""]` (the target HJ being entered) +- `axis`: `["axis", "X"|"Y"|"Z"]` (which plane was used) + +**Validation:** +1. Verify previous event was a valid sidestep to a plane coordinate +2. Verify the plane coordinate matches the target HJ on the specified axis: `sector(plane_coord_axis) == sector(HJ_axis)` +3. If sector doesn't match, reject + +--- + +## Security Considerations + +### Sector Entry Does Not Reveal More Information + +Knowing an avatar is "on the X-plane of HJ H" reveals only that their X sector equals H's X sector. Their Y and Z sectors (and all Gibson-level precision) remain hidden. This is strictly less information than revealing the full 3D point. + +### Directional Commitment Prevents Free Teleportation + +By binding the commitment cost to the XOR distance between specific (from, to) pairs, the protocol prevents: +- **Reuse:** Commitment is single-use +- **Amortization:** Can't "build up" credit for long hops +- **Distance cheating:** Far hops cost more, always + +### Backward Compatibility + +- Existing hyperjump coordinates (merkle roots) are unchanged +- Existing `kind=321` block anchor events remain valid +- Old clients that don't support sector entry can still use **point entry** (3D hop)—it just costs vastly more +- Sector entry is opt-in and detected by validators + +--- + +## Open Questions for Discussion + +1. **Commitment height formula:** Current proposal uses popcount of high 128 bits of XOR difference. Alternatives? + - Full Hamming distance / 4 + - LCA height of (from, to) coordinates (but this requires knowing both points upfront, which is circular) + - Precomputed distance tier table + +2. **"Welcome HJ" for new spawns?** A predictable low-cost entry point (e.g., derived from genesis block) could help onboard users. But this introduces a "central" point, which may violate decentralization ethos. + +3. **Route discovery:** Should clients have built-in graph routing for multi-hop journeys, or should this be left to third-party tools? + +4. **Bitcoin reorg handling:** Should implementations track Bitcoin finality depth (e.g., 6 confirmations) before accepting HJs from new blocks? + +--- + +## Implementation Checklist + +- [ ] Community review and feedback on this draft +- [ ] Finalize directional commitment formula (open question #1) +- [ ] Update DECK-0001 with approved changes +- [ ] Add sector-based HJ queries to cyberspace-cli (filter by sector, not exact coordinate) +- [ ] Add commitment computation to hyperjump validation +- [ ] Create `kind=33340` event handler +- [ ] Update tests for new validation rules +- [ ] Write migration guide for existing clients + +--- + +*This DECK draft is for community review. Comments welcome via GitHub issues or Nostr DM to @arkin0x.* + +--- + +## Appendix: Mathematical Derivation + +### Expected LCA for Sector Matching + +Given: +- Sector space: S = 2⁵⁵ sectors per axis +- N target sectors (from HJs): N = blocks × 3 = 2.8M +- Random spawn position + +**Probability that at least one target shares ≥k high-order bits with spawn:** + +P(match) = 1 - P(all N targets have < k matching) + = 1 - (1 - 2^(-k))^N + +For median case (P = 0.5): +0.5 = 1 - (1 - 2^(-k))^N +(1 - 2^(-k))^N = 0.5 +1 - 2^(-k) = 0.5^(1/N) +2^(-k) = 1 - 0.5^(1/N) + +For large N, using Taylor approximation: +2^(-k) ≈ ln(2) / N +k ≈ log₂(N) - log₂(ln(2)) +k ≈ log₂(N) + 0.53 + +With N = 2.8M: +k ≈ log₂(2.8×10⁶) + 0.53 +k ≈ 21.4 + 0.53 +k ≈ 22 bits matching (median, one axis) + +**For best-of-3 axes:** +P(best LCA ≤ h) = 1 - P(all 3 axes have LCA > h) + = 1 - (1 - P(one axis has LCA ≤ h))³ + +Solving for median (CDF = 0.5): +Median LCA ≈ 33 bits + +This matches our empirical calculations. + From da9738e66207e75a7b5009741eb11cfeb07db5e2 Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 19:47:27 -0500 Subject: [PATCH 06/11] Clean up and rename DECK-0001 --- decks/DECK-0001-plane-shadow-v2.md.orig | 339 ------------------ decks/DECK-0001-plane-shadow-v2.md.rej | 32 -- ...try-v2.md => DECK-0001-v2-sector-entry.md} | 0 3 files changed, 371 deletions(-) delete mode 100644 decks/DECK-0001-plane-shadow-v2.md.orig delete mode 100644 decks/DECK-0001-plane-shadow-v2.md.rej rename decks/{DECK-0001-sector-entry-v2.md => DECK-0001-v2-sector-entry.md} (100%) diff --git a/decks/DECK-0001-plane-shadow-v2.md.orig b/decks/DECK-0001-plane-shadow-v2.md.orig deleted file mode 100644 index 12d243b..0000000 --- a/decks/DECK-0001-plane-shadow-v2.md.orig +++ /dev/null @@ -1,339 +0,0 @@ -# DECK-0001 (Draft v2): Plane-Based Hyperjump Access with Shadow Derivation - -**DECK:** 0001 -**Title:** Plane-Based Hyperjump Access with Shadow Derivation -**Status:** Proposal (supersedes 2026-02-28 draft) -**Created:** 2026-04-08 -**Author:** Arkinox -**Requires:** `CYBERSPACE_V2.md` v2.x - ---- - -## Abstract - -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 two mechanisms: - -1. **Plane-based entry**: Each hyperjump defines three 2D entry planes (one per axis). Avatars can enter by reaching *any* point on one plane, reducing the sidestep from 3D (h≈84) to 1D (h≈57-63). - -2. **Shadow hyperjump derivation**: Each base hyperjump coordinate can be iteratively hashed to derive "shadow" hyperjumps at exponentially increasing entry cost. This multiplies effective HJ density by ~60x, further reducing entry LCA to h≈50-57. - -**Result:** With ~940K Bitcoin block HJs + 60x shadow derivation = **56M effective plane HJs**, the entry cost drops from ~$50,000 cloud compute to **~$800**, enabling consumer access within a 1-year budget. - ---- - -## Layer Analysis (Math / Protocol / Social) - -### Mathematical Layer - -The Cantor pairing tree's **decomposition invariant** (Property 5) proves that *every* path between two points contains at least one hop with LCA ≥ the bit position where they differ. This is absolute for movement within the Cantor metric. - -**However**, plane-based entry does NOT violate this theorem. It changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D plane where *one* coordinate matches. The LCA is computed on a **single axis**, not all three. - -- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 -- **1D plane entry:** LCA = min(LCA_x, LCA_y, LCA_z) ≈ 57-63 (best of 3 axes) - -This is not a cheat—it's exploiting the geometric fact that a plane has lower dimensionality than a point in 3D space. The theorem still holds *within* each dimension; we're simply choosing the cheapest dimension. - -Shadow derivation uses SHA256 as a deterministic expansion function. Each iteration produces a new pseudo-random coordinate. The entry cost doubles per iteration (2^N), creating a natural economic tier system. - -### Protocol Layer - -The protocol must define: -- How plane entry is validated (prove you're on the plane) -- How shadow HJs are derived and verified -- How inter-hyperjump travel cost is computed (the **hyperjump-cost problem**) - -Critically, **exit** from a hyperjump always occurs at the exact merkle-root coordinate. This preserves spatial meaning and prevents planes from being "free teleportation." - -### Social Layer - -Plane-based entry democratizes access. Without it, only entities with nation-state resources could reach *any* hyperjump. With it, consumers spending ~$1,000 on cloud compute can reach their first HJ within a year of parallel computation. - -This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no one**. The thermodynamic cost remains—it's just amortized over a larger set of entry points. - ---- - -## Specification - -### 1. Plane-Based Entry (Normative) - -#### Definition - -For a hyperjump at coordinate **H = (Hx, Hy, Hz, Hp)**, three entry planes are defined: - -- **X-plane**: All coordinates where **X = Hx** (covers (Hx, *, *, *)) -- **Y-plane**: All coordinates where **Y = Hy** (covers (*, Hy, *, *)) -- **Z-plane**: All coordinates where **Z = Hz** (covers (*, *, Hz, *)) - -The plane bit **Hp** is inherited from the hyperjump coordinate (plane 0 = dataspace, plane 1 = ideaspace). - -#### Entry Validation - -To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate on that plane. This is done via a standard **sidestep movement event** (`A=sidestep`) with: - -- Destination coordinate **D** where the chosen axis matches the hyperjump's axis value -- Standard sidestep Merkle proof for all three axes - -Example (entering via Y-plane): -```json -{ - "kind": 3333, - "tags": [ - ["A", "sidestep"], - ["C", ""], // Y value matches HJ's Y - ["proof", ""], - ["Y_matches_HJ", "true"] // Optional hint for validators - ] -} -``` - -After reaching the plane, the avatar publishes a **hyperjump entry event** (new event kind, see below) to signal they are now "on" the hyperjump network. - -#### Exit Behavior - -When exiting a hyperjump (after a `A=hyperjump` action), the avatar **always** arrives at the exact merkle-root coordinate **(Hx, Hy, Hz, Hp)**. The plane entry advantage applies only to *entering*, not exiting. - -This ensures: -- Spatial meaning is preserved (you can't "teleport around" distance) -- Navigation FROM the exit point to a final destination still costs work -- The plane mechanism doesn't collapse locality - ---- - -### 2. Shadow Hyperjump Derivation (Normative) - -#### Derivation Function - -Given a base hyperjump coordinate **H₀** (from Bitcoin block merkle root), shadow coordinates are derived iteratively: - -``` -H₀ = merkle_root_as_coord256 -H₁ = SHA256(H₀) // reinterpret 32-byte hash as coord256 -H₂ = SHA256(H₁) -... -Hₙ = SHA256(Hₙ₋₁) -``` - -Each **Hₙ** is a valid **shadow hyperjump** at **iteration depth N**. - -#### Entry Cost - -Entering a shadow hyperjump at depth **N** costs **2^N** times the base sidestep cost. This is enforced by requiring the avatar to include the **iteration count N** in their entry proof, and validators recompute the expected LCA penalty. - -Practical limits: -- **N ≤ 20**: Consumer-feasible (2²⁰ ≈ 1M multiplier, adds ~20 to LCA) -- **N ≤ 40**: Cloud-feasible (~$100-500) -- **N ≤ 60**: Nation-state feasible (~$10,000+) -- **N > 60**: Prohibitively expensive - -Implementations SHOULD reject shadow entries with N > 60. - -#### Validation - -Block anchor events MUST include an optional **shadow depth tag**: -- `shadow` tag: `["shadow", ""]` where `` is a base-10 integer (0 for base HJ, 1+ for shadows) - -If omitted, depth is assumed to be 0. - -To validate a shadow hyperjump entry: -1. Derive Hₙ from base H₀ using N iterations -2. Verify the avatar's destination coordinate matches Hₙ (or is on Hₙ's plane) -3. Apply entry cost multiplier 2^N to the sidestep proof validation - ---- - -### 3. Hyperjump-Cost Problem (Proposed Specification) - -#### The Problem - -The current DECK-0001 defines hyperjump as **free teleportation** between any two hyperjumps. This creates a graph where all nodes are equidistant (cost=0), which: -- Collapses spatial meaning -- Makes "distance" irrelevant once on the network -- Violates Property 1 (locality) at the protocol layer - -We need a cost function that: -1. Scales with spatial distance (preserves locality) -2. Costs meaningful work (not arbitrary fees) -3. Cannot be reused (no amortization) -4. Is consumer-feasible for reasonable distances - -#### Proposed Solution: Directional Cantor Commitment - -When making a hyperjump from **H_from** to **H_to**, the avatar must compute a **directional Cantor commitment**: - -``` -direction_vector = H_to XOR H_from // 256-bit directional signature -commitment_height = popcount(direction_vector >> 128) // 0-128, based on high bits -commitment = compute_cantor_prefix(direction_vector, commitment_height) -``` - -The **commitment** is a partial Cantor tree computation (not a full hop proof) that: -- Costs 2^commitment_height operations -- Is unique to this specific (from, to) pair -- Cannot be reused for a different destination -- Expires after use (single-use commitment) - -#### Cost Scaling - -| Distance (hamming XOR) | Commitment Height | Compute Time (consumer) | Cloud Cost | -|------------------------|-------------------|-------------------------|------------| -| < 64 bits (nearby) | 8-16 | < 1 second | <$0.01 | -| 64-96 bits (same sector band) | 16-24 | 1 min - 1 hour | $0.01-1 | -| 96-128 bits (cross-sector) | 24-32 | 1 hour - 1 day | $1-10 | -| 128-160 bits (far) | 32-40 | 1 day - 1 week | $10-100 | -| 160-192 bits (very far) | 40-48 | 1 week - 1 month | $100-1000 | -| 192-224 bits (across space) | 48-56 | 1 month - 1 year | $1000-10k | -| > 224 bits (opposite corners) | 56-64 | 1-10 years | $10k-100k | - -This preserves the **graph structure** of the hyperjump network while maintaining spatial locality. Nearby HJs are cheap to reach; distant ones cost more. - -#### Non-Reuse Mechanism - -The commitment includes: -- Previous movement event ID (binds to specific position in chain) -- Timestamp of hyperjump event -- Destination coordinate - -This ensures the commitment is **single-use** and **non-transferable**. Validators reject any hyperjump event where the commitment doesn't match the specific (from, to, timestamp) tuple. - -#### Open Questions - -1. **Should commitment height be continuous or tiered?** Continuous is more precise; tiered is simpler to implement. - -2. **Can commitments be precomputed?** Yes, but they're still single-use. Precomputation is an optimization, not an amortization. - -3. **What prevents farming cheap short hops to "build up" to a long hop?** Nothing—this is intended! Strategic multi-hop routing is a valid use case and mirrors physical transit networks. - -4. **Should there be a maximum commitment height?** Suggest N=64 (same as shadow limit). Beyond that, the hop is effectively impossible for consumers. - ---- - -## Coverage and Accessibility Analysis - -### Assumptions - -- Bitcoin block production: 52,560 blocks/year (~10 min average) -- Current blocks (2026): ~940,000 -- Shadow multiplier: 60x (N ≤ 60 practical limit) -- Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 -- Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` - - 85-bit axis space = 2⁸⁵ sectors - - With 169M plane HJs: LCA ≈ log₂(2⁸⁵ / 1.69×10⁸) ≈ **log₂(2.2×10¹⁷) ≈ 57.5** - -### Spawn-to-HJ LCA Projection (1D, best-of-3 axes) - -| Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | -|------|--------|---------------------|---------|---------------|---------------------------| -| 2026 | 940K | 169M | 57.5 | ~13 years | ~$800 | -| 2031 | 1.2M | 216M | 56.8 | ~8 years | ~$500 | -| 2036 | 1.5M | 270M | 56.2 | ~5 years | ~$350 | -| 2046 | 2.0M | 360M | 55.3 | ~2.5 years | ~$180 | -| 2056 | 2.5M | 450M | 54.6 | ~1.3 years | ~$100 | - -**With Moore's Law (compute doubles every 2.5 years):** - -| Year | Compute Multiplier | Effective LCA Reduction | Time to First HJ | -|------|-------------------|-------------------------|------------------| -| 2026 | 1× | baseline | 13 years / $800 | -| 2031 | 4× | -0.5 | 3.3 years / $200 | -| 2036 | 16× | -1.0 | 0.8 years / $50 | -| 2041 | 64× | -1.5 | **2.5 months / $15** | -| 2046 | 256× | -2.0 | **3 weeks / $4** | - -### Total Cyberspace Coverage - -| Metric | Value | -|--------|-------| -| Total coord256 space | 2²⁵⁶ ≈ 1.16×10⁷⁷ points | -| Total sector space (85-bit axes) | 2²⁵⁵ ≈ 5.8×10⁷⁶ sectors | -| HJ coverage (2026) | 169M / 5.8×10⁷⁶ = **2.9×10⁻⁶⁹** (negligible) | -| Interpretation | HJs are **vanishingly sparse**—they don't "cover" space, they provide strategic waypoints | - -**Key insight:** Cyberspace doesn't "collapse" as HJ density increases. It transitions from **impossible** → **nation-state only** → **cloud-feasible** → **consumer-accessible**. The spatial structure remains; only accessibility changes. - ---- - -## Events Specification - -### New Event Kind: Hyperjump Entry Announcement - -**Kind:** 33340 (CSEP-33340) -**Purpose:** Signal that an avatar has reached a hyperjump plane and is now on the HJ network - -**Required tags:** -- `A`: `["A", "hyperjump_entry"]` -- `e`: `["e", "", "", "previous"]` -- `c`: `["c", ""]` (coordinate on the entry plane) -- `HJ`: `["HJ", ""]` (the target HJ being entered) -- `axis`: `["axis", "X"|"Y"|"Z"]` (which plane was used) - -**Optional tags:** -- `shadow`: `["shadow", ""]` (if entering a shadow HJ) - -**Validation:** -1. Verify previous event was a valid sidestep to a plane coordinate -2. Verify the plane coordinate matches the target HJ on the specified axis -3. If shadow depth > 0, verify entry cost multiplier is applied - ---- - -## Backward Compatibility - -- Existing hyperjump coordinates (merkle roots) are unchanged -- Existing `kind=321` block anchor events remain valid -- Old clients that don't support plane entry can still use **point entry** (3D hop)—it just costs more -- Shadow HJs are opt-in: validators that don't recognize shadow depth=0 only - ---- - -## Security Considerations - -### Plane Entry Does Not Reveal Information - -Knowing an avatar is "on the X-plane of HJ H" reveals only that their X coordinate equals Hx. Their Y and Z coordinates remain hidden. This is strictly less information than revealing the full 3D point. - -### Shadow Derivation Is Trustless - -Anyone can derive shadow HJs from public Bitcoin data. No trusted setup or coordination required. The 2^N cost scaling is mathematical, not policy-based. - -### Directional Commitment Prevents Free Teleportation - -By binding the commitment cost to the XOR distance between specific (from, to) pairs, the protocol prevents: -- **Reuse:** Commitment is single-use -- **Amortization:** Can't "build up" credit for long hops -- **Distance cheating:** Far hops cost more, always - ---- - -## Open Questions for Discussion - -1. **What should the commitment height formula be?** Current proposal uses popcount of high 128 bits. Alternatives: - - Full Hamming distance / 4 - - LCA height of (from, to) coordinates - - Precomputed distance tier table - -2. **Should there be a "welcome HJ" for new spawns?** A predictable low-cost entry point (e.g., derived from genesis block) could help onboard users. But this introduces a "central" point, which may violate decentralization ethos. - -3. **How should clients discover optimal multi-hop routes?** This is a graph routing problem. Should it be built into the CLI, or left to third-party tools? - -4. **What happens if Bitcoin forks or has a deep reorg?** HJs derived from reorged blocks become invalid. Should implementations track Bitcoin finality depth before accepting HJs? - ---- - -## Implementation Checklist - -- [ ] Update DECK-0001 with plane entry spec -- [ ] Add shadow derivation function to cyberspace-cli -- [ ] Implement plane-based HJ queries (filter cache by single axis) -- [ ] Add directional commitment computation to hyperjump validation -- [ ] Create `kind=33340` event handler -- [ ] Update tests for new validation rules -- [ ] Write migration guide for existing clients - ---- - -*This DECK draft is for community review. Comments welcome via GitHub issues or Nostr DM to @arkin0x.* diff --git a/decks/DECK-0001-plane-shadow-v2.md.rej b/decks/DECK-0001-plane-shadow-v2.md.rej deleted file mode 100644 index e2d3a8d..0000000 --- a/decks/DECK-0001-plane-shadow-v2.md.rej +++ /dev/null @@ -1,32 +0,0 @@ ---- DECK-0001-plane-shadow-v2.md -+++ DECK-0001-plane-shadow-v2.md -@@ -61,12 +63,14 @@ This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no - - ### Entry Validation - --To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate on that plane. This is done via a standard **sidestep movement event** (`A=sidestep`) with: -+To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. -+ -+This is done via a standard **sidestep movement event** (`A=sidestep`) with: - - - Destination coordinate **D** where `sector(chosen_axis) = sector(HJ_axis)` - - Standard sidestep Merkle proof for all three axes - --Example (entering via Y-plane): -+Example (entering via Y-plane, matching sector not exact coordinate): - ```json - { - "kind": 3333, -@@ -166,10 +170,10 @@ Validators reject any hyperjump event where the commitment doesn't match the spe - - ### Coverage and Accessibility Analysis - - ### Assumptions - --- Bitcoin block production: 52,560 blocks/year (~10 min average) -+- Bitcoin block production: 52,560 blocks/year (~10 min average) - - Current blocks (2026): ~940,000 - - Shadow multiplier: 60x (N ≤ 60 practical limit) --- Effective plane HJs: blocks × 3 planes × 60 shadows = **169M** by 2026 -+- Effective plane HJs: blocks × 3 sector-planes × 60 shadows = **169M** by 2026 - - Average 1D LCA gap formula: `LCA ≈ log₂(total_space / effective_HJs)` diff --git a/decks/DECK-0001-sector-entry-v2.md b/decks/DECK-0001-v2-sector-entry.md similarity index 100% rename from decks/DECK-0001-sector-entry-v2.md rename to decks/DECK-0001-v2-sector-entry.md From 06a536b2f2f03ec35a8a07c1c10b58865a6a0e84 Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 19:51:44 -0500 Subject: [PATCH 07/11] Add PR description reference --- decks/DECK-0001-v2-sector-entry.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/decks/DECK-0001-v2-sector-entry.md b/decks/DECK-0001-v2-sector-entry.md index ce570a8..77e12e4 100644 --- a/decks/DECK-0001-v2-sector-entry.md +++ b/decks/DECK-0001-v2-sector-entry.md @@ -345,3 +345,19 @@ Median LCA ≈ 33 bits This matches our empirical calculations. + +--- + +## PR Description (for reference) + +**Title:** DECK-0001 v2: Sector-based hyperjump entry planes + +**Summary:** +Each HJ has 3 sector-wide entry planes (1 sector thick). Match ONE axis sector (55 bits) instead of exact Gibson coordinate (85 bits). Entry cost: h≈84 → h≈33, enabling consumer access in ~15 minutes ($0.09 cloud). + +**Open Questions:** +1. Commitment height formula? (popcount vs alternatives) +2. Welcome HJ for spawns? +3. Route discovery method? +4. Bitcoin reorg handling? + From 0ff2fb29e038fadb53c8074886d9ca73bb18e9c7 Mon Sep 17 00:00:00 2001 From: XOR Date: Wed, 8 Apr 2026 20:07:40 -0500 Subject: [PATCH 08/11] Correct sector extraction: coordinates are interleaved MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix critical error: sector extraction requires de-interleaving first per CYBERSPACE_V2.md §2.2. Added proper definition with O(85) bit-op reference implementation. --- decks/DECK-0001-v2-sector-entry.md | 33 +++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/decks/DECK-0001-v2-sector-entry.md b/decks/DECK-0001-v2-sector-entry.md index 77e12e4..17daf30 100644 --- a/decks/DECK-0001-v2-sector-entry.md +++ b/decks/DECK-0001-v2-sector-entry.md @@ -68,7 +68,38 @@ For a hyperjump at coordinate **H = (Hx, Hy, Hz, Hp)**, three entry planes are d Each plane is **1 sector thick** (2³⁰ Gibsons). The plane bit **Hp** is inherited from the hyperjump coordinate (plane 0 = dataspace, plane 1 = ideaspace). -Sector extraction: `sector(coord) = coord >> 30` (high 55 bits) +#### Sector Extraction (Normative) + +Coordinates are **interleaved** per `CYBERSPACE_V2.md` §2.2 (bit pattern: `XYZXYZXYZ...P`). To extract a sector: + +1. **De-interleave** the coord256 to extract the 85-bit axis value (X, Y, or Z) +2. **Extract high 55 bits**: `sector_value = axis_value >> 30` + +Reference implementation: +```python +def extract_axis(coord256: int, axis: str) -> int: + """De-interleave coord256 to get 85-bit axis value.""" + if axis == 'X': + shift = 3 # X bits at positions 3, 6, 9, ... + elif axis == 'Y': + shift = 2 # Y bits at positions 2, 5, 8, ... + elif axis == 'Z': + shift = 1 # Z bits at positions 1, 4, 7, ... + + result = 0 + for i in range(85): + bit_pos = shift + (3 * i) + if coord256 & (1 << bit_pos): + result |= (1 << i) + return result + +def sector(coord256: int, axis: str) -> int: + """Extract 55-bit sector value from an axis.""" + axis_value = extract_axis(coord256, axis) + return axis_value >> 30 # High 55 bits of 85-bit axis +``` + +**Complexity:** De-interleaving is O(85) bit operations — negligible compared to sidestep computation. #### Entry Validation From 85bd9d664474ff652dfe84aff926d22700626e70 Mon Sep 17 00:00:00 2001 From: XOR Date: Tue, 14 Apr 2026 20:46:31 -0500 Subject: [PATCH 09/11] DECK-0001 v2: Sector-based hyperjump entry (shadow HJs removed) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Replace HJ spec with sector-plane entry design - Entry LCA: h≈84 → h≈33 (51 bits easier = 10¹⁴× cheaper) - Consumer access: ~15 minutes, ~/usr/bin/bash.09 cloud cost - Shadow HJs removed as unnecessary (sector planes alone sufficient) - Add directional Cantor commitment for inter-HJ travel cost - Preserve locality: exit at exact 3D coordinate, not plane - Three-layer analysis: mathematical, protocol, social See DECK-0001-v2-sector-entry.md for full draft and mathematical derivation. --- decks/DECK-0001-hyperjumps.md | 521 ++++++++++++++++++++++++---------- 1 file changed, 375 insertions(+), 146 deletions(-) diff --git a/decks/DECK-0001-hyperjumps.md b/decks/DECK-0001-hyperjumps.md index e42337e..17daf30 100644 --- a/decks/DECK-0001-hyperjumps.md +++ b/decks/DECK-0001-hyperjumps.md @@ -1,165 +1,394 @@ -# DECK-0001: Hyperjumps (Bitcoin block Merkle-root teleports) +# DECK-0001 (Draft v2): Sector-Based Hyperjump Entry -DECK: 0001 -Title: Hyperjumps (Bitcoin block Merkle-root teleports) -Status: Draft -Created: 2026-02-28 -Last updated: 2026-02-28 -Requires: `CYBERSPACE_V2.md` +**DECK:** 0001 +**Title:** Sector-Based Hyperjump Entry +**Status:** Proposal (supersedes 2026-02-28 draft) +**Created:** 2026-04-08 +**Author:** Arkinox +**Requires:** `CYBERSPACE_V2.md` v2.x + +--- ## Abstract -This DECK defines **hyperjumps**: a zero-movement-proof teleport mechanism between special coordinates derived from Bitcoin blocks. -A Bitcoin block’s Merkle root is treated as a thermodynamically "paid for" random coordinate in Cyberspace. By publishing these blocks as Nostr events (block anchor events), avatars can visit a growing network of unpredictable but far-reaching transit points. +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**. + +--- + +## Layer Analysis (Math / Protocol / Social) + +### Mathematical Layer + +The Cantor pairing tree's **decomposition invariant** (Property 5) proves that *every* path between two points contains at least one hop with LCA ≥ the bit position where they differ. This is absolute for movement within the Cantor metric. + +**However**, sector-plane entry changes the *target*: instead of reaching a 3D point (Hx, Hy, Hz), you reach a 2D sector-slab where *one* axis sector matches. The LCA is computed on the **sector bits** (55 bits), not the full Gibson value (85 bits). + +- **3D point entry:** LCA = max(LCA_x, LCA_y, LCA_z) ≈ 84 (full 85-bit Gibson space) +- **1D sector-plane entry:** LCA ≈ log₂(2⁵⁵ / HJs) ≈ 33 (55-bit sector space) +- **Improvement:** 51 bits easier → 2⁵¹ ≈ 2×10¹⁵ times cheaper + +This is not a cheat—it's exploiting the geometric fact that matching a sector (1 in 2³⁰ Gibsons) is vastly cheaper than matching an exact Gibson coordinate. The theorem still holds *within* each dimension; we're simply lowering the precision requirement for entry. + +### Protocol Layer + +The protocol defines: +- How sector planes are specified (1 sector thick per axis) +- How plane entry is validated (prove sector match, not Gibson match) +- How inter-hyperjump travel cost is computed (directional Cantor commitment) + +Critically, **exit** from a hyperjump always occurs at the exact merkle-root coordinate. This preserves spatial meaning and prevents planes from being "free teleportation." + +### Social Layer + +Sector-plane entry democratizes access. Without it, only entities with nation-state resources could reach *any* hyperjump. With it, consumers spending ~15 minutes of computation (~$0.09 cloud) can reach their first HJ. -## Terms -- Hyperjump: a protocol-defined teleport action between two hyperjump coordinates that reuses Bitcoin proof-of-work rather than requiring a Cyberspace v2 movement proof. -- Hyperjump coordinate: a coord256 derived deterministically from a Bitcoin block’s Merkle root. -- Block anchor event: a Nostr event that binds Bitcoin block identifiers to the corresponding hyperjump coordinate so clients can discover nearby hyperjumps via Nostr queries. +This aligns with Cyberspace's ethos: **infrastructure for everyone, owned by no one**. The thermodynamic cost remains—it's just amortized over a larger set of entry points. + +--- ## Specification -### Hyperjump coordinate derivation (normative) -Given a Bitcoin block’s Merkle root (`merkle_root`): -- Let `coord_hex = merkle_root` (32 bytes, lowercase hex, no `0x` prefix). -- Let `coord256 = int(coord_hex, 16)`. -- The hyperjump coordinate is `coord256`, interpreted as a Cyberspace coordinate per `CYBERSPACE_V2.md` §2. - -Notes: -- This uses the Merkle root as presented in standard big-endian hex form (as commonly shown in block explorers). Implementations MUST agree on this endianness. -- The plane bit is the least significant bit of `coord256` (per `CYBERSPACE_V2.md` §2.1). Therefore hyperjumps may exist in either plane. - -### Block anchor events (hyperjump publishing) -Hyperjump coordinates are discoverable conveniently via Nostr by querying **block anchor events** (kind 321) that bind Bitcoin block identifiers to their Merkle-root-derived coordinate. The accuracy of block anchor events on nostr is not guaranteed, so you may want to publish your own or derive block anchors from your own bitcoin node. - -#### Event kind -- Block anchor events: `kind = 321` - -#### Required tags (normative) -Block anchor events MUST include: -- `C` tag: `["C", ""]` where `` is the Merkle-root-derived hyperjump coordinate -- sector tags: `X`, `Y`, `Z`, `S` (per `CYBERSPACE_V2.md` §3), computed from the hyperjump coordinate -- `B` tag: `["B", ""]` where `` is the Bitcoin block height (base-10 string) -- `H` tag: `["H", ""]` (32-byte lowercase hex string) -- `P` tag: `["P", ""]` (32-byte lowercase hex string) - -Block anchor events SHOULD include: -- `net` tag: `["net", ""]` where `` is one of `mainnet`, `testnet`, `signet`, `regtest`. - - If omitted, implementations SHOULD assume `mainnet`. -- `N` tag: `["N", ""]` once the next block is known - -#### Validation of anchor events (normative) -To verify a block anchor event as valid for hyperjumping, an implementation MUST verify that: -1. Its `C` tag matches the Merkle root of the block at height `B` on the Bitcoin network the client is using (or the network specified by the anchor event’s `net` tag, if present). -2. Its `H` tag is the corresponding block hash. -3. Its `P` tag is the corresponding previous block hash. - -How an implementation performs this validation is out of scope (full node, headers-only/SPV, trusted checkpoints, etc.), but the resulting `(height, block_hash, merkle_root)` bindings MUST match Bitcoin consensus for the selected network. - -### Hyperjump movement events -A hyperjump action is represented as a movement event (`kind=3333`) in the avatar’s movement chain (`CYBERSPACE_V2.md` §6) with action tag `["A", "hyperjump"]`. - -#### Hyperjump movement event (normative) -Required tags: -- `A` tag: `["A", "hyperjump"]` -- `e` genesis: `["e", "", "", "genesis"]` -- `e` previous: `["e", "", "", "previous"]` -- `c` tag: `["c", ""]` -- `C` tag: `["C", ""]` (the destination hyperjump coordinate) -- `B` tag: `["B", ""]` where `` is the destination Bitcoin block height (base-10 string) -- sector tags: `X`, `Y`, `Z`, `S` (per `CYBERSPACE_V2.md` §3), computed from the destination coordinate - -Optional tags: -- `net` tag: `["net", ""]` where `` is one of `mainnet`, `testnet`, `signet`, `regtest`. - - If omitted, implementations SHOULD assume `mainnet`. -- `e` hyperjump-to: `["e", "", "", "hyperjump_to"]` (a `kind=321` anchor event for the destination block) -- `e` hyperjump-from: `["e", "", "", "hyperjump_from"]` (a `kind=321` anchor event for the origin block) - -Prohibited tags: -- Hyperjump events MUST NOT include a `proof` tag. (They are not validated using `CYBERSPACE_V2.md` §5 / §6.5.) - -Behavioral constraints: -- `prev_coord_hex` MUST be a valid hyperjump coordinate (i.e., it MUST correspond to the `C` tag of at least one valid block anchor event). -- `` MUST equal the hyperjump coordinate for block height `` on the selected Bitcoin network. - -Non-normative note: -- This design intentionally requires a normal hop (`CYBERSPACE_V2.md` §6.4) to enter the hyperjump network (i.e., to move onto a hyperjump coordinate in the first place). - -#### Hyperjump verification summary (normative) -To verify a hyperjump event: -1. Verify it is `kind=3333` and includes `["A","hyperjump"]`. -2. Verify its chain structure (`e` genesis + `e` previous) as in `CYBERSPACE_V2.md` §6. -3. Verify that the previous movement event’s `C` tag equals this event’s `c` tag. -4. Verify that `c` is a valid hyperjump coordinate by resolving at least one valid block anchor event with `C=c`. -5. Resolve the destination block height from the event’s `B` tag and derive the expected destination coordinate using the Bitcoin network implied by the event’s `net` tag (or `mainnet` if omitted). -6. Accept iff the expected destination coordinate equals the event’s `C`. - -Optional shortcut (non-normative): -- If `hyperjump_to` is present, the verifier may instead validate that referenced anchor event and compare its `C` directly. - -## Example (non-normative) -This example shows: -1. A published block anchor event (`kind=321`) that makes a hyperjump coordinate discoverable. -2. A normal hop (`A=hop`) that moves onto a hyperjump coordinate (requires a `proof` tag). -3. A hyperjump (`A=hyperjump`) that moves from one hyperjump coordinate to another by choosing a destination block height (no `proof` tag). - -Example block anchor event for Bitcoin block height `1606` (abridged fields; tags shown in full): -```json -{ - "kind": 321, - "content": "Block 1606", - "tags": [ - ["C", "744193479b55674c02dec4ed73581eafbd7e2db03442360c9c34f9394031ee8f"], - ["X", "11846810334975873"], - ["Y", "19088986011188665"], - ["Z", "27231467915017080"], - ["S", "11846810334975873-19088986011188665-27231467915017080"], - ["H", "000000005d388d74f4b9da705c4a977b5aa53f88746f6286988f9f139dba2a99"], - ["P", "00000000ba96f7cee624d66be83099df295a1daac50dd99e4315328aa7d43e77"], - ["N", "00000000fc33b76de0621880e0cad2f6bd24e48250c461258dc8c6a6a3253c7a"], - ["B", "1606"] - ] -} +### 1. Sector-Based Entry Planes (Normative) + +#### Definition + +For a hyperjump at coordinate **H = (Hx, Hy, Hz, Hp)**, three entry planes are defined: + +- **X-plane**: All coordinates where **sector(X) = sector(Hx)** (covers all (X, *, *, *) matching the sector) +- **Y-plane**: All coordinates where **sector(Y) = sector(Hy)** (covers all (*, Y, *, *) matching the sector) +- **Z-plane**: All coordinates where **sector(Z) = sector(Hz)** (covers all (*, *, Z, *) matching the sector) + +Each plane is **1 sector thick** (2³⁰ Gibsons). The plane bit **Hp** is inherited from the hyperjump coordinate (plane 0 = dataspace, plane 1 = ideaspace). + +#### Sector Extraction (Normative) + +Coordinates are **interleaved** per `CYBERSPACE_V2.md` §2.2 (bit pattern: `XYZXYZXYZ...P`). To extract a sector: + +1. **De-interleave** the coord256 to extract the 85-bit axis value (X, Y, or Z) +2. **Extract high 55 bits**: `sector_value = axis_value >> 30` + +Reference implementation: +```python +def extract_axis(coord256: int, axis: str) -> int: + """De-interleave coord256 to get 85-bit axis value.""" + if axis == 'X': + shift = 3 # X bits at positions 3, 6, 9, ... + elif axis == 'Y': + shift = 2 # Y bits at positions 2, 5, 8, ... + elif axis == 'Z': + shift = 1 # Z bits at positions 1, 4, 7, ... + + result = 0 + for i in range(85): + bit_pos = shift + (3 * i) + if coord256 & (1 << bit_pos): + result |= (1 << i) + return result + +def sector(coord256: int, axis: str) -> int: + """Extract 55-bit sector value from an axis.""" + axis_value = extract_axis(coord256, axis) + return axis_value >> 30 # High 55 bits of 85-bit axis ``` -Example movement hop onto that hyperjump coordinate (requires standard hop validation): +**Complexity:** De-interleaving is O(85) bit operations — negligible compared to sidestep computation. + +#### Entry Validation + +To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. + +This is done via a standard **sidestep movement event** (`A=sidestep`) with: + +- Destination coordinate **D** where `sector(chosen_axis) = sector(HJ_axis)` +- Standard sidestep Merkle proof for all three axes + +Example (entering via Y-plane): ```json { "kind": 3333, - "content": "", "tags": [ - ["A", "hop"], - ["e", "", "", "genesis"], - ["e", "", "", "previous"], - ["c", ""], - ["C", "744193479b55674c02dec4ed73581eafbd7e2db03442360c9c34f9394031ee8f"], - ["proof", ""], - ["X", "11846810334975873"], - ["Y", "19088986011188665"], - ["Z", "27231467915017080"], - ["S", "11846810334975873-19088986011188665-27231467915017080"] + ["A", "sidestep"], + ["C", ""], // sector(Y) matches HJ's sector(Y) + ["proof", ""] ] } ``` -Example hyperjump from height `1606` to height `1602` (no `proof` tag): -```json -{ - "kind": 3333, - "content": "", - "tags": [ - ["A", "hyperjump"], - ["e", "", "", "genesis"], - ["e", "", "", "previous"], - ["c", "744193479b55674c02dec4ed73581eafbd7e2db03442360c9c34f9394031ee8f"], - ["C", "42adcf1bc1976b02f66d5a33ab41946e7152f9b7ec08046a51625d443092e8cb"], - ["B", "1602"], - ["e", "", "", "hyperjump_from"], - ["e", "", "", "hyperjump_to"], - ["X", "6397583792183907"], - ["Y", "22152908496923134"], - ["Z", "5507206459976287"], - ["S", "6397583792183907-22152908496923134-5507206459976287"] - ] -} +After reaching the plane, the avatar publishes a **hyperjump entry announcement** (kind 33340, see below) to signal they are now "on" the hyperjump network. + +#### Exit Behavior + +When exiting a hyperjump (after a `A=hyperjump` action), the avatar **always** arrives at the exact merkle-root coordinate **(Hx, Hy, Hz, Hp)**. The sector-plane advantage applies only to *entering*, not exiting. + +This ensures: +- Spatial meaning is preserved (you can't "teleport around" distance) +- Navigation FROM the exit point to a final destination still costs work +- The plane mechanism doesn't collapse locality + +--- + +### 2. Hyperjump-Cost Problem (Normative) + +#### The Problem + +The original DECK-0001 defines hyperjump as **free teleportation** between any two hyperjumps. This creates a graph where all nodes are equidistant (cost=0), which: +- Collapses spatial meaning +- Makes "distance" irrelevant once on the network +- Violates Property 1 (locality) at the protocol layer + +We need a cost function that: +1. Scales with spatial distance (preserves locality) +2. Costs meaningful work (not arbitrary fees) +3. Cannot be reused (no amortization) +4. Is consumer-feasible for reasonable distances + +#### Proposed Solution: Directional Cantor Commitment + +When making a hyperjump from **H_from** to **H_to**, the avatar must compute a **directional Cantor commitment**: + +``` +direction_vector = H_to XOR H_from // 256-bit directional signature +commitment_height = popcount(direction_vector >> 128) // 0-128, based on high bits +commitment = compute_cantor_prefix(direction_vector, commitment_height) ``` + +The **commitment** is a partial Cantor tree computation (not a full hop proof) that: +- Costs 2^commitment_height operations +- Is unique to this specific (from, to) pair +- Cannot be reused for a different destination +- Expires after use (single-use commitment) + +#### Cost Scaling + +| Distance (hamming XOR on high 128 bits) | Commitment Height | Compute Time (consumer) | Cloud Cost | +|----------------------------------------|-------------------|-------------------------|------------| +| < 32 bits (nearby) | 8-16 | < 1 second | <$0.01 | +| 32-48 bits (same sector band) | 16-24 | 1 min - 1 hour | $0.01-1 | +| 48-64 bits (cross-sector) | 24-32 | 1 hour - 1 day | $1-10 | +| 64-80 bits (far) | 32-40 | 1 day - 1 week | $10-100 | +| 80-96 bits (very far) | 40-48 | 1 week - 1 month | $100-1000 | +| 96-112 bits (across space) | 48-56 | 1 month - 1 year | $1000-10k | +| > 112 bits (opposite corners) | 56-64 | 1-10 years | $10k-100k | + +This preserves the **graph structure** of the hyperjump network while maintaining spatial locality. Nearby HJs are cheap to reach; distant ones cost more. + +#### Non-Reuse Mechanism + +The commitment includes: +- Previous movement event ID (binds to specific position in chain) +- Timestamp of hyperjump event +- Destination coordinate + +This ensures the commitment is **single-use** and **non-transferable**. Validators reject any hyperjump event where the commitment doesn't match the specific (from, to, timestamp) tuple. + +#### Open Questions + +1. **Should commitment height be continuous or tiered?** Continuous is more precise; tiered is simpler to implement. + +2. **Can commitments be precomputed?** Yes, but they're still single-use. Precomputation is an optimization, not an amortization. + +3. **What prevents farming cheap short hops to "build up" to a long hop?** Nothing—this is intended! Strategic multi-hop routing is a valid use case and mirrors physical transit networks. + +4. **Should there be a maximum commitment height?** Suggest N=64 (reasonable upper bound). Beyond that, the hop is effectively impossible for consumers. + +--- + +## Coverage and Accessibility Analysis + +### Assumptions + +- Bitcoin block production: 52,560 blocks/year (~10 min average) +- Current blocks (2026): ~940,000 +- Planes per HJ: 3 (X, Y, Z) +- Effective plane HJs: blocks × 3 planes = **2.8M** by 2026 +- Average 1D LCA gap formula for sector matching: `LCA ≈ log₂(2⁵⁵ / effective_HJs)` + - **55-bit sector space** = 2⁵⁵ sectors per axis (plane is 1 sector = 2³⁰ Gibsons thick) + - With 2.8M plane HJs: LCA ≈ log₂(2⁵⁵ / 2.8×10⁶) ≈ **log₂(1.3×10¹⁰) ≈ 33.6** + +### Spawn-to-HJ LCA Projection (1D sector match, best-of-3 axes) + +| Year | Blocks | Effective Plane HJs | Avg LCA | Consumer Time | Cloud Cost ($0.15/hr GPU) | +|------|--------|---------------------|---------|---------------|---------------------------| +| 2026 | 940K | 2.8M | 33.0 | ~15 minutes | ~$0.09 | +| 2031 | 1.2M | 3.6M | 32.8 | ~13 minutes | ~$0.07 | +| 2036 | 1.5M | 4.5M | 32.7 | ~12 minutes | ~$0.06 | +| 2046 | 2.0M | 6.0M | 32.5 | ~10 minutes | ~$0.05 | +| 2056 | 2.5M | 7.5M | 32.4 | ~9 minutes | ~$0.04 | + +**With Moore's Law (compute doubles every 2.5 years):** + +| Year | Compute Multiplier | Time to First HJ | Cloud Cost | +|------|-------------------|------------------|------------| +| 2026 | 1× | ~15 minutes | ~$0.09 | +| 2031 | 4× | ~4 minutes | ~$0.02 | +| 2036 | 16× | ~1 minute | ~$0.005 | + +### Blocks-Only Analysis + +**Sector-wide planes alone solve the bootstrap problem.** + +| Configuration | Median LCA | Consumer Time | Cloud Cost | +|--------------|------------|---------------|------------| +| **Sector planes** (this proposal) | h=33 | ~15 minutes | ~$0.09 | +| Original HJ design (point entry) | h=84 | ~10¹¹ years | ~$50,000+ | +| **Improvement** | **51 bits easier** | **10¹⁴× faster** | **500,000× cheaper** | + +This demonstrates that the geometric insight (sector matching vs point matching) is what solves the bootstrap problem. Future work can layer additional optimizations on top. + +### Total Cyberspace Coverage + +| Metric | Value | +|--------|-------| +| Total coord256 space | 2²⁵⁶ ≈ 1.16×10⁷⁷ points | +| Total sector space (85-bit axes) | 2²⁵⁵ ≈ 5.8×10⁷⁶ sectors | +| HJ coverage (2026) | 2.8M / 5.8×10⁷⁶ = **4.8×10⁻⁷¹** (vanishingly sparse) | +| Interpretation | HJs are **vanishingly sparse**—they don't "cover" space, they provide strategic waypoints | + +**Key insight:** Cyberspace doesn't "collapse" as HJ density increases. It transitions from **impossible** → **nation-state only** → **cloud-feasible** → **consumer-accessible**. The spatial structure remains; only accessibility changes. + +--- + +## Events Specification + +### Block Anchor Events (Existing, Unchanged) + +**Kind:** 321 (CSEP-321) + +Existing block anchor events remain valid. No changes required. + +### Hyperjump Entry Announcement (New) + +**Kind:** 33340 (CSEP-33340) +**Purpose:** Signal that an avatar has reached a hyperjump sector-plane and is now on the HJ network + +**Required tags:** +- `A`: `["A", "hyperjump_entry"]` +- `e`: `["e", "", "", "previous"]` +- `c`: `["c", ""]` (coordinate on the entry plane) +- `HJ`: `["HJ", ""]` (the target HJ being entered) +- `axis`: `["axis", "X"|"Y"|"Z"]` (which plane was used) + +**Validation:** +1. Verify previous event was a valid sidestep to a plane coordinate +2. Verify the plane coordinate matches the target HJ on the specified axis: `sector(plane_coord_axis) == sector(HJ_axis)` +3. If sector doesn't match, reject + +--- + +## Security Considerations + +### Sector Entry Does Not Reveal More Information + +Knowing an avatar is "on the X-plane of HJ H" reveals only that their X sector equals H's X sector. Their Y and Z sectors (and all Gibson-level precision) remain hidden. This is strictly less information than revealing the full 3D point. + +### Directional Commitment Prevents Free Teleportation + +By binding the commitment cost to the XOR distance between specific (from, to) pairs, the protocol prevents: +- **Reuse:** Commitment is single-use +- **Amortization:** Can't "build up" credit for long hops +- **Distance cheating:** Far hops cost more, always + +### Backward Compatibility + +- Existing hyperjump coordinates (merkle roots) are unchanged +- Existing `kind=321` block anchor events remain valid +- Old clients that don't support sector entry can still use **point entry** (3D hop)—it just costs vastly more +- Sector entry is opt-in and detected by validators + +--- + +## Open Questions for Discussion + +1. **Commitment height formula:** Current proposal uses popcount of high 128 bits of XOR difference. Alternatives? + - Full Hamming distance / 4 + - LCA height of (from, to) coordinates (but this requires knowing both points upfront, which is circular) + - Precomputed distance tier table + +2. **"Welcome HJ" for new spawns?** A predictable low-cost entry point (e.g., derived from genesis block) could help onboard users. But this introduces a "central" point, which may violate decentralization ethos. + +3. **Route discovery:** Should clients have built-in graph routing for multi-hop journeys, or should this be left to third-party tools? + +4. **Bitcoin reorg handling:** Should implementations track Bitcoin finality depth (e.g., 6 confirmations) before accepting HJs from new blocks? + +--- + +## Implementation Checklist + +- [ ] Community review and feedback on this draft +- [ ] Finalize directional commitment formula (open question #1) +- [ ] Update DECK-0001 with approved changes +- [ ] Add sector-based HJ queries to cyberspace-cli (filter by sector, not exact coordinate) +- [ ] Add commitment computation to hyperjump validation +- [ ] Create `kind=33340` event handler +- [ ] Update tests for new validation rules +- [ ] Write migration guide for existing clients + +--- + +*This DECK draft is for community review. Comments welcome via GitHub issues or Nostr DM to @arkin0x.* + +--- + +## Appendix: Mathematical Derivation + +### Expected LCA for Sector Matching + +Given: +- Sector space: S = 2⁵⁵ sectors per axis +- N target sectors (from HJs): N = blocks × 3 = 2.8M +- Random spawn position + +**Probability that at least one target shares ≥k high-order bits with spawn:** + +P(match) = 1 - P(all N targets have < k matching) + = 1 - (1 - 2^(-k))^N + +For median case (P = 0.5): +0.5 = 1 - (1 - 2^(-k))^N +(1 - 2^(-k))^N = 0.5 +1 - 2^(-k) = 0.5^(1/N) +2^(-k) = 1 - 0.5^(1/N) + +For large N, using Taylor approximation: +2^(-k) ≈ ln(2) / N +k ≈ log₂(N) - log₂(ln(2)) +k ≈ log₂(N) + 0.53 + +With N = 2.8M: +k ≈ log₂(2.8×10⁶) + 0.53 +k ≈ 21.4 + 0.53 +k ≈ 22 bits matching (median, one axis) + +**For best-of-3 axes:** +P(best LCA ≤ h) = 1 - P(all 3 axes have LCA > h) + = 1 - (1 - P(one axis has LCA ≤ h))³ + +Solving for median (CDF = 0.5): +Median LCA ≈ 33 bits + +This matches our empirical calculations. + + +--- + +## PR Description (for reference) + +**Title:** DECK-0001 v2: Sector-based hyperjump entry planes + +**Summary:** +Each HJ has 3 sector-wide entry planes (1 sector thick). Match ONE axis sector (55 bits) instead of exact Gibson coordinate (85 bits). Entry cost: h≈84 → h≈33, enabling consumer access in ~15 minutes ($0.09 cloud). + +**Open Questions:** +1. Commitment height formula? (popcount vs alternatives) +2. Welcome HJ for spawns? +3. Route discovery method? +4. Bitcoin reorg handling? + From b46a986bae226e650f23dc7965c648ac6162df7d Mon Sep 17 00:00:00 2001 From: XOR Date: Tue, 14 Apr 2026 20:49:49 -0500 Subject: [PATCH 10/11] Fix directional commitment: use block height, not coordinate XOR MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PROBLEM: Original formula (popcount of coordinate XOR) gives h=64 median for random merkle roots. Cost: 2^64 ≈ 10^19 ops (5.8 million years). Makes HJ network completely unusable. ROOT CAUSE: Bitcoin merkle roots are uniformly random 256-bit values. Any two random values have XOR distance ≈256 bits, popcount ≈64. SOLUTION: Use Bitcoin block HEIGHT difference instead: - commitment_height = |B_to - B_from|.bit_length() - Median Δ=271K blocks → h=19 → 524K ops (~5ms) - 100% of hops are h≤20 (max with current Bitcoin history) - Still preserves locality: nearby blocks cheap, distant blocks expensive - triangle inequality holds: multi-hop routing is valid skill This makes the HJ network practical for everyday use while maintaining spatial fabric and preventing free teleportation. --- decks/DECK-0001-hyperjumps.md | 101 +++++++++++++++++++++++----------- 1 file changed, 68 insertions(+), 33 deletions(-) diff --git a/decks/DECK-0001-hyperjumps.md b/decks/DECK-0001-hyperjumps.md index 17daf30..04c691c 100644 --- a/decks/DECK-0001-hyperjumps.md +++ b/decks/DECK-0001-hyperjumps.md @@ -135,7 +135,7 @@ This ensures: --- -### 2. Hyperjump-Cost Problem (Normative) +### 2. Directional Cantor Commitment (Normative) #### The Problem @@ -145,59 +145,94 @@ The original DECK-0001 defines hyperjump as **free teleportation** between any t - Violates Property 1 (locality) at the protocol layer We need a cost function that: -1. Scales with spatial distance (preserves locality) +1. Scales with distance (preserves locality) 2. Costs meaningful work (not arbitrary fees) 3. Cannot be reused (no amortization) -4. Is consumer-feasible for reasonable distances +4. Is consumer-feasible for all practical distances -#### Proposed Solution: Directional Cantor Commitment +#### Problem with Coordinate-Based Distance -When making a hyperjump from **H_from** to **H_to**, the avatar must compute a **directional Cantor commitment**: +An initial approach used XOR distance of full 256-bit merkle-root coordinates: ``` -direction_vector = H_to XOR H_from // 256-bit directional signature -commitment_height = popcount(direction_vector >> 128) // 0-128, based on high bits -commitment = compute_cantor_prefix(direction_vector, commitment_height) +direction_vector = H_to XOR H_from (256-bit merkle roots) +commitment_height = popcount(high 128 bits) ``` -The **commitment** is a partial Cantor tree computation (not a full hop proof) that: -- Costs 2^commitment_height operations -- Is unique to this specific (from, to) pair -- Cannot be reused for a different destination -- Expires after use (single-use commitment) +**Result:** For random 256-bit merkle roots, median commitment height is **h=64**, costing 2^64 ≈ 1.8×10^19 operations (~5.8 million years). This makes the HJ network unusable. + +**Root cause:** Bitcoin merkle roots are uniformly random. Any two random 256-bit values have XOR distance ≈256 bits and popcount ≈64. The formula accidentally makes every HJ pair maximally distant. + +#### Solution: Bitcoin Block Height Difference + +The commitment height is derived from **Bitcoin block height difference**, not spatial coordinate distance: + +``` +block_diff = |B_to - B_from| (absolute difference in block heights) +commitment_height = block_diff.bit_length() # log2(block_diff), or 0 if block_diff = 0 +commitment_cost = 2^commitment_height SHA256 operations +``` + +**Why this works:** +- Block height is the only meaningful "distance" in the HJ system (merkle coordinates are random, block numbers are ordered) +- Nearby blocks (in height) represent "nearby" HJs conceptually +- With ~940K blocks, random block pairs have median Δ=271K → h=19 → 524K ops (~5ms) +- **100% of hops are h≤20** (maximum possible with current Bitcoin history) +- Cost scales naturally: adjacent blocks are trivial, distant blocks cost more #### Cost Scaling -| Distance (hamming XOR on high 128 bits) | Commitment Height | Compute Time (consumer) | Cloud Cost | -|----------------------------------------|-------------------|-------------------------|------------| -| < 32 bits (nearby) | 8-16 | < 1 second | <$0.01 | -| 32-48 bits (same sector band) | 16-24 | 1 min - 1 hour | $0.01-1 | -| 48-64 bits (cross-sector) | 24-32 | 1 hour - 1 day | $1-10 | -| 64-80 bits (far) | 32-40 | 1 day - 1 week | $10-100 | -| 80-96 bits (very far) | 40-48 | 1 week - 1 month | $100-1000 | -| 96-112 bits (across space) | 48-56 | 1 month - 1 year | $1000-10k | -| > 112 bits (opposite corners) | 56-64 | 1-10 years | $10k-100k | +| Block Height Difference | Commitment Height | SHA256 Operations | Time (consumer GPU) | Cloud Cost | +|------------------------|-------------------|-------------------|---------------------|------------| +| Δ = 1 (adjacent) | h = 1 | 2 ops | < 1 μs | $0 | +| Δ = 10 (nearby) | h = 4 | 16 ops | < 1 μs | $0 | +| Δ = 100 (~1 day) | h = 7 | 128 ops | < 1 μs | $0 | +| Δ = 1,000 (~1 week) | h = 10 | 1K ops | ~1 μs | $0 | +| Δ = 10,000 (~2 months) | h = 14 | 16K ops | ~0.2 ms | $0 | +| Δ = 100,000 (~2 years) | h = 17 | 131K ops | ~1 ms | $0 | +| Δ = 500,000 (across chain) | h = 19 | 524K ops | ~5 ms | $0.0001 | +| **Median (random pair)** | **h = 19** | **524K ops** | **~5 ms** | **$0.0001** | +| **Maximum (940K blocks)** | **h = 20** | **1M ops** | **~10 ms** | **$0.0002** | -This preserves the **graph structure** of the hyperjump network while maintaining spatial locality. Nearby HJs are cheap to reach; distant ones cost more. +**Note:** Maximum possible block difference is ~940K (in 2026), so **h never exceeds 20**. As Bitcoin grows, h increases by ~1 every 10 years (when block count doubles). At year 2100 with 10M blocks, max h=24 (16M ops, ~160ms) — still consumer-feasible. #### Non-Reuse Mechanism -The commitment includes: -- Previous movement event ID (binds to specific position in chain) -- Timestamp of hyperjump event -- Destination coordinate +The commitment MUST be single-use and bound to the specific movement: + +```python +commitment_preimage = ( + previous_movement_event_id + # binds to chain position + hyperjump_event_timestamp + # prevents precomputation attacks + destination_coordinate + # binds to specific target + block_diff # the distance metric +) +commitment_hash = SHA256(commitment_preimage) +``` + +Validators MUST verify: +1. `block_diff` matches the actual height difference from anchor events +2. Commitment hash is valid +3. Commitment has not been reused (track by `previous_movement_event_id`) +4. Reject if any check fails + +#### Triangle Invariance (No Cheating) -This ensures the commitment is **single-use** and **non-transferable**. Validators reject any hyperjump event where the commitment doesn't match the specific (from, to, timestamp) tuple. +Strategic multi-hop routing is **valid and encouraged**: -#### Open Questions +- Direct hop Δ=500K: h=19, 524K ops +- Two hops Δ=250K + Δ=250K: 2 × (h=18, 262K ops) = 524K ops total -1. **Should commitment height be continuous or tiered?** Continuous is more precise; tiered is simpler to implement. +**Total cost is identical.** The triangle inequality holds. No cheating. -2. **Can commitments be precomputed?** Yes, but they're still single-use. Precomputation is an optimization, not an amortization. +This mirrors physical transit: taking 3 bus stops costs the same as one long route covering the same distance. Multi-hop routing is a skill, not an exploit. -3. **What prevents farming cheap short hops to "build up" to a long hop?** Nothing—this is intended! Strategic multi-hop routing is a valid use case and mirrors physical transit networks. +#### Open Questions (Resolved) -4. **Should there be a maximum commitment height?** Suggest N=64 (reasonable upper bound). Beyond that, the hop is effectively impossible for consumers. +1. **Commitment height formula?** → **Block height bit_length** (see above) +2. **Maximum commitment height?** → **No cap needed**, naturally bounded by Bitcoin growth (h≤20 in 2026, h≤24 by 2100) +3. **Can commitments be precomputed?** → Yes, but still single-use. Optimization, not amortization. +4. **What prevents farming cheap hops?** → Nothing! Multi-hop routing is valid. Triangle inequality ensures total cost equals direct hop cost. --- From d22c7c618671d7e836f8be8dcfb436e69039c5b1 Mon Sep 17 00:00:00 2001 From: XOR Date: Thu, 16 Apr 2026 12:12:28 -0500 Subject: [PATCH 11/11] DECK-0001 v2: Sector-based hyperjump entry with enter action and Cantor traversal proof --- decks/DECK-0001-hyperjumps.md | 101 ++++++++++++++++++++++++++++------ 1 file changed, 85 insertions(+), 16 deletions(-) diff --git a/decks/DECK-0001-hyperjumps.md b/decks/DECK-0001-hyperjumps.md index 04c691c..5e41cd1 100644 --- a/decks/DECK-0001-hyperjumps.md +++ b/decks/DECK-0001-hyperjumps.md @@ -103,26 +103,33 @@ def sector(coord256: int, axis: str) -> int: #### Entry Validation -To enter a hyperjump via a plane, an avatar MUST prove they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. - -This is done via a standard **sidestep movement event** (`A=sidestep`) with: +To enter a hyperjump via a plane, an avatar MUST publish an **enter action** (kind 3333, `A=enter`) proving they have reached a coordinate whose **sector** matches the hyperjump's sector on the chosen axis. +The enter action includes: - Destination coordinate **D** where `sector(chosen_axis) = sector(HJ_axis)` -- Standard sidestep Merkle proof for all three axes +- Standard Cantor proof for the path to **D** (same as hop proof) +- Reference to the target HJ being entered Example (entering via Y-plane): ```json { "kind": 3333, "tags": [ - ["A", "sidestep"], + ["A", "enter"], ["C", ""], // sector(Y) matches HJ's sector(Y) - ["proof", ""] + ["HJ", ""], + ["axis", "Y"], + ["proof", ""] ] } ``` -After reaching the plane, the avatar publishes a **hyperjump entry announcement** (kind 33340, see below) to signal they are now "on" the hyperjump network. +**Why `enter` instead of `sidestep`:** +- **Sidestep** uses Merkle proofs for storage-infeasible LCA heights (h>35-40) +- **Enter** uses Cantor proofs for sector-level precision (h≈33, consumer-feasible) +- The enter action is specifically for hyperjump plane entry, with HJ reference and validation + +After publishing the enter action, the avatar is now "on" the hyperjump network and can publish hyperjump traversal proofs to move between HJs. #### Exit Behavior @@ -150,6 +157,8 @@ We need a cost function that: 3. Cannot be reused (no amortization) 4. Is consumer-feasible for all practical distances +**Additionally:** We need a **traversal proof** mechanism - an entity traveling from block N to block M must publish proof that they traversed the path, not just that they paid a cost. + #### Problem with Coordinate-Based Distance An initial approach used XOR distance of full 256-bit merkle-root coordinates: @@ -165,7 +174,7 @@ commitment_height = popcount(high 128 bits) #### Solution: Bitcoin Block Height Difference -The commitment height is derived from **Bitcoin block height difference**, not spatial coordinate distance: +The **access commitment** is derived from **Bitcoin block height difference**, not spatial coordinate distance: ``` block_diff = |B_to - B_from| (absolute difference in block heights) @@ -180,6 +189,51 @@ commitment_cost = 2^commitment_height SHA256 operations - **100% of hops are h≤20** (maximum possible with current Bitcoin history) - Cost scales naturally: adjacent blocks are trivial, distant blocks cost more +#### Traversal Proof: Incremental Cantor Tree + +Access commitment pays the "toll" to use the HJ network. **Traversal proof** demonstrates that an entity actually traveled the path. + +**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) +``` + +**Publication:** Kind 3333 event with `A=hyperjump` tag: +```json +{ + "kind": 3333, + "tags": [ + ["A", "hyperjump"], + ["from_height", "850000"], + ["to_height", "850100"], + ["from_hj", ""], + ["to_hj", ""], + ["prev", ""], + ["proof", ""] + ] +} +``` + +**Verification:** Recompute tree from leaves, verify root matches. O(path_length) operations. + +**Non-reuse:** Temporal seed binds proof to chain position. Replay = equivocation (detectable). + +**See:** `decks/hyperjump-traversal-proof.md` for full specification. + #### Cost Scaling | Block Height Difference | Commitment Height | SHA256 Operations | Time (consumer GPU) | Cloud Cost | @@ -301,20 +355,35 @@ Existing block anchor events remain valid. No changes required. ### Hyperjump Entry Announcement (New) -**Kind:** 33340 (CSEP-33340) -**Purpose:** Signal that an avatar has reached a hyperjump sector-plane and is now on the HJ network +**Kind:** 3333 (standard movement action) +**Purpose:** Signal that an avatar has entered a hyperjump sector-plane and is now on the HJ network **Required tags:** -- `A`: `["A", "hyperjump_entry"]` +- `A`: `["A", "enter"]` (action type - 4th movement primitive) - `e`: `["e", "", "", "previous"]` -- `c`: `["c", ""]` (coordinate on the entry plane) +- `c`: `["c", ""]` (coordinate on the entry plane) - `HJ`: `["HJ", ""]` (the target HJ being entered) - `axis`: `["axis", "X"|"Y"|"Z"]` (which plane was used) +- `proof`: `["proof", ""]` (Cantor proof for reaching the entered coordinate) + +**Action semantics:** +The `enter` action is a 4th movement primitive (alongside spawn, hop, sidestep). It proves the avatar has reached a coordinate whose **sector** matches a hyperjump's sector on the specified axis. + +**Proof construction:** +Build a Cantor pairing tree for the path from spawn (or previous known position) to the entered coordinate. The proof is the Cantor root of that path — standard hop-style proof, but the destination is specifically on a hyperjump plane. **Validation:** -1. Verify previous event was a valid sidestep to a plane coordinate -2. Verify the plane coordinate matches the target HJ on the specified axis: `sector(plane_coord_axis) == sector(HJ_axis)` -3. If sector doesn't match, reject +1. Verify the Cantor proof is valid for the path to `entered_coord` +2. Verify sector match: `sector(entered_coord_axis) == sector(HJ_axis)` on the specified axis +3. Verify `previous_movement_event_id` is the actual preceding event in the chain +4. If any check fails, reject + +**Why not sidestep?** +The `enter` action is distinct from `sidestep`: +- **Sidestep**: crosses an LCA boundary via Merkle proof (storage-efficient for tall boundaries) +- **Enter**: proves arrival at a hyperjump plane via standard Cantor proof (sector-level precision, h≈33) + +Sidestep is for when Cantor is storage-infeasible (h>35-40). Enter uses Cantor because h≈33 is consumer-feasible (~15 min). --- @@ -362,7 +431,7 @@ By binding the commitment cost to the XOR distance between specific (from, to) p - [ ] Update DECK-0001 with approved changes - [ ] Add sector-based HJ queries to cyberspace-cli (filter by sector, not exact coordinate) - [ ] Add commitment computation to hyperjump validation -- [ ] Create `kind=33340` event handler +- [ ] Create kind 3333 event handler for enter action - [ ] Update tests for new validation rules - [ ] Write migration guide for existing clients