# Proof of Potato: Fairness, wirtschaftliche Anreize und Gebühren (v0.2)

Diese Seite erläutert das **inhaltlich angenommene Drei-Fenster-Modell**; Zahlen sind ausdrücklich nur Forschungsparameter. Verbindlicher Protokollcode darf erst nach Simulation, Pi-Benchmark und finalem Parameter-ADR entstehen.

## Warum drei Fenster?

Die Blockchain erzeugt laufend Blöcke; eine **Mining-Runde** fasst mehrere Blöcke zusammen und hat **drei zeitlich nacheinander freigegebene Aufgabenfenster**. Es gibt **nicht** ein Los pro Block. Eine freigegebene Miner-Identität kann durch eine erfolgreiche Aufgabe **genau ein** Ticket für die spätere Gewinner-Lotterie erwerben.

- Fenster 1: kostenlos, echte begrenzte Rechenarbeit, keine Erfolgsgarantie.
- Fenster 2: nur wenn noch kein Ticket, erst progressive + fixe Gebühr, dann zweite neue Aufgabe.
- Fenster 3: nur wenn weiterhin kein Ticket, höhere progressive + fixe Gebühr, dann dritte neue Aufgabe.
- Nach erfolgreichem Proof: stoppen, Ticket festhalten; keine zusätzlichen Tickets/Losgewichte durch schnellere CPU oder weitere Zahlungen.
- Ein Nutzer kann freiwillig maximal 1, 2 oder 3 Fenster freigeben. Mining darf ohne Schlüsselzugriff aufs Wallet starten; kostenpflichtige Fenster brauchen gesonderte Wallet-Autorisierung.

## Beispielrechnungen zur Qualifikation, **keine Produktparameter**

Angenommen, jedes vollständig und rechtzeitig bearbeitete Fenster hat unabhängig dieselbe Erfolgschance `p = 0,70`:

| Genutzte Fenster (max.) | Qualifikationschance | Marginaler Mehrwert |
|---|---:|---:|
| 1 | 70,0 % | Basis |
| 2 | 91,0 % | +21,0 Prozentpunkte |
| 3 | 97,3 % | +6,3 Prozentpunkte |

Mathematisch: `P(Ticket bis Fenster k) = 1 - (1 - p)^k`. Das sind **keine direkten Lotterie-Gewinnchancen**; diese hängen außerdem von den anderen qualifizierten Teilnehmern ab. Wenn für einzelne Fenster andere Schwierigkeitswerte gelten, ist die Formel entsprechend anzupassen.

Bei normalem Miner-Verhalten fallen Gebühren für Fenster 2 **nach erfolglosem Fenster 1**, für Fenster 3 **nach zwei erfolglosen Fenstern** an. Konsensseitig ist aber nur nachweisbar, dass **bis dahin kein Ticket angenommen** wurde, nicht dass der Miner erfolglos gerechnet hat. Fenster 3 setzt zusätzlich voraus, dass Fenster 2 zuvor bezahlt/freigeschaltet wurde. Wenn beide optionalen Preise `F2` und `F3` sind, gilt im Beispiel bei vollständigem Durchspielen eine **erwartete Gebühr** `E[F] = (1-p) * F2 + (1-p)^2 * F3`. Die *maximal mögliche* Zahlung ist `F2 + F3`. In Simulationsanalysen strikt unterscheiden.

## Gebührenidee und progres­sive Basis

**Nicht das Wallet-Guthaben** als alleinige Bemessungsgrundlage nehmen: Coins können auf andere Wallets verschoben werden. Stattdessen die konsensgeprüften PoP-Gewinne, die der **registrierten Mining-Identität oder Betreibergruppe** in einem gleitenden Betrachtungszeitraum (Ziel: ca. 90 Tage) zugeordnet wurden. Dadurch entsteht kein dauerhafter Malus nur wegen langen Mitwirkens: ältere Gewinne fallen wieder aus der Bemessung heraus.

Entwurf als mathematische Struktur, nicht als feste Zahlen:

```text
R = zugeordnete, finalisierte PoP-Bruttogewinne im Lookback
P(R) = progressive, stückweise lineare Gebühr auf R
F2(R) = fixer Grundbetrag 2 + P(R)
F3(R) = fixer Grundbetrag 3 + Multiplikator3 * P(R)
```

`Grundbetrag3 > Grundbetrag2 >= 0`, `Multiplikator3 > 1`. Der genaue progressive Tarif darf nicht in Float-Code überführt werden; implementationstechnisch Integer-Basis-Einheiten + gebrochene Rationalwerte mit definiertem Runden verwenden. Entscheide, ob Tarif auf **marginale Stufen** oder pauschal auf die gesamte Summe eines Bandes angewandt wird. Marginalstufen vermeiden Sprungstellen.

### Forschungswerte zum Ausprobieren, nicht beschlossen

- Pro Aufgabe beispielhaft `p=70 %` bei vollständig abgesuchtem endlichem Nonce-Raum.
- Nur in einer **Simulation**: fixer Aufpreis Fenster 2 von `0,001 PTM`, Fenster 3 von `0,003 PTM` und progressive Marginalsätze 0,005 % (0–10 PTM), 0,020 % (10–100 PTM), 0,050 % (>100 PTM); für Fenster 3 doppelte Progression. Die Werte können viel zu hoch/niedrig sein.
- Beispielhafte Bruttobelohnung 1 PTM, Netzwerkgrößen 5/10/20/50 zugelassene Miner.

Die Beispielwerte sind bewusst **nicht** in der produktiven Software oder in der Genesis-Konfiguration definiert.

## Kostenverwendung

- Zusatzfenster-Gebühren: auf konsenskritische Weise **burnen**, weder an Miner noch an Validatoren auszahlen.
- Normale Transaktionsgebühren: als Validator-Finanzierung vorgesehen; konkrete, auch auf Rundungsreste bezogene Verteilung bleibt offen.
- Brennen reduziert den ausgebbaren Umlauf. Eigene Zähler für `minted_total` und `burned_total` verhindern falsche Emissionsannahmen. Keine verlässlichen Preis-/Wertbehauptungen.

## Schutzmechanismen und Angriffe

1. **Guthaben-Verschiebung:** Lookback nach Mining-Belohnungen statt aktuell sichtbarer Wallet-Balance; **kein** automatischer Reset durch Transfer.
2. **Mehrfach-Identitäten:** Betreiber kann mehrere VMs/Schlüssel nutzen. Eine Node-ID ist nicht eine physische Maschine. Manuelle und auditierbare Registrierung plus Gruppenregel nötig. Noch nicht kryptografisch gelöst.
3. **Erfolglos gerechnet ≠ nachweisbar:** nur gültige Lösungs-Hashes beweisbar; eine Node kann nicht beweisen, wie viele erfolglose Versuche sie hatte. Endlichen pro-ID-Nonce-Raum und Ticketlimit prüfen.
4. **Hardware:** leistungsfähige Geräte können schneller alle erlaubten Versuche abschließen. Zeitfenster groß genug für Raspberry Pi 4, echte Messungen auf schwacher Hardware, CPU-Limit und Netzwerklatenz berücksichtigen.
5. **Validator-Zensur und Fristen:** Gebühren und Proofs benötigen verbindliche Aufnahme-/Commit-Regeln. Nachträgliche Proofs und Gebühren aus falschem Fenster ablehnen. Blockchain-Zeit statt lokaler `time.Now()` als Konsensgrundlage.
6. **Zufall:** Liste der Tickets vor Veröffentlichung des deterministisch überprüfbaren Beacons fixieren, sonst Manipulationsgefahr.
7. **Wirtschaft:** immer mindestens das kostenlose Fenster; Zusatzfenster möglicherweise finanziell nachteilig. UI muss Gesamtmaximum und nicht nur Erwartungswert zeigen.
8. **Budgetvorteil bleibt möglich:** Auch wenn reiche Miner durch höhere **eigene Mining-Gewinne** mehr zahlen, kann ein vermögender Neueinsteiger sich Zusatzgebühren leichter leisten. Dieses Modell dämpft Vorteile, schafft aber keine völlige Vermögensneutralität; Ticketlimit, eng begrenzte Fenster und Betreiberregistrierung bleiben nötig.
9. **Automatisierung:** keine Wallet-Private-Keys im Miner. Kostenpflichtige Freigaben müssen runden-, fenster-, identitäts-, chain- und betragsgebunden, widerrufbar und wiederholungsfest sein. Bis zu einer sicheren Lösung nur explizite Nutzerfreigabe pro Vorgang.
10. **Recht:** Gebühren für bessere Chancen auf überwiegend zufallsabhängige Preise können Glücksspielrecht betreffen. Private Tests nur mit wertlosen PTM; rechtliche Prüfung vor handelbarer/öffentlicher Nutzung.

## Nächste Akzeptanzkriterien für M1

- Fairness-Simulation mit Szenarien 5/10/20/50 Miner, verschiedenen 90-Tage-Mining-Erträgen und Teilnahme-Modi 1/2/3 erstellen.
- Marginale Erhöhung der echten Gewinnerwartung und erwartete/maximale Gebühren für alle Profile ausgeben, nicht nur Ticketqualifikation.
- Pi-4-Benchmark mit Kandidaten für Nonce-Raum und echten Latenzen; CPU-, Speicher- und Stromlimits.
- In einem weiteren ADR konkrete Formeln, Rundungs- und Sicherheitsregeln **nach** Nutzerfreigabe akzeptieren.