# Potatium Protokoll v0.1 – Entwurf, nicht freigegeben

## Bestätigte Produktziele

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

## Noch zu entscheiden

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

## Vorgesehene Invarianten

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.

## Testanforderungen

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.