Potatium: Gesamthandbuch (aktueller Stand v0.2)

Stand: 25.10.2026. Dieses Dokument ersetzt die frühere v0.1-Beschreibung; es dokumentiert den abgestimmten Produktentwurf, keine fertig implementierte Kryptowährung.

1. Ziel und Identität

Potatium (PTM) ist eine eigenständige Hobby-Layer-1-Blockchain. Das Symbol ist das gewählte abstrakte goldene P/Kartoffellogo auf schwarzem Grund: assets/logo/potatium-ptm-logo.png. Der Mining-Arbeitstitel lautet Proof of Potato (PoP). Raspberry Pi 4 und alte Büro-PCs sollen mit kleinen echten kryptografischen Aufgaben teilnehmen können, ohne GPU-/ASIC-Wettrüsten. Es gibt keine Absicht zu ICO, Börsenlisting oder Renditeversprechen. Nur wertlose private Test-PTM verwenden, bis Sicherheit und rechtliche Fragen geklärt sind.

2. Entwicklungsstand und Umgebung

Fertig ist das Projektgerüst mit Go-Paketen, doctor.sh, lokaler statischer Wallet-Vorschau und Documentation; keine echte Blockchain, Wallet-Funktion, Miner-/Validatorlogik.
Nutzer meldete erfolgreichen scripts/bootstrap_workdir.sh/scripts/doctor.sh unter Ubuntu 26.04.1, Go 1.27.3, Git 2.53.0 mit go test ./..., go vet ./... und Syntaxprüfung. Zustand des tatsächlichen Gitea-Repos/Codex-Fortschritts muss vor Änderungen eingesehen werden.
Infrastruktur: unprivilegierter Proxmox-Ubuntu-26.04-LTS-LXC potatium-dev, 4 vCPU, 4 GB RAM, 40 GB Disk initial. Benutzer potatium, verbindlicher Workdir /home/potatium/src/potatium.
IDE: VS Code lokal über Remote-SSH + Go/Codex. Git-Monorepo (privates Gitea), keine IDE/kein Docker-in-LXC erforderlich.

3. Zielarchitektur

Browser Web-Wallet (lokales Signing, nur signierte Tx an API)
                  |                       Raspberry Pi/Alt-PC
          Potatium RPC/API <-------------- potatium-miner
                  |
   Go State Machine: Accounts, Transfers, PoP, Mint/Burn, Gebühren
                  |
      ABCI++ Anwendung (eigene Go-Implementierung)
                  |
        CometBFT Validator / P2P Netzwerk
                  |
    weitere Validatoren mit je eigener Datenbank

CometBFT + ABCI++ ohne Cosmos SDK ist eine bewusst gewählte Startpräferenz, noch gegen aktuelle APIs zu verifizieren. PoP-Miner erzeugen keine CometBFT-Blöcke. Weitere Programme: potatiumd (Node), potatium-miner (eigener Miner), potatium-cli (CLI), web/wallet (Web-GUI). Erst ein lokales Testnet, dann ein privates Mehrhost-Testnet; keine öffentlichen API-Ports.

4. PoP v0.2: Prinzip wurde abgestimmt

Eine Mining-Runde ist nicht ein Blockchain-Block. Sie enthält drei hintereinander freigegebene Fenster. Die genaue Block-/Zeitplanung ist noch offen. Erst zum Fensterstart wird die zugehörige Rechen-Challenge nutzbar; Belege sind an Chain-ID, Fenster, Runde und Miner-ID gebunden.

Fenster 1: Jeder zugelassene Miner darf kostenlos eine kurze, wirklich zu lösende PoW-Aufgabe mit endlichem zulässigen Nonce-Raum bearbeiten.
Fenster 2: Wenn der Miner noch keinen Proof gefunden hat, darf er nach bestätigter Zahlung fix + progressiv eine neue unabhängige Herausforderung bearbeiten.
Fenster 3: Ohne bisheriges Ticket und nach Freischaltung von Fenster 2 kann er für höhere fixe und progressive Kosten eine dritte neue Aufgabe bearbeiten.
Ein Ticket pro freigegebener Mining-Identität je Runde maximal. Nach einem erfolgreichen Proof ist Schluss; weitere Zahlungen/Hochleistung bringen kein weiteres Ticket. Keine Garantie auf ein Ticket nach drei Versuchen.
Spätere Ziehung: Die akzeptierte Ticketmenge wird zuerst bindend festgeschrieben; nach Kenntnis einer späteren überprüfbaren Zufallsquelle (drand als Kandidat) bestimmt jeder Validator denselben Gewinner und nur der regelkonforme Mint ist erlaubt.

Erfolgschancen (bloßes Rechenbeispiel)

Bei völlig unabhängigen vollständigen Fenstern mit je p = 70 % auf einen gültigen Hash beträgt P(mindestens ein Erfolg) nach 1/2/3 Fenstern 70 / 91 / 97,3 %. Der Mehrwert nimmt ab (+21 bzw. +6,3 Prozentpunkte). Dies ist nicht die finale Gewinnauslosung und kein beschlossener Schwierigkeitswert. Tatsächliche Pi-/Desktop-Zeit, Cache, Netz und Einreichungsfristen beeinflussen die praktische Chance.

Gebühren und Fairness

Die abgelehnte Idee „Gebühr pro aktuellem Wallet-Guthaben“ lässt sich durch Wegüberweisen von PTM manipulieren. Stattdessen: gebührenrelevant sind die PoP-Gewinne der zugeordneten Mining-Identität/Betreibergruppe über ein gleitendes Fenster von ungefähr 90 Tagen. Langjährige Miner haben keinen lebenslangen Malus; alte Gewinne fallen mit der Zeit heraus.

Fenster 2 = Basisbetrag2 + Progressive(90-Tage-Ertrag); Fenster 3 = Basisbetrag3 + stärkerer progressiver Anteil. Alle exakten Prozentsätze, Stufen, Beträge und Rundungsregeln sind offen. Bei Erfolg in Fenster 1 oder 2 fallen spätere Gebühren nicht an; Zusatzgebühren im Misserfolgsfall werden nicht erstattet.

Zusatzgebühren werden verbrannt, normale Überweisungsgebühren sollen die Validatoren finanzieren (Aufteilungsregeln noch offen). Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.

Wichtige Grenzen

Sybil-Problem: eine kryptografische Node-ID beweist keine eigene physische Maschine oder Person. Anfangs manuell freigegebene Registrierungsidentitäten und Betreiberzuordnung. Mehrfachidentitäten müssen organisatorisch kontrolliert werden.
Kein Nachweis erfolgloser Arbeit: Validatoren sehen gültige Hash-Treffer, nicht echte CPU-Minuten ohne Treffer. Endliche Nonce-Räume begrenzen erlaubte Treffer pro Identität.
Hardware: schnellere Rechner sind früher fertig; beim Pi 4 müssen endliche Aufgaben in ihrem Fenster zuverlässig bearbeitbar sein. Vollkommene Hardwaregleichheit lässt sich nicht beweisen.
Zufall/Zensur: Validatoren könnten Aufnahme von Proofs/Gebühren behindern, Beacon-Ausfall kann Ziehung verzögern. Fristen und Fallback vor Mainnet präzisieren.
Budget: Gebühren für zusätzliche zufallsabhängige Chancen sind kein harmloses Detail, mögliche Glücksspiel-/Finanzrechtsfolgen. Vorläufig ausschließlich Privat-/Testnet ohne echten Wert.

5. Coin und Transaktionen: offen

Coin-Menge, Genesis-Verteilung, kleinste Einheit/Dezimalstellen, Belohnung, Halbierungen/Emission, Standardgebühren, Blockzeit, RNG-Beacon, Signatur-/Adressformat und Datenbank müssen vor konsenskritischem Code entschieden werden. Zahlen aus Chat-Beispielen (10 Mio, 1 PTM je Runde, 12 Blöcke, 10 Sekunden, Gebührenstaffel oder 70 %) nicht als Default übernehmen. Saldos ausschließlich in ganzen Basis-Einheiten, Replay-Schutz mit Nonce, Signatur und Chain-ID, deterministische Aufträge.

6. Web-Wallet ab erster funktionaler MVP-Version

Wallet lokal und sicher erstellen/importieren/verschlüsselt exportieren und entsperren/sperren.
Korrekte PTM-Adresse anzeigen/kopieren, Balance/Netzwerkverbindung, PTM senden inkl. Fee-Preview und Bestätigung, empfangen, Verlauf mit echtem Tx-Status.
Privater Schlüssel und Seed niemals an API, Node, Miner oder Logs; Browser-signierte Transfers; sichere, getestete Kryptobibliotheken und eindeutig definierte signierbare Bytes.
Für kostenpflichtige Fenster: gültigen Gebührenmaßstab, Spend-Limit, Maximalpreis und explizite Freigabe anzeigen. Solange die sichere Autorisierung nicht implementiert ist: Zusatzfenster deaktiviert.
Keine erfundenen Guthaben, Fake-Transaktionen oder als sicher deklarierte ungetestete Wallet-Demos. Aktuelles web/wallet ist nur statisches UI-Gerüst.

7. Repository und Verfahrensregeln

AGENTS.md ist Codex-Leitlinie; docs/PROJEKTPLAN.md, docs/PROTOKOLL_ENTWURF.md, docs/POP_FAIRNESS_UND_GEBUEHREN.md, docs/ROADMAP.md und docs/decisions/ sind der aktuelle Stand. Git-Branches klein halten, Änderungen nicht ungefragt pushen oder echte Schlüssel committen. Alle wichtigen Protokollentscheidungen als ADR mit Gründen, Alternativen und Folgen; die letzte akzeptierte ADR hat Vorrang gegenüber älteren Entwurfsbeispielen.

8. Nächste Schritte

Update anwenden und Repo-Änderungen prüfen, testen, committen.
Mit Codex den M1-Parameterblock bearbeiten: Tokenomics und Tx-Signaturen, dann Gebühren-/Fairness-Simulation für mindestens 5/10/20/50 Miner samt Erwartungswert/Kosten, Benchmark auf Pi 4.
Finale konsenskritische Regeln einzeln per ADR bestätigen, erst dann implementieren.
Ledger und funktionale Web-Wallet parallel, danach CometBFT-Integration und PoP-Logik.

9. Nicht vorspiegeln

Ein sauberes Go-Gerüst und eine HTML-Oberfläche sind noch keine nutzbare Blockchain oder Wallet. Der neue Gebührenentwurf ist dokumentiert und simulationsbedürftig, nicht implementiert.

8.8 KiB Raw Blame History