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 progressive 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

Guthaben-Verschiebung: Lookback nach Mining-Belohnungen statt aktuell sichtbarer Wallet-Balance; kein automatischer Reset durch Transfer.
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.
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.
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.
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.
Zufall: Liste der Tickets vor Veröffentlichung des deterministisch überprüfbaren Beacons fixieren, sonst Manipulationsgefahr.
Wirtschaft: immer mindestens das kostenlose Fenster; Zusatzfenster möglicherweise finanziell nachteilig. UI muss Gesamtmaximum und nicht nur Erwartungswert zeigen.
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.
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.
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.

7.4 KiB Raw Permalink Blame History Unescape Escape