potatium/docs/POP_FAIRNESS_UND_GEBUEHREN.md

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:

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.