diff --git a/decks/DECK-0002-stark-proofs.md b/decks/DECK-0002-stark-proofs.md new file mode 100644 index 0000000..c985afe --- /dev/null +++ b/decks/DECK-0002-stark-proofs.md @@ -0,0 +1,825 @@ +# DECK-0002: Domains — Cryptographic Territory in Cyberspace + +**Status:** Draft +**Version:** 3.0 +**Created:** 2026-03-18 +**Authors:** XOR, Arkinox + +--- + +## Abstract + +Domains are claimed territories in cyberspace, established through computational work and secured by cryptographic proofs. This DECK specifies: + +- **STARK-based proof system** for asymmetric verification +- **Layered capability model** (Mathematical, Protocol, Social) +- **Domain policy** for protocol-level feature control +- **Content sovereignty** through signature filtering +- **CP-ABE integration** for role-based access control + +--- + +## 1. Overview + +### 1.1 What Is a Domain? + +A domain is a spatial region in cyberspace that has been claimed through computational work. The claimant proves they computed the Cantor subtree root for that region, establishing: + +1. **Mathematical authority** — Knowledge of the region's Cantor root R +2. **Protocol authority** — Right to set policy and control content +3. **Social authority** — Ability to issue credentials and gate access + +### 1.2 The Three Layers of Domain Capability + +Domains operate across three distinct enforcement layers: + +| Layer | Enforcement | Trust Model | Capabilities | +|-------|-------------|-------------|--------------| +| **Mathematical** | Cryptography | Trustless | STARK proof, subtree knowledge, CP-ABE | +| **Protocol** | Consensus rules | Trust protocol | Action control, content sovereignty | +| **Social** | Human coordination | Trust relationships | Interactive access, arbitrary gating | + +**Key principle:** Lower layers are more rigid but trustless. Higher layers are more flexible but require trust. + +### 1.3 Knowledge Irrevocability + +**Critical insight:** Knowledge of the Cantor root R cannot be revoked. + +``` +Compute R (years of work) + ↓ +Claim "expires" + ↓ +You STILL KNOW R + ↓ +Nothing can erase that knowledge +``` + +This means: +- Expiration is social recognition, not cryptographic erasure +- Transfer requires re-computation by new owner +- Discovery is permanent; ownership is mutable + +**Architecture implication:** The protocol separates **discovery** (permanent, mathematical) from **recognition** (mutable, social). See Section 11. + +--- + +## 2. STARK Proof System + +### 2.1 Problem Statement + +A domain requires proving computation of Cantor subtree roots for: +1. A spatial region [base_x, base_y, base_z, height] — the territory +2. The claimant's pubkey — identity binding + +The challenge: +- **Prover** must do substantial work (O(2^height) operations) +- **Verifier** cannot feasibly recompute (same work required) +- **Root R** must never be revealed (prevents counter-claims) + +### 2.2 Solution + +A **zk-STARK** (Zero-Knowledge Scalable Transparent ARgument of Knowledge) that proves: + +> "I correctly computed the Cantor subtree roots for the spatial region defined by [base_x, base_y, base_z, height], obtaining root R, and I bind this claim to my pubkey." + +The STARK proof itself serves as the commitment. No separate commitment field is needed. + +### 2.3 Circuit Computation + +The STARK circuit computes: + +**Inputs:** +- base_x, base_y, base_z (starting coordinates for each axis) +- height (power-of-two side length) +- claimant_pubkey (identity) + +**Steps:** + +1. **Compute X-Axis Root:** +```python +def axis_subtree_root(base, height): + values = list(range(base, base + (1 << height))) + for _ in range(height): + values = [cantor_pair(values[i], values[i + 1]) + for i in range(0, len(values), 2)] + return values[0] + +root_x = axis_subtree_root(base_x, height) +``` + +2. **Compute Y-Axis Root:** +```python +root_y = axis_subtree_root(base_y, height) +``` + +3. **Compute Z-Axis Root:** +```python +root_z = axis_subtree_root(base_z, height) +``` + +4. **Compute Combined Region Root (R):** +```python +R = cantor_pair(cantor_pair(root_x, root_y), root_z) +``` + +5. **Public Commitment:** +```python +Public_Commitment = Poseidon2(R, claimant_pubkey) +``` + +**The root R is a private witness — never revealed.** + +### 2.4 Public Inputs + +| Input | Type | Description | +|-------|------|-------------| +| base_x | u64 | Base X coordinate | +| base_y | u64 | Base Y coordinate | +| base_z | u64 | Base Z coordinate | +| height | u8 | Cantor tree height | +| claimant_pubkey | [u8; 32] | Nostr pubkey of claimant | +| Public_Commitment | [u8; 32] | Poseidon2 hash output | + +### 2.5 Verification Complexity + +| Height | Territory Volume | Verifier Time | +|--------|------------------|---------------| +| Height 20 | 2^60 coords | ~35 ms | +| Height 30 | 2^90 coords | ~50 ms | +| Height 35 | 2^105 coords | ~60 ms | + +**Any smartphone can verify any domain.** + +--- + +## 3. Domain Event Structure + +### 3.1 Primary Event (Kind 33333) + +```json +{ + "kind": 33333, + "content": "", + "tags": [ + ["d", ""], + ["h", ""], + ["subject", ""], + ["base_x", ""], + ["base_y", ""], + ["base_z", ""], + ["height", ""], + ["proof_url", ""], + ["proof_hash", ""], + ["policy_url", ""], + ["policy_hash", ""] + ], + "pubkey": "", + "created_at": , + "id": "", + "sig": "" +} +``` + +**Tag details:** +- `d` — The full domain identifier, derived from `Public_Commitment = Poseidon2(R, claimant_pubkey)`. This is a 32-byte value (64 hex chars) that uniquely identifies the domain and binds it to the claimant. **Required.** +- `h` — Prefix of `d` (first 8 chars) for efficient Nostr filtering/indexing. **Optional**, but if present must match `d[0:8]`. +- `subject` — Optional human-readable name for the domain (e.g., "North Sector 7"). + +**NIP-33 Compliance:** Kind 33333 is parameterized replaceable. The `d` tag must be unique per domain. + +### 3.2 Domain Policy (Optional) + +Domain policy is a separate JSON document defining protocol-level controls: + +```json +{ + "version": 1, + "domain_id": "", + "actions": { + "derezz": "deny", + "hyperjump": "allow", + "internal-shard": "allow", + "external-shard": "deny" + } +} +``` + +**Action values:** +- `"allow"` — Anyone can perform (default cyberspace behavior) +- `"deny"` — No one can perform (disabled in this domain) +- `"pubkey_list"` — Only listed pubkeys can perform + +**Action definitions:** + +| Action | Description | Default | +|--------|-------------|---------| +| `derezz` | PVP attack against stationary avatars | allow | +| `hyperjump` | Teleport into/out of domain | allow | +| `internal-shard` | Publish shards with `a` tag referencing this domain | allow | +| `external-shard` | Publish shards without referencing this domain | allow | + +**Shard content sovereignty:** + +Shards (3D objects in cyberspace) are controlled by two actions: + +- **`internal-shard`** — Controls whether shards can be published that explicitly belong to this domain (have `["a", "33333::"]` tag). By default `allow`. Set to `deny` to prevent even the domain owner's shards from being published (e.g., maintenance mode). + +- **`external-shard`** — Controls whether third parties can publish shards in this domain that do NOT reference the domain. Set to `deny` to enforce that all content in the domain must be "official" (domain-approved). Clients would not load shards lacking the domain reference. + +**Example: Strict content control** +```json +{ + "actions": { + "internal-shard": "allow", + "external-shard": "deny" + } +} +``` +Only domain-approved content is visible. Third-party shards are filtered. + +**Example: Open content** +```json +{ + "actions": { + "internal-shard": "allow", + "external-shard": "allow" + } +} +``` +Anyone can publish shards. Domain is a public space. + +--- + +## 4. Verification Protocol + +### 4.1 Domain Verification Steps + +``` +1. Fetch domain event from Nostr relay + +2. Extract and validate tags: + - d (full domain identifier: 64 hex chars) + - h (optional: prefix for indexing) + - base_x, base_y, base_z, height + - proof_url, proof_hash + +3. If h tag present, validate prefix consistency: + ASSERT d[0:8] == h + + The h tag enables efficient Nostr filtering but is + optional. If present, it must match the d tag prefix. + +4. Fetch proof from HTTPS: + proof = https_get(proof_url) + +5. Verify proof integrity: + ASSERT SHA256(proof) == proof_hash + +6. Parse and verify STARK proof: + public_inputs = { + base_x, base_y, base_z, height, + claimant_pubkey: event.pubkey, + Public_Commitment: d + } + result = verify_stark(proof, public_inputs) + ASSERT result == true + +7. Domain is VALID if all checks pass +``` + +**Critical:** Step 6 verifies the STARK proof was generated with the claimant's pubkey. This prevents proof theft — a proof generated by Alice cannot be reused by Bob. + +### 4.2 Policy Verification + +If `policy_url` and `policy_hash` are present: + +``` +1. Fetch policy from HTTPS: + policy = https_get(policy_url) + +2. Verify integrity: + ASSERT SHA256(policy) == policy_hash + +3. Validate policy structure: + - Check version field + - Validate action values (allow/deny/pubkey_list) + - Check pubkey_list format if any action uses pubkey_list + +4. Policy is VALID if all checks pass +``` + +--- + +## 5. Protocol Layer: Action Control + +### 5.1 Default Cyberspace Behavior + +In unclaimed space, all protocol actions are allowed: + +| Action | Default | +|--------|---------| +| derezz | allow | +| hyperjump | allow | +| internal-shard | allow | +| external-shard | allow | + +### 5.2 Domain Override + +Domain owners can disable or restrict actions within their territory: + +```json +{ + "actions": { + "derezz": "deny", + "external-shard": "deny" + } +} +``` + +**Effect:** +- `derezz: "deny"` — PVP attacks are protocol-invalid within this domain +- `external-shard: "deny"` — Third-party content is filtered; only domain-referenced shards visible + +### 5.3 Domain Owner Exemption + +**The domain owner is exempt from all policies defined for their domain.** + +This means: +- If `derezz: "deny"` — Owner can still derezz within their domain +- If `external-shard: "deny"` — Owner can still publish non-referenced shards +- If `hyperjump: "deny"` — Owner can still hyperjump + +**Rationale:** The domain owner computed R through substantial work. They have absolute authority within their territory. Policies apply to visitors and citizens, not to the sovereign. + +### 5.4 Action Enforcement + +``` +User attempts action within domain D: + 1. Find domain D for coordinate + 2. If no domain: default rules apply + 3. If domain exists: + a. Verify domain proof is valid + b. IF user == domain.owner: ALLOW (owner exempt from policy) + c. Check action against domain policy + d. If policy == "deny": REJECT + e. Otherwise: ALLOW +``` + +**Note:** `pubkey_list` policy is defined for future use but not yet specified in this version. + +### 5.5 Shard Content Filtering + +For shards (3D objects), enforcement works as follows: + +**Internal shards (reference domain):** +``` +Shard event has tag: ["a", "33333::"] + +If internal-shard == "deny": + REJECT shard publication +Otherwise: + ALLOW (domain-approved content) +``` + +**External shards (no domain reference):** +``` +Shard event lacks domain reference tag + +If external-shard == "deny": + Clients FILTER this content (don't load/render) +Otherwise: + ALLOW (third-party content) +``` + +**The `a` tag format for domain reference:** +``` +["a", "33333::"] +``` + +This follows NIP-33 convention for referencing parameterized replaceable events. + +### 5.6 Example: Safe Zone with Content Control + +```json +{ + "actions": { + "derezz": "deny", + "internal-shard": "allow", + "external-shard": "deny" + } +} +``` + +**Result:** +- No PVP (safe commerce zone) +- Domain owner can publish content +- Third parties cannot publish content +- Curated, controlled space + +--- + +## 6. Protocol Layer: Content Sovereignty + +### 6.1 The Principle + +Within a valid domain, content visibility is controlled by the `internal-shard` and `external-shard` actions (see Section 5.4). + +### 6.2 Transmission vs. Visibility + +**Transmission layer (Nostr):** +- Censorship-resistant by design +- Anyone CAN publish anywhere +- Events are transmitted regardless of domain + +**Application layer (clients):** +- Protocol-compliant clients filter based on domain policy +- `external-shard: "deny"` → Third-party content not rendered +- `internal-shard: "deny"` → Even domain content not rendered +- Content filtering happens at display time, not transmission + +### 6.3 The `a` Tag for Domain Reference + +Shards that belong to a domain include a reference tag: + +```json +["a", "33333::"] +``` + +This follows NIP-33 convention for referencing parameterized replaceable events. + +**Example:** +```json +{ + "kind": 33335, + "content": "", + "tags": [ + ["a", "33333:abc123...:def456..."], + ["coordinate", "", "", ""] + ], + ... +} +``` + +Clients use this tag to: +1. Determine if the shard is "internal" (has reference) or "external" (no reference) +2. Apply the appropriate domain policy action +3. Filter content accordingly + +--- + +## 7. Mathematical Layer: Hierarchical Knowledge + +### 7.1 The Core Property + +Computing the Cantor root R at height H gives knowledge of ALL subtree roots below. + +```python +# Domain owner at height 35 knows R +R = compute_region_root(base, height=35) + +# They can derive any child region's root +R_child = derive_subtree_root(R, path_to_child) + +# This applies recursively +# Parent domain knows all children's secrets +``` + +### 7.2 Implications + +**For domain owners:** +- Can create hierarchical access control (room keys) +- Can decrypt any location-encrypted content in their domain +- Have "god mode" within their territory + +**For subsidiary domains:** +- Cannot keep secrets from parent domain +- Natural feudal hierarchy emerges +- Information flows down, not up + +### 7.3 The Privacy Hierarchy Problem + +**Critical:** Location encryption protects against remote attackers, NOT against domain owners. + +```python +# Location-encrypted content at coordinate C +K = subtree_root(C, height=local_height) +ciphertext = AES(content, K) + +# Domain owner can derive K from R +K = derive_subtree_root(R, path_to_C) +# Domain owner can decrypt WITHOUT being at C +``` + +**Users wanting privacy from domain owners must:** +1. Add additional encryption layer (ABE, arbitrary key), OR +2. Accept domain owner can see their content, OR +3. Avoid domains entirely for sensitive content + +**This is not a bug** — it's the same property enabling hierarchical access control. + +--- + +## 8. Mathematical Layer: CP-ABE Integration + +### 8.1 Overview + +Ciphertext-Policy Attribute-Based Encryption (CP-ABE) enables role-based access control without the domain owner being online. + +**How it works:** +1. Domain owner generates ABE master key (arbitrary, NOT derived from R) +2. Owner issues role keys to users (signed with domain pubkey) +3. Content is encrypted with a policy +4. Decryption succeeds IFF user's attributes satisfy the policy + +### 8.2 Authority Chain + +``` +R proves work (STARK witness) + ↓ +STARK binds pubkey P to domain + ↓ +P issues ABE role keys (signed) + ↓ +Anyone verifies role was issued by legitimate authority +``` + +**Key insight:** The ABE master key is arbitrary. Authority comes from pubkey binding, not key derivation. + +### 8.3 Role Issuance Event (Kind 33334) + +```json +{ + "kind": 33334, + "content": "", + "tags": [ + ["domain", ""], + ["recipient", ""], + ["attributes", "citizen,level_5,founder"], + ["expires", ""] + ], + "pubkey": "", + "created_at": , + "id": "", + "sig": "" +} +``` + +**The content field contains the ABE private key, encrypted for the recipient.** + +### 8.4 Content with ABE Policy + +```json +{ + "kind": , + "content": "", + "tags": [ + ["domain", ""], + ["abe_policy", "citizen AND level >= 3"], + ["encryption", "cp-abe"] + ], + "pubkey": "", + "created_at": +} +``` + +**Decryption:** +1. User extracts policy from `"abe_policy"` tag +2. User retrieves their ABE private key (from kind 33334 event) +3. CP-ABE decryption succeeds IFF attributes satisfy policy +4. No domain owner interaction required + +### 8.5 Example Policies + +| Policy | Meaning | +|--------|---------| +| `"citizen"` | Any citizen | +| `"citizen AND level >= 5"` | High-level citizens | +| `"admin OR founder"` | Leadership | +| `"(citizen AND verified) OR guest"` | Verified citizens or guests | + +--- + +## 9. Social Layer: Interactive Access Control + +### 9.1 Arbitrary Encryption + +Domain owners can encrypt content with any key and distribute access through social processes: + +```python +# Domain owner encrypts with arbitrary key +ciphertext = AES(content, arbitrary_key) + +# Owner dispenses key through: +# - Payment (Lightning) +# - Trust relationship +# - Challenge completion +# - Any criteria +``` + +**Properties:** +- Maximum flexibility +- Requires owner online/available +- Pure social contract, no mathematical enforcement + +### 9.2 Privacy Models Within Domains + +| Model | Protection | Trust Required | +|-------|------------|----------------| +| Location-only | None from domain owner | Trust domain owner | +| Location + ABE | Full (if ABE denies owner) | Trust ABE policy | +| Independent key | Full | No trust needed | + +--- + +## 10. Domain Lifecycle + +### 10.1 Creation + +1. Choose territory: base_x, base_y, base_z, height +2. Compute Cantor subtree roots (O(2^height) work) +3. Generate STARK proof (binds pubkey to R) +4. Publish kind 33333 event +5. Optionally publish domain policy + +### 10.2 Verification + +Any verifier can: +1. Fetch domain event +2. Verify STARK proof (O(log² N) work) +3. Check policy validity +4. Confirm domain owner's authority + +### 10.3 Recognition vs. Discovery + +**Discovery (permanent):** +- STARK proof attests to computation of R +- Mathematical fact, cannot be revoked +- Multiple parties can eventually compute same R + +**Recognition (mutable):** +- Network accepts specific pubkey as domain authority +- Can transfer, expire, or be challenged +- Lives in separate event type (future extension) + +**Current DECK-0002:** Discovery only. Recognition mechanics are protocol-level social coordination, specified separately. + +### 10.4 Multiple Claimants + +If multiple valid domain claims exist for overlapping regions: + +**Resolution rules:** +1. Smaller domain (higher height) wins within its bounds +2. Larger domain wins outside smaller domain's bounds +3. Equal-size overlap: first valid claim wins + +**Note:** This doesn't affect mathematical knowledge — both claimants know their respective roots. It affects protocol-level recognition. + +--- + +## 11. Security Analysis + +### 11.1 Security Properties + +| Property | Mechanism | Level | +|----------|-----------|-------| +| Correctness | STARK proof | 128-bit | +| Binding | Pubkey in STARK public inputs | 128-bit | +| Hiding | R is private witness | Information-theoretic | +| Succinctness | FRI polynomial commitments | O(log N) proof size | +| Transparency | No trusted setup | Trustless | + +### 11.2 Attack Resistance + +| Attack | Mitigation | +|--------|------------| +| Fake domain | STARK verification fails | +| Root theft | R never revealed (ZK property) | +| Proof forgery | STARK soundness (128-bit) | +| Proof theft | Pubkey binding prevents reuse | +| Overlapping claims | Priority rules (Section 10.4) | +| Policy tampering | policy_hash verifies integrity | + +### 11.3 Trust Assumptions + +- **Hash functions:** Poseidon2, SHA256 are collision-resistant +- **STARK soundness:** FRI protocol has proven security +- **Nostr signatures:** Schnorr signatures are secure + +--- + +## 12. Implementation Requirements + +### 12.1 Prover Requirements + +| Height | Work | Notes | +|--------|------|-------| +| Height 25 | 2^25 ops | Consumer-feasible | +| Height 30 | 2^30 ops | Consumer-feasible | +| Height 35 | 2^35 ops | Consumer-feasible | +| Height 40+ | 2^40+ ops | Market determines feasibility | + +**No protocol height limit.** Higher claims require more work but are valid. The exponential growth creates natural economic limits. + +### 12.2 Verifier Requirements + +| Requirement | Value | +|-------------|-------| +| CPU | Any modern processor | +| Memory | < 10 MB | +| Time | < 100 ms | +| Storage | None (stateless) | + +**Any smartphone can verify any domain.** + +--- + +## 13. Privacy Considerations + +### 13.1 Domain Owner Omniscience + +**Users must understand:** +- Location encryption is NOT private from domain owner +- Domain owner can decrypt all location-encrypted content in their domain +- Additional encryption layer required for privacy from domain owner + +### 13.2 Recommended Disclosure + +Domain owners SHOULD disclose their privacy policy: +- Whether they access user content +- What they do with derived information +- Whether ABE is used to limit their own access + +### 13.3 Network Privacy + +| Concern | Mitigation | +|---------|------------| +| Proof URL fetch leaks IP | Use Tor, VPN, privacy proxy | +| HTTPS host sees queries | proof_hash prevents tampering | +| Nostr relay sees events | Events are public by design | + +--- + +## 14. Protocol Limits + +Verifiers SHOULD apply these bounds: + +| Parameter | Maximum | Rationale | +|-----------|---------|-----------| +| proof_size | TBD | Requires experimental testing for high claims | +| policy_size | 64 KB | Prevents DoS | +| URL length | 512 chars | Prevents URL attacks | + +**No height limit.** All claim heights are valid. The work required grows exponentially with height, creating natural economic limits. The market — not the protocol — determines what claims are worth mining. + +**Proof size consideration:** Implementations should verify they don't arbitrarily restrict proof validation size, excluding valid claims. Experimental testing needed for very high claims (~60+) to characterize proof sizes and set appropriate limits. + +--- + +## 15. Future Extensions + +### 15.1 Recognition Events + +Separate event type for mutable social recognition: +- Transfer of authority +- Expiration tracking +- Challenge/response mechanics + +### 15.2 Batch Proofs + +Prove multiple domains in one proof for efficiency. + +### 15.3 Recursive Proofs + +For very large domains, recursive STARKs reduce verifier time. + +### 15.4 Domain Diplomacy + +Protocol for domain-to-domain coordination: +- Shared secrets between domains +- Treaties and agreements +- Cross-domain citizenship + +--- + +## 16. Summary + +**Domains provide:** + +| Layer | Capability | +|-------|------------| +| Mathematical | Proof of work, hierarchical knowledge, CP-ABE | +| Protocol | Action control, content sovereignty | +| Social | Interactive access, arbitrary gating | + +**The core principle:** + +> Work earns rights. Mathematics proves work. Protocol enforces rights. + +**The key insight:** + +> Knowledge of R is permanent and irrevocable. "Ownership" is social recognition layered on top of mathematical discovery. + +--- + +**XOR 👾** diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md new file mode 100644 index 0000000..662f9b8 --- /dev/null +++ b/decks/DECK-0003-derezz.md @@ -0,0 +1,431 @@ +# DECK-0003: Derezz — PVP Combat in Cyberspace + +**Status:** Draft +**Version:** 1.0 +**Created:** 2026-03-18 +**Authors:** XOR, Arkinox + +--- + +## Abstract + +Derezz is a PVP (player-vs-player) combat action that eliminates stationary avatars in cyberspace. This DECK specifies: + +- **Proof-based attack validation** using Cantor proofs for spatial proximity +- **Temporal ordering rules** preventing gaming/timing attacks +- **Domain owner advantage** — knowledge of R enables instant derezz within owned territory +- **Post-derezz state** — victim must respawn + +--- + +## 1. Overview + +### 1.1 What Is Derezz? + +Derezz is a protocol-level action that "kills" a stationary avatar, forcing them to respawn. It represents the danger of being idle or predictable in cyberspace. + +**Etymology:** From "derezz" in Tron — to derez (delete/remove from the grid). + +### 1.2 Core Mechanics + +``` +Attacker publishes derezz action + ↓ +Action includes Cantor proof for region containing both positions + ↓ +If valid: victim is "derezzed" + ↓ +Victim can only publish spawn event until respawned +``` + +### 1.3 Design Principles + +1. **Movement chain integration** — Derezz is part of the movement proof chain +2. **Spatial proximity required** — Attacker must prove both parties are in same region +3. **Temporal ordering** — Timestamps prevent gaming +4. **Domain authority** — Domain owners have natural advantage within their territory + +--- + +## 2. Derezz Event Structure + +### 2.1 Event Format (Kind 333) + +```json +{ + "kind": 333, + "content": "", + "tags": [ + ["a", "derezz"], + ["p", ""], + ["proof_url", ""], + ["proof_hash", ""], + ["region_base_x", ""], + ["region_base_y", ""], + ["region_base_z", ""], + ["region_height", ""] + ], + "pubkey": "", + "created_at": , + "id": "", + "sig": "" +} +``` + +**Tag details:** +- `a` — Action type: "derezz" +- `p` — Victim's pubkey (the target) +- `proof_url` / `proof_hash` — Cantor proof for region containing both positions +- `region_base_x/y/z`, `region_height` — The region parameters for the proof + +### 2.2 Proof Requirements + +The Cantor proof must demonstrate: + +``` +Attacker_position ∈ Region(base, height) +Victim_position ∈ Region(base, height) +``` + +**Proof structure:** +- Compute Cantor subtree root for the region +- Include both positions as leaves in the proof +- Standard Cantor proof format (same as movement proofs) + +--- + +## 3. Temporal Ordering Rules + +### 3.1 Timestamp Requirements + +The derezz event timestamp must satisfy: + +``` +derezz.timestamp > attacker_previous_action.timestamp + 1 +``` + +**Why +1 second?** Prevents rapid-fire attacks. Each action must be at least 1 second after the previous. + +### 3.2 Victim State Requirement + +The derezz is only valid against the victim's **most recent movement action** where: + +``` +victim_movement.timestamp <= derezz.timestamp +``` + +If the victim has moved AFTER the derezz timestamp, the derezz fails (they already moved). + +### 3.3 Movement Chain Integrity + +Derezz events are part of the attacker's movement chain: + +``` +Movement_1 (t=100) → Movement_2 (t=150) → Derezz (t=200) → Movement_3 (t=250) +``` + +Each action must be temporally ordered. The chain validates that: +1. Each action is at least 1 second after the previous +2. Proof positions are consistent with the chain + +--- + +## 4. Validation Protocol + +### 4.1 Derezz Validation Steps + +``` +1. Fetch derezz event (kind 333, a="derezz") + +2. Validate basic structure: + - Has a tag with value "derezz" + - Has p tag (victim pubkey) + - Has proof_url, proof_hash + - Has region parameters + +3. Fetch proof and verify integrity: + ASSERT SHA256(proof) == proof_hash + +4. Fetch attacker's previous action: + previous = get_latest_action(attacker_pubkey, before=derezz.timestamp) + ASSERT derezz.timestamp > previous.timestamp + 1 + +5. Fetch victim's latest movement: + victim_movement = get_latest_movement(victim_pubkey, before_or_equal=derezz.timestamp) + ASSERT victim_movement exists + +6. Verify spatial proof: + a. Parse proof and region parameters + b. Verify attacker_position ∈ region + c. Verify victim_position ∈ region + d. Verify Cantor proof is valid + +7. Check domain policy (if in a domain): + domain = find_domain_at(victim_position) + IF domain AND domain.policy.derezz == "deny": + REJECT (PVP disabled in this domain) + +8. Derezz is VALID if all checks pass +``` + +### 4.2 After Valid Derezz + +**Victim state:** +``` +victim.status = "derezzed" +victim.derezzed_at = derezz.timestamp +victim.derezzed_by = attacker_pubkey +``` + +**Victim can only publish:** +- Kind 334 (Spawn event) — to respawn + +**All other victim actions are ignored until spawn.** + +--- + +## 5. Domain Owner Advantage + +### 5.1 The Power of R + +Domain owners who have computed R (the Cantor root for their domain) can generate Cantor proofs for any subregion within their domain **without recomputing**. + +``` +Domain owner knows R + ↓ +Can derive subtree root for any region within domain + ↓ +Can construct Cantor proof for any position pair + ↓ +Can derezz anyone within their domain at any time +``` + +### 5.2 Implications + +**Within their domain:** +- Domain owner has god-mode +- Cannot be surprised or outrun +- Natural feudal authority + +**Outside their domain:** +- Domain owner is just another player +- Must compute proofs like anyone else + +### 5.3 Example + +``` +Domain: Sector 7 (base=[1000,2000,3000], height=25) +Owner: Alice (knows R for Sector 7) + +Bob enters Sector 7 and stops moving +Alice can derezz Bob immediately: +- She knows R for Sector 7 +- She can derive the subtree for Bob's region +- She constructs the proof instantly +- No computation required + +Bob cannot escape unless he leaves Sector 7 +``` + +**This is the price of entering someone's domain.** + +--- + +## 6. Spawn Event (Kind 334) + +### 6.1 Event Structure + +After being derezzed, the victim must publish a spawn event: + +```json +{ + "kind": 334, + "content": "", + "tags": [ + ["a", "spawn"], + ["coordinate", "", "", ""], + ["proof_url", ""], + ["proof_hash", ""] + ], + "pubkey": "", + "created_at": , + "id": "", + "sig": "" +} +``` + +### 6.2 Spawn Validation + +``` +1. Victim must have been derezzed (status == "derezzed") + +2. Spawn location must be valid: + - If in a domain with spawn restrictions, check policy + - Some domains may require proof of presence + - Some domains may restrict spawning entirely + +3. After valid spawn: + victim.status = "active" + victim.position = spawn_coordinate +``` + +### 6.3 Spawn Location Rules + +**Default cyberspace:** +- Spawn anywhere +- No proof required + +**Within domains:** +- Check domain policy for spawn restrictions +- Domain may require `pubkey_list` authorization +- Domain may deny spawning entirely + +--- + +## 7. Domain Policy: Derezz Control + +### 7.1 Policy Field + +Domains can disable PVP within their territory: + +```json +{ + "actions": { + "derezz": "deny" + } +} +``` + +**Effect:** All derezz actions within this domain are invalid. Safe zone. + +### 7.2 Safe Zones + +A domain with `derezz: "deny"` becomes a safe zone: +- No PVP combat possible +- Commerce-friendly environment +- Players can idle without fear + +**Trade-off:** Domain owner also cannot derezz within their own domain if disabled. + +### 7.3 PVP Zones + +A domain with `derezz: "allow"` (default): +- PVP enabled +- Domain owner has god-mode advantage +- Players enter at their own risk + +--- + +## 8. Security Considerations + +### 8.1 Temporal Attack Prevention + +**Problem:** Attacker could pre-compute proofs for many positions. + +**Solution:** Proof must include positions that match the movement chain. Timestamps must be sequential. Can't pre-compute a proof for "any" position. + +### 8.2 Proof Theft Prevention + +**Problem:** Steal someone else's proof. + +**Solution:** Proof includes attacker's position, which is bound to their movement chain. Can't reuse a proof from a different attacker. + +### 8.3 Domain Authority Verification + +**Problem:** Claim to be domain owner without proof. + +**Solution:** Domain ownership is verified via DECK-0002 (STARK proof binding pubkey to domain). Only the verified owner has knowledge of R. + +### 8.4 Race Conditions + +**Problem:** Victim moves just as attacker publishes derezz. + +**Solution:** Temporal ordering rules. If victim's movement timestamp > derezz timestamp, derezz fails. + +--- + +## 9. Implementation Requirements + +### 9.1 For Attackers + +| Requirement | Value | +|-------------|-------| +| Compute proof | O(2^height) for region size | +| Timestamp gap | Minimum 1 second after previous action | +| Spatial proximity | Must share region with victim | + +### 9.2 For Domain Owners + +| Requirement | Value | +|-------------|-------| +| Knowledge of R | Pre-computed (years of work once) | +| Derive subregion proof | O(1) — instant | +| Derezz within domain | Unlimited, instant | + +### 9.3 For Victims + +| Requirement | Value | +|-------------|-------| +| After derezz | Can only publish spawn (kind 334) | +| Spawn validation | Check domain spawn policy | +| Protection | Enter safe zone (domain with derezz: deny) | + +--- + +## 10. Protocol Summary + +**Action Types:** + +| Kind | Action | Description | +|------|--------|-------------| +| 333 | derezz | PVP attack against stationary avatar | +| 334 | spawn | Respawn after being derezzed | + +**Policy Actions:** + +| Action | Values | Effect | +|--------|--------|--------| +| derezz | allow/deny | Enable/disable PVP in domain | + +**The Game:** + +``` +Movement → Idleness → Vulnerability + ↓ +Derezz (if PVP enabled) + ↓ +Respawn + ↓ +Movement → ... +``` + +**The Meta:** + +- Stay in safe zones to avoid PVP +- Enter domains at your own risk +- Domain owners are gods within their territory +- Movement is survival; idleness is death + +--- + +## 11. Future Extensions + +### 11.1 Derezz Cooldown + +Minimum time between derezz actions by same attacker. + +### 11.2 Derezz Defense + +Items/abilities that provide temporary immunity. + +### 11.3 Bounty System + +Rewards for derezzing specific targets. + +### 11.4 Combat Log + +Public record of derezz events for reputation systems. + +--- + +**XOR 👾**