# randomp2p **Vertrauensloser Multiplayer-Münzwurf – P2P im Browser, keine Server, kein Trust.** Zwei bis N Spieler verbinden sich via WebRTC (simple-peer) und führen ein kryptografisches Commit-Reveal-Protokoll aus, um einen garantiert fairen Münzwurf zu erhalten. Solange **ein** Teilnehmer ehrlich ist, ist das Ergebnis zufällig und manipulationssicher. ## Features - **P2P** – Kein Server, kein Account, keine zentrale Instanz - **Trustless** – Commit-Reveal-Protokoll mit SHA-256-Bindung, jeder verifiziert - **QR-Bootstrapping** – SDP-Offers/Answers werden als QR-Codes ausgetauscht - **Multiplayer (2–n)** – Beliebig viele Teilnehmer in einer Runde - **Coin-Animation** – 3D-Münzwurf via CSS - **100% Vanilla JS** – Keine Build-Tools, kein npm, keine Abhängigkeiten außer CDN-Libs ## Quick Start ```bash git clone cd randomp2p python3 -m http.server 8080 ``` Dann auf zwei (oder mehr) Geräten `http://localhost:8080` öffnen. > WebRTC + Kamera (`getUserMedia`) + Web Crypto API brauchen einen **sicheren Kontext**. Lokal via localhost funktioniert das. Für andere Geräte im selben Netzwerk die lokale IP verwenden. ## Spielanleitung ### Host 1. **"Raum erstellen"** – QR-Code mit SDP Offer wird angezeigt 2. **"Antwort-QR scannen"** – Kamera startet, scannt die Antwort-QRs der Beitreter 3. Jeder neue Spieler erscheint in der Liste 4. **"Münzwurf starten"** – Übergang in den Spiel-Screen 5. **"Münzwurf starten"** – Protokoll beginnt (Commit → Reveal → Ergebnis) ### Beitreter 1. **"Raum beitreten"** – Kamera startet 2. QR des Hosts scannen 3. **Antwort-QR zeigen** – Host scannt diesen QR 4. Verbindung steht, warten auf Start 5. Protokoll läuft automatisch durch – Ergebnis erscheint ### Protokoll-Phasen | Phase | Beschreibung | |-------|-------------| | **Commit** | Jeder Spieler generiert 32 Zufallsbytes und sendet den SHA-256-Hash an alle | | **Warten** | Sammle Commits aller Teilnehmer | | **Reveal** | Jeder sendet die rohen Zufallsbytes an alle | | **Verify** | Jeder prüft: SHA-256(received) == stored_commit | | **Result** | XOR aller Secrets → Parity (0=Kopf, 1=Zahl) | ## Architektur ``` randomp2p/ ├── index.html – 5 Screens + CDN-Libs ├── style.css – Dark-Theme, Coin-Animation ├── crypto.js – SHA-256, Zufallsbytes, XOR-Combine ├── p2p.js – MeshNet: simple-peer, QR-Signaling, Datenkanal ├── protocol.js – Commit-Reveal State Machine └── app.js – UI-Routing, Kamera/QR-Scan, Verkabelung ``` ### Abhängigkeiten (CDN) | Library | Zweck | |---------|-------| | [simple-peer](https://github.com/feross/simple-peer) | WebRTC-Datenkanäle | | [qrcodejs](https://github.com/davidshimjs/qrcodejs) | QR-Code-Generierung | | [jsQR](https://github.com/cozmo/jsQR) | QR-Code-Scanning per Kamera | ## Netzwerk-Topologie **Best Case (gleiches WiFi):** QR-SDP-Austausch zwischen Host und jedem Peer. Host teilt IP-Liste → potentiell volles Mesh über `signal_relay`. **Worst Case (NAT/Internet):** Stern-Topologie über den Host. Protokoll funktioniert trotzdem – die Fairness ist nicht von der Topologie abhängig. ## Warum ist das fair? Das Commit-Reveal-Protokoll garantiert: 1. **Keine späte Manipulation:** Der SHA-256-Commit bindet jeden Spieler vor dem Reveal an sein Secret (Preimage-Resistenz) 2. **Keine Absprache nötig:** Solange **ein** Teilnehmer ehrlich Zufallsbytes beisteuert, ist das XOR-Ergebnis zufällig 3. **Volle Transparenz:** Jeder Teilnehmer rechnet lokal alle Prüfungen und das Endergebnis Mathematisch: `result = S_1 ⊕ S_2 ⊕ ... ⊕ S_n`. Wenn `S_k` echt zufällig und vor `S_1..S_{k-1}, S_{k+1}..S_n` festgelegt wurde, ist `result` zufällig – unabhängig von allen anderen Secrets. ## IPFS-Deployment ```bash ipfs add -r . # → CID notieren, über IPFS-Gateway aufrufbar # → Gateway-URL als QR-Code in die App einbauen ``` ## Ausblick / TODOs - [ ] Volles Mesh: Peers verbinden sich direkt via relayed signaling - [ ] Timeout + Reconnect bei Verbindungsabbruch - [ ] Raum-Code als Alternative zum QR-Scan - [ ] TURN-Server-Konfiguration für NAT-Traversal - [ ] Mehrere Runden mit Historie - [ ] PWA-Manifest + ServiceWorker für IPFS-Distribution ## Lizenz MIT