potatium/docs/WEB_WALLET.md

Potatium Web-Wallet: Mindestumfang ab dem ersten funktionalen MVP

Vorhandene Dateien in web/wallet/ sind nur eine deaktivierte UI-Vorschau. Keine Schlüsselerzeugung, keine echten Daten oder Transaktionen vortäuschen.

Pflichtfunktionen

• Im Browser Wallet kryptografisch sicher erstellen und importieren, verschlüsselt exportieren und durch Wiederherstellung testen.
• Adresse/Kopieren, Balance aus echter verbundener Node, PTM senden mit Betrag/Empfänger/Fee/Bestätigung, empfangen, History und Transaktionsstatus.
• Wallet sperren/entsperren, verständliche Offline- und Fehlermeldungen, Netzwerkstatus.
• Private Keys, Seed-Phrases und Passwörter niemals ans Backend, an Miner oder in Logs/Telemetrie/Repo; Schlüsselmaterial nur im Browser, sichere gepinnte Bibliotheken, klar definierte Signing-Bytes.
• Verschlüsselter Storage, starke KDF, CSP, lokale HTTP-Vorschau nur 127.0.0.1/SSH-Forwarding, später HTTPS; Backup- und XSS-Tests.

Zusatzfenster und Gebühren (PoP v0.2)

• Miner startet immer ohne PTM mit kostenlosem Fenster 1.
• Die Web-Wallet kann (nach Festlegung des Protokolls) optional erlauben, für Fenster 2/3 eine eng begrenzte Gebühr zu bezahlen. Fixpreis und progressive Gebühr anhand der aus dem finalisierten Chain-State berechneten Mining-Gewinne der letzten ca. 90 Tage der zugeordneten Identität/Gruppe anzeigen. Die PoP-Fenstergebühr wird dem On-chain-Fonds zugeführt, nicht verbrannt (ADR 0007/0008).
• Nutzer sieht vor Autorisierung den konkreten Preis je Zusatzfenster, die maximale mögliche Gesamtausgabe, Gebührenrisiken und den Unterschied zwischen Qualifikations- und tatsächlicher Gewinnchance.
• Gebühr nur nach explizit signierter Freigabe für Chain-ID, Miner-ID, Runde, Fenster, Betrag, Ablauf und Nonce. Ggf. später vorsichtig modellierbares widerrufbares Budget statt unbeschränkter Dauerfreigabe. Miner benötigt keine Wallet-Secrets.
• Vor finaler Gebühren-/Signaturspezifikation alle Zahlungs-Aktionen deaktiviert lassen. Keine automatische Abbuchung nur wegen „Mining aktiviert“.
• Bestätigte Zahlung vor Fenster-Freigabe; Fehlschlag führt nicht zur Erstattung. Nach erfolgreichem Proof oder Fristende keine weitere Freigabe.

Sicherheitstests

Replay über Runden, falsche Chain-ID, abgelaufene Autorisierung, negative/überlaufende Beträge, divergierende Fee-Snapshots, manipulierte Fees/Proofs, Backup-/Recovery-Fehler und Offline-Stati. Browser-/Go-Kompatibilität der gewählten Signatursuite erst nach ADR garantieren.

Erweiterung: Operator-Wallet und Hub-/Worker-Mining (ADR 0005)

Die Registrierung eines Hub ist keine automatisch auf dem Server erzeugte Wallet. Die Wallet entsteht/importiert und signiert weiterhin nur im Browser; Hub/Worker erhalten keine Wallet-Seeds/-Spend-Keys. Alle legitimen PoP-Belohnungen des Hub und seiner Worker werden an eine vom Betreiber autorisierte Auszahlungsadresse gebucht. Normale Benutzer können zusätzliche Wallets führen; damit ändern sich weder Operator-Registry noch progressive 90-Tage-Gewinnhistorie.

Die Wallet muss den separaten Betrag für Worker-Aktivierung vor Runde und für Zusatzfenster 2/3 vor neuer Challenge anzeigen. Der Nutzer benötigt eine begrenzte vorab bewilligte Gebührenreserve oder ein widerrufbares Zweckmandat, damit Pi-Worker unbeaufsichtigt minen können, ohne die Wallet privat an Backend/Worker auszuhändigen. Gebühren-/Fonds-Historie (und echte separate Burns, falls vorhanden), Reserve-Restbetrag, Rückzahlung, Obergrenzen und Alarmmeldungen gehören ins Hub-Cockpit. Konkretes Signatur-/Reserveformat bleibt offen. Keine selbsttätigen Abbuchungen ohne klare, widerrufbare Autorisierung.

Wallet, Hub und Network Admin (ADR 0006)

Ein Hub hat eine eingebundene Browser-Wallet, aber keine Pflicht, für jede Full-Node-Instanz eine neue Geld-Wallet zu erzeugen. Eine Betreiber-Auszahlungsadresse kann für mehrere Hub-Miner und Worker gelten; mehrere Browser/Hubs übertragen private Schlüssel nicht automatisch. Ein Network Admin ist nur beobachtend, hat keine privaten Wallet-Schlüssel und keine Ausgaberechte. Wallet-Kennzahlen im Hub nur aus echter Chain-Antwort und nach clientseitiger Autorisierung anzeigen; „nicht verbunden“ statt ausgedachtem Guthaben. Siehe docs/COCKPITS_UND_MONITORING.md.

Wallet-Anmeldung ist nicht Mining-Zulassung (ADR 0008)

Wallet-Erstellung/Import funktioniert lokal ohne zentrale Benutzerregistrierung; Wallet-Spend-Keys verbleiben verschlüsselt auf Clientseite. Hub und Worker besitzen eigene technische Identitäten; signierte On-chain-Betreiber-/Mining-Freigabe ist eine eigenständige Berechtigung und wird vom geschützten Network Admin autorisiert. Ein registrierter Betreiber kann mehrere Hubs/Worker einer Auszahlungsadresse zuordnen. Hubs synchronisieren per verifiziertem P2P-Bootstrap ohne zentralen Anmelde-Server. Details: docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md und ADR 0008.