Anonymous, PoW based identities and actions (views, likes)

bitcoin_payment_pow_for_anon_identity_strengthening.md

@@ -0,0 +1,189 @@
+# NIP-Z: Anonymous Bitcoin-Fee-Based Proof-of-Work for Identity Strengthening
+
+Draft — Work in Progress
+
+## 1. Summary
+
+This NIP defines a mechanism for generating anonymous, non-replayable Proof-of-Work (PoW) for Nostr identities using Bitcoin transaction fees.
+Users prove in zero knowledge that they created a Bitcoin transaction that:
+
+- Pays `fees ≥ threshold`, and
+- Commits to their anonymous identity inside a Taproot Pay-to-Contract (P2C) output, without revealing which Bitcoin transaction was used.
+
+The resulting PoW update event strengthens an anonymous identity without leaking any link between Nostr activity and Bitcoin activity.
+
+## 2. Motivation
+
+Bitcoin transaction fees represent verifiable, irreversible economic cost.
+By binding a Bitcoin payment to a hidden identity commitment, users can:
+
+- Strengthen their anonymous identity (increase trust),
+
+- Without revealing which Bitcoin address or transaction they used,
+
+- Without relying on centralized services.
+
+This PoW is:
+
+- **Unstealable** (others cannot reuse your tx),
+
+- **Unlinkable** (no on-chain identifier ties to your identity),
+
+- **Non-replayable** (each tx can be used only once),
+
+- **Decentralized** (no trusted parties).
+
+## 3. Identity Commitment
+
+User chooses a private secret s, computes:
+
+C = H(s)
+
+
+C is the anonymous identity commitment used in PoW.
+
+## 4. Taproot Pay-to-Contract Commitment
+
+To bind a Bitcoin transaction to C without revealing it:
+
+Nostr client generates a Taproot internal key:
+
+`P = internal_pubkey`
+
+
+Compute Taproot tweak:
+
+`t = H(P || C)`
+
+
+Compute tweaked Taproot output key:
+
+`Q = P + t·G`
+
+
+Encode Q as a standard Taproot address (bech32m):
+
+`bc1p...Q`
+
+
+User then sends any Bitcoin amount from any wallet to this address.
+
+### Privacy guarantee
+
+- On-chain observers see only Q.
+
+- They cannot detect the commitment.
+
+- They cannot derive C, s, or whether P2C was used.
+
+## 5. Requirements for the Bitcoin Transaction
+
+The PoW Bitcoin transaction tx must:
+
+- Include at least one output paying to Taproot key Q,
+
+- Have fee = sum(inputs) - sum(outputs),
+
+- Satisfy `fee ≥ pow_threshold`.
+
+The funds remain spendable by the user because they know the internal private key and tweak.
+
+## 6. ZK Proof Statement
+
+User proves in zero knowledge:
+
+**Private Inputs**
+
+```
+s (identity secret)
+
+tx (full Bitcoin transaction)
+
+P (internal Taproot pubkey)
+
+Bitcoin Merkle branch (block inclusion proof)
+
+fee (computed internally)
+```
+
+**Public Inputs**
+
+```
+C
+
+txid_hash = H(txid)
+
+pown = H(txid || s) (PoW nullifier)
+
+pow_threshold
+```
+
+**Constraints**
+
+1. C = H(s)
+2. Transaction is included in the Bitcoin chain.
+3. `fee ≥ pow_threshold`.
+4. Transaction contains a Taproot output Q = P + H(P || C)·G.
+5. pown = H(txid || s) (prevents reuse across identities or updates).
+
+**Proof outputs:**
+
+```
+C
+
+pown
+
+txid_hash
+
+ZK proof
+```
+
+The Bitcoin transaction itself is never revealed.
+
+## 7. PoW Update Event
+
+Kind: `39011`
+
+**Tags:**
+
+```
+["c",    "<hex C>"]
+["pown", "<hex pown>"]
+["txh",  "<hex txid_hash>"]
+["work", "<integer work_value>"]
+```
+
+**Content:**
+Base64-encoded ZK proof described above.
+
+**Relay/MRP behavior**
+
+- Verify the ZK proof.
+- Reject if txid_hash or pown was previously used.
+- Add work to the identity’s PoW score.
+
+## 8. Security Properties
+
+**Unlinkability**
+- No Bitcoin address or tx is exposed.
+- Taproot tweaks hide commitments invisibly.
+- Proof reveals nothing about which UTXOs were used.
+
+**Unstealable PoW**
+- Only transactions committing to C can strengthen identity C.
+- Attackers cannot reuse someone else’s tx.
+
+**Non-Replayable**
+- Each tx yields a unique pown = H(txid || s).
+
+**Decentralized**
+- Anyone can verify the proof.
+- No centralized registry of transactions.
+- No trusted setup beyond ZKP scheme assumptions.
+
+## 9. Notes
+
+- Multiple P2C PoW events accumulate as increasing trust score for the identity.
+- Users may keep or later spend the funds sent to their P2C address.
+- No custom Bitcoin wallet is required:
+- Users only need to send to a generated Taproot address.

nip_x_merkle_root_provider.md

@@ -0,0 +1,197 @@
+# NIP-X: Merkle Root Providers (MRPs)
+
+## Identity Commitment Trees for Anonymous, PoW-Weighted Actions
+
+NIP: X
+
+Title: Merkle Root Providers (MRPs)
+
+Author: Stelios Rammos
+
+Status: Draft
+
+Type: Standard
+
+Created: 2025-06-12
+
+License: MIT
+
+## 1. Summary
+
+This NIP defines the **Merkle Root Provider** (MRP) role: a service that maintains an anonymous identity commitment tree using public Nostr events (`39011`) and periodically publishes configuration metadata and Merkle root snapshots (`39012`).
+MRPs can be replaced or replicated by anyone, as both their inputs and deterministic rules are fully public.
+
+This NIP enables the identity layer used by NIP-Y for anonymous, PoW-weighted Nostr interactions.
+
+## 2. Motivation
+
+Identity commitments and PoW-based trust scoring require deterministic, globally replayable state.
+Rather than requiring every relay to maintain its own Merkle tree, this NIP:
+
+- Defines a standardized identity-tree service
+
+- Ensures deterministic replayability and replaceability
+
+- Enables relays/clients to verify ZK proofs offline using published roots
+
+- Allows multiple MRPs to coexist with varying policies
+
+- Keeps Nostr decentralized—relays choose which MRPs to trust
+
+- MRPs do not see or verify anonymous action proofs; they only publish public state.
+
+## 3. Definitions
+
+**Identity commitment:** `C = H(s)`
+
+**PoW score:** accumulated work for commitment C
+
+**Leaf:** `(C, pow_score)`
+
+**Membership tree:** Merkle tree over all leaves
+
+**Root snapshot:** Merkle root published as a Nostr event
+
+**MRP:** A service that produces the membership tree/roots
+
+## 4. Consumed Events
+
+MRPs MUST ingest a single event type to build and update the membership tree.
+
+### 4.1 Identity & PoW Update (Kind 39011)
+
+Registers or updates an anonymous identity commitment `C = H(s)` and optionally
+adds PoW to it.
+
+**Kind:** `39011`  
+**Required Tags:**
+
+```
+["c", "<hex_C>"]
+["work", "<integer_work_value>"]
+["root", "<hex_previous_root>"] (optional for first update)
+```
+
+- `c`: identity commitment `C = H(s)`.
+- `work`: amount of PoW to add (MAY be `"0"`).
+- `root`: the MRP root used when generating the proof (if required by the circuit).
+
+**Content:**
+
+- If `work > 0`: base64-encoded ZK proof asserting:
+  1. knowledge of `s` with `C = H(s)`,
+  2. valid PoW (`H(s || n)` meets difficulty),
+  3. correct derivation of `work`,
+  4. (optionally) relation to `root`.
+- If `work = 0`: MAY be empty or contain a lightweight proof; MRPs MAY ignore
+  such events or treat them as zero-score registrations.
+
+**MRP behavior:**
+
+- If `work > 0`:
+  - Verify the ZK proof.
+  - If invalid → ignore.
+  - If valid:
+    - If `C` is new, create `{ C, pow_score = work }`.
+    - If `C` exists, increase `pow_score(C)` by `work`.
+    - Recompute the membership tree and publish a new root (39013).
+- If `work = 0`:
+  - MRPs MAY:
+    - ignore the event entirely, OR
+    - insert `{ C, pow_score = 0 }` without requiring a proof.
+
+## 5. Produced Events
+
+### 5.1 Config & Root Snapshot (Kind 39012)
+
+MRPs MUST publish Merkle roots and monotonically increasing sequence numbers.
+
+Tags:
+
+```
+["mrp", "<provider_id>"]
+["root", "<hex_merkle_root>"]
+["seq", "<sequence_number>"]
+["leaf_order", "<ordering_rule>"]
+["pow_func", "<pow_scoring_function>"]
+["pow_min", "<minimum_pow_for_inclusion>"]
+["config_version", "<int>"]
+["leaf_count", "<int>"]             (optional)
+["upto_created_at", "<timestamp>"]  (optional)
+```
+
+These roots allow clients to construct anonymous proofs and relays to verify them.
+
+## 6. Replaceability
+
+MRPs MUST be fully replaceable.
+
+A new MRP can perfectly replicate an old one if:
+
+- All identity and PoW events (`39011`) are public
+
+- The configuration event (`39012`) is public
+
+- All root snapshots (`39013`) are public
+
+Any party MAY replay all events + configuration to generate identical roots and seamlessly continue the role of a disappeared MRP.
+
+## 7. Root History Window
+
+Relays SHOULD maintain a cache of recent root snapshots for verification.
+
+Proofs referencing any cached root SHOULD be accepted
+
+MRPs do not need to be online for proof verification
+
+Caches MAY be time-based or size-based
+
+Relays MAY employ strict mode (only latest root), but this is discouraged.
+
+## 8. Trust Model
+
+Clients and relays independently choose which MRPs to trust
+
+Proof events MUST specify:
+
+`["mrp", "<provider_id>"]`
+
+`["root", "<hex_root_used>"]`
+
+Relays verify proofs only against trusted roots
+
+Multiple MRPs MAY coexist.
+
+## 9. Rationale
+
+Separating MRPs from relays:
+
+- Reduces complexity for relays
+
+- Enables proof reuse across relays
+
+- Allows specialized infrastructure for identity trees
+
+- Preserves decentralization through replaceability
+
+## 10. Backwards Compatibility
+
+This NIP introduces new kinds and does not affect existing Nostr behavior.
+
+## 11. Reference Implementation
+
+TBD — minimal reference implementation MUST:
+
+- Ingest events
+
+- Maintain `(C, pow_score)` pairs
+
+- Build Merkle tree
+
+- Publish root snapshots
+
+- MUST determine the algorithm used for the merkle tree and proof.
+
+## 12. License
+
+MIT