docs: update Proof of Potato model to v0.2

docs/PROTOKOLL_ENTWURF.md

@@ -1,44 +1,73 @@
-# Potatium Protokoll v0.1 – Entwurf, nicht freigegeben
+# Potatium: Protokollentwurf v0.2 (nicht implementiert)
 
-## Bestätigte Produktziele
+**Stand 25.10.2026.** Die Grundrichtung des Mining-Modells ist abgestimmt. Sämtliche konkreten Zahlen und konsenskritischen Details sind bis zur Simulation, Pi-Messung und einem bestätigten ADR **offen**. `docs/decisions/0003-pop-fenster-und-gebuehren.md` hält den Grundsatzentscheid fest.
 
-- Neue eigenständige Blockchain mit nativer Kryptowährung Potatium (PTM).
-- Leichte echte PoW-Aufgabe pro Miner/je Runde; pro **freigegebener Node-ID** maximal **ein** qualifiziertes Ticket pro Runde.
-- Ein verifizierbarer Gewinner wird aus den rechtzeitig qualifizierten Tickets ausgelost; PTM-Emission als konsensgeprüfte Blockregel.
-- Kleine Hardware (Ziel: Raspberry Pi 4) muss sinnvoll mitmachen können; mehr physische Geräte dürfen mehr Node-Identitäten haben. Registrierung zunächst manuell.
-- Validatoren bestätigen Blöcke unabhängig von Lotteriegewinnern.
-- Webbasiertes Wallet mit Basisfunktionen ab erstem funktionalen MVP.
+## Beschlossene Produktprinzipien
 
-## Noch zu entscheiden
+1. Potatium ist eine eigenständige Hobby-L1 mit nativen PTM (Ticker vor externer Nutzung prüfen), Go-Kern, Web-Wallet ab erstem funktionalem MVP. Kein Ethereum-Token.
+2. Blockchain-Validatoren (geplant: CometBFT + eigene ABCI++-App) bestätigen Blöcke; PoP-Miner bestimmen weder Blockreihenfolge noch Validator-Konsens.
+3. **Eine Mining-Runde hat drei nacheinander freigegebene Mining-Fenster.** Die Zahl der Consensus-Blöcke je Runde/Fenster ist noch offen; alte Beispiele „12 Blöcke/120 Sekunden“ sind keine Entscheidung.
+4. **Fenster 1 ist kostenfrei.** Fenster 2 und 3 sind freiwillig, kosten jeweils eine **fixe Grundgebühr plus progressive Komponente** und werden nur solange kein gültiges Ticket angenommen wurde gebraucht.
+5. Die Gebührenbasis ist die **nachweisbare, einer registrierten Mining-Identität/Betreiberzuordnung zugerechnete PoP-Gewinnsumme der zurückliegenden ca. 90 Tage**, **nicht** das gerade sichtbare Wallet-Guthaben. Genaues Zeit-/Höhenfenster und Verbundidentitäten noch spezifizieren. Langjährige Aktivität an sich darf keinen permanenten Bonus/Malus auslösen.
+6. Progression: Fenster 3 soll teurer sein und zugleich **deutlich geringeren zusätzlichen Nutzen** als Fenster 2 bieten. **Keine unlimitierten Zusatzchancen, kein Kauf einer weiteren Identität.** Konkrete Tarife und Erfolgswahrscheinlichkeiten erst nach Simulation entscheiden.
+7. Ein qualifizierter Miner erhält **maximal ein Ticket** je Runde. Nur vollständig gültige Proofs aus zulässigen Fenstern zählen. Nach dem ersten gültigen Proof endet die Teilnahme dieser Identität für diese Runde.
+8. Zusatzfenster-Gebühren werden **verbrannt** (aus dem spendierbaren Umlauf entfernt). Normale Transaktionsgebühren sollen die Validatoren finanzieren; Zuteilungsmechanik ist noch offen.
+9. Ohne PTM kann jede zugelassene Identität an Fenster 1 teilnehmen. Gebühren und Mining-Erfolg dürfen keine Gewinnergarantie erzeugen.
+10. Registrierte Identität ≠ nachweislich einzigartige physische Maschine oder Person. Für das kleine private Netzwerk zunächst manuelle Freigabe, Audit und Sperrmöglichkeit. Mehrere Geräte/Identitäten und gemeinsamer Betreiber müssen gesondert geregelt werden.
 
-| ID | Parameter | Aktueller Stand / Anforderung |
-|---|---|---|
-| P-01 | Maximale Coin-Menge | OFFEN, keine Annahme 21 Mio. |
-| P-02 | Anfangsbestand/Genesis | OFFEN; Starthöhe/Valve der Testcoins festlegen |
-| P-03 | Dezimalstellen | OFFEN; alle Werte ganzzahlig in Basis-Einheiten |
-| P-04 | PoP-Emissionsplan | OFFEN; nicht automatisch 10 PTM |
-| P-05 | Rundenlänge | OFFEN; nicht automatisch 120 s |
-| P-06 | Konsens-Blockzeit | OFFEN; getrennt von Mining-Runden |
-| P-07 | Proof | SHA-256 als Prototyp-Kandidat, kalibrieren auf Raspberry Pi |
-| P-08 | Mining-Difficulty | feste/zeitbasierte Kalibrierung erst nach Benchmarks |
-| P-09 | Teilnehmerliste | Höhe/Abschlussprozess und Eligibility-Fenster offen |
-| P-10 | Zufallsbeweis | drand als Option; Ausfallverhalten offen |
-| P-11 | Schlüssel und Adresse | Signaturalgorithmus, Serialisierung, Recovery offen |
-| P-12 | Transaction Fees | zunächst niedrige Gebühren oder Testnet-Fee-Regel offen |
-| P-13 | Validator-Modell | CometBFT fester Satz zu Beginn als Architekturpräferenz |
-| P-14 | Registry-Administration | Autorisierung, Removal, Transparenz und Verfahren offen |
+## Ablauf einer Mining-Runde (logisches Zustandsmodell)
 
-## Vorgesehene Invarianten
+```text
+Runde R beginnt; Identitäten / Regeln / Gebührenbasis werden eingefroren
+  Fenster 1: kostenlose, identitätsgebundene PoW-Challenge
+       | gültiger Proof? -> 1 Ticket; fertig
+       | andernfalls
+  Fenster 2: vorher autorisierte, bestätigte Gebühr verbrennen
+       | neue, zuvor unbekannte PoW-Challenge; Proof? -> 1 Ticket; fertig
+       | andernfalls
+  Fenster 3: höhere Gebühr vorab verbrennen (Fenster 2 muss zuvor freigeschaltet sein)
+       | neue PoW-Challenge; Proof? -> 1 Ticket; fertig
+       | andernfalls kein Ticket
+  Fristende: akzeptierte Tickets endgültig fixieren
+  Später: unabhängige, überprüfbare Zufallsquelle belegen
+  Gewinner deterministisch bestimmen und regelgerecht PTM erzeugen
+```
 
-1. Jeder akzeptierte Zustandsübergang deterministisch und reproduzierbar.
-2. Keine Wallet darf Coins ohne gültige Protokoll-Ausgabe erzeugen.
-3. Ein Ticket pro registrierter Node-ID pro Runde; Signatur/Nonce bindet es an Runde, Chain-ID und Challenge.
-4. Ein Los nur dann, wenn PoW und Frist nach überprüfbaren Regeln erfüllt sind.
-5. Ziehungsinput wird **vor** dem entscheidenden späteren Zufallswert festgeschrieben; Gewinnerberechnung vollständig nachprüfbar.
-6. Wenn keine gültigen Tickets vorliegen, gilt eine ausdrücklich definierte Nicht-Auszahlung/Carryover-Regel (noch zu beschließen).
-7. Keine Node-ID beweist eine einzigartige Hardware; Kryptografie löst das Sybil-Problem nicht allein.
-8. Gleiche Chance **unter allen qualifizierten Losen**; nicht garantierte gleiche Qualifikationschance zwischen CPUs.
+*In einzelnen Fenstern darf ein Miner innerhalb eines **begrenzten Nonce-Raums** leichte SHA-256-Arbeit leisten. Der Node kann gültige Treffer und Zeitfenster prüfen, **nicht**, wie viele erfolglose Hashes tatsächlich gerechnet wurden; das Protokoll kann nur „kein Ticket angenommen“ kontrollieren. Für Fenster 3 ist vorherige kostenpflichtige Freischaltung von Fenster 2 nötig, nicht ein technisch unmöglich beweisbarer Misserfolg. Neue Fensterchallenges müssen beim vorigen Fenster nicht im Voraus berechenbar sein.*
 
-## Testanforderungen
+## Gebühren und Emission: Sicherheitsregeln
 
-Property-Tests für Ticket-Limit und Emission, Fuzzing für Parser und Eingaben, Replay/Double-Spend, deterministische Blöcke, RNG-/Commit-Tests, Snapshot/Restart, Pi-Benchmarks und Multi-Validator-Ausfalltests. Jede Definition einer Regel bekommt reproduzierbare Testvektoren.
+- Jede Gebühr besteht aus einer **ganzzahligen Basis-Einheiten**-Berechnung, mit expliziten Rundungs- und Überlaufregeln. Keine Float-Werte in konsenskritischen Funktionen.
+- **Gebühren-Snapshot vor der Runde** aus finalisiertem Chain-State; exakt definierte Zuschreibung von Mining-Belohnungen zu Identitäten und bei Bedarf gemeinsamer Betreibergruppe. Wallet-Transfers dürfen die Zuschreibung nicht zurücksetzen.
+- Fenster-Freischaltung nur nach bestätigter, replaygeschützter **Gebührenautorisierung**. Falls keine gültige Zahlung vorliegt: kostenloses Fenster bleibt nutzbar, das kostenpflichtige Fenster nicht.
+- Keine Rückerstattung bei erfolglosem Fenster. Ob nach einem bereits gewonnenen Ticket überhaupt Gebühren mehr eingereicht werden dürfen: **nein**.
+- Kein Miner-/Validatorprozess erhält ungefragt den privaten Browser-Wallet-Schlüssel. Spätere Komfortzahlung nur über eingeschränkte, widerrufbare, runden- und betragsbegrenzte Signaturfreigabe mit definierten Nonces; **nicht implementiert**.
+- `minted_total`, `burned_total` und verfügbare Guthaben getrennt, deterministisch und integerbasiert führen; Versorgungslimit und Gebührenbehandlung festlegen.
+- Gewinnerauswahl erst nach Commitment der Ticketmenge, mit **später bekannt werdender verifizierter** Zufallsquelle, etwa nachweisbarem drand-Beacon. Beacon-Ausfälle, Reorgs, Verzögerung und Manipulation definieren.
+- Wenn niemand qualifiziert ist: **kein Gewinner**; Emission/Carryover und Timeout weiterhin offen.
+
+## Sicherheitsgrenzen und zu prüfende Angriffe
+
+- **Sybil:** mehr echte Geräte oder zugelassene Zweit-Identitäten verschaffen mehr Chancen; Geräteerkennung ist keine beweisbare Personenprüfung.
+- **Identity-Splitting:** Betreiber könnte Gewinne/Identitäten aufteilen und Progression umgehen. Registry und Betreiber-Zusammenfassung nur organisatorisch für Hobby-Testnet, nicht mathematisch perfekt.
+- **Zeitfenster/HW:** Schnelle CPUs können den begrenzten Nonce-Raum früher fertigstellen. Nur reale Pi-4-Benchmarks und großzügige Fristen können einen merklichen Vorteil klein halten, nicht ausschließen.
+- **Zensur:** ein Validator darf nicht unbemerkt rechtzeitig gesendete Gebühren/Proofs verdrängen; konkrete Gegenmaßnahmen und Finalitätsfristen fehlen noch.
+- **Anreize:** progressive Gebühren können für manche Nutzer wirtschaftlich unvernünftig werden, bei kleinem Netzwerk kostenpflichtige Fenster aber dominieren. Simulation für 5/10/20/50 Miner und verschiedene Vermögens-/Erfolgsklassen nötig.
+- **Recht:** Zahlungen für höhere Chancen auf zufallsabhängige Gewinne können Glücksspiel-/Finanzrecht berühren. Vor öffentlicher Nutzung juristisch prüfen; vorerst nur privates Testnet ohne wirtschaftlichen Wert.
+
+## Nicht beschlossene Parameter
+
+| ID | Parameter / Festlegung noch nötig |
+|---|---|
+| P-01 | Maximale Gesamtmenge, Basis-Einheit/Dezimalstellen, Genesis-Zuteilung |
+| P-02 | Emission/Belohnung pro Ziehung, Emissionsobergrenze, leere Runden, Halving |
+| P-03 | Blockzeit, Anzahl Consensus-Blöcke je PoP-Runde und je Fenster |
+| P-04 | PoW-Hash-Vorlage, Nonce-Raum, Schwierigkeitsziel/Erfolgsrate, Pi-4-Benchmark |
+| P-05 | Finale Gebührenformel, Fixbetrag, Marginalstufen, Multiplikator Fenster 3, Mindest-/Maximalbetrag und Rundungsregel |
+| P-06 | Exakte Bestimmung „letzte 90 Tage“ (Zeitstempel vs. Blockhöhen) und Zuordnung der Gewinne zu Betreibergruppen |
+| P-07 | Signierte Gebührenfreigabe, Zahlungsreihenfolge, Ablauf/Nonce, Fallback, Verwahrung und Gebühren bei Reorg |
+| P-08 | Signatur-/Adressformat, Wallet-Recovery und Tx-Serialisierung |
+| P-09 | Proof-Einreichungs- und Finalitätsfristen, RNG-Quelle/Fallback, Ticket-Commit, Auszahlung |
+| P-10 | Registry-Administration, Zweitgeräte-Regel, Validator- und normale Gebührenverteilung |
+
+**Wichtig:** Zahlen aus älteren Diskussionen wie 70/91/97,3 %, 1 PTM Belohnung, 10 Mio. PTM, 10-s-Blockzeit oder 0,001-PTM-Grundkosten bleiben ausschließlich **Rechenbeispiele**. Sie sind nicht implementiert, beschlossen oder für öffentliche Nutzung freigegeben.