# Potatium: Projektplan v0.2

**Stand:** 25.10.2026. Maßgeblich sind Repositorydateien/ADRs; Änderungen durch Codex oder Git in deinem LXC haben Vorrang. Die neue PoP-Richtung ist als Prinzip akzeptiert, Zahlen sind weiter offen.

## Ziel

Potatium (PTM, vor öffentlicher Nutzung Name/Ticker prüfen) ist eine **eigene, kleine Hobby-Layer-1-Blockchain**, kein ERC-20-Token und keine Anlageempfehlung. Geplant sind ressourcensparsame Miner auf Raspberry Pi 4/5 und älteren PCs sowie eine browserbasierte Wallet **bereits im ersten funktionalen MVP**. Das gewählte Logo bleibt `assets/logo/potatium-ptm-logo.png` (goldenes abstraktes P/Kartoffelzeichen auf Schwarz).

## Entwicklungsumgebung und Git

- Proxmox **unprivilegierter Ubuntu Server 26.04 LTS LXC** `potatium-dev` (Basis 4 vCPU, 4 GB RAM, 40 GB Speicher, bei Bedarf mehr).
- Benutzer `potatium`, **einziger** Arbeitsordner `/home/potatium/src/potatium`. Keine Duplikate in `~/workdir`.
- IDE: VS Code auf dem lokalen Rechner via Remote-SSH, OpenAI Codex, Go-Plugin; keine GUI im Container.
- Monorepo auf privatem Gitea-Remote; `main` plus kleine Feature-Branches, kleine nachvollziehbare Commits. Keine Zugangsdaten, Wallet-Keys oder Chain-State in Git.
- Ubuntu-Go-Skripte und Tests bereits als Gerüst vorhanden; aktuelle Remote-/Push-/Codex-Zustände vor Aussagen oder Änderungen prüfen.
- Keine PostgreSQL- oder Docker-in-LXC-Voraussetzung. Alle API-Server zunächst nur `127.0.0.1`, Zugriff über SSH-Portweiterleitung.

## Technisches Modell (Plan, noch nicht vollständig bestätigt)

- Go (`linux/amd64`, `linux/arm64`) für `potatiumd`, `potatium-miner` und `potatium-cli`.
- Konsenskandidat: **CometBFT** als Validator/P2P mit eigener deterministischer ABCI++-Applikation, zunächst **ohne Cosmos SDK**; echte Versionen prüfen. Validatoren betreiben Blockkonsens, Miner qualifizieren sich für PTM-Lotterie; Rollen getrennt.
- Eigenständiger eingebetteter konsensdeterministischer Zustand, jedes Validatorgerät speichert selbst; keine geteilte zentrale SQL-Datenbank.
- Konten/Transaktionen/Schlüssel-/Adressschema einschließlich Nonce und Wallet-Backup noch präzise zu definieren.
- Web-Wallet-MVP: Browser-Keygenerierung/-Signatur, verschlüsselter lokaler Speicher, Erstellen/Import/Export/Backup, Adresse/Balance, Senden/Empfangen, Gebühren, History/Status, Sperren/Entsperren; **keine** Private Keys an Backend, immer echte Chain-Daten oder „nicht verbunden“.
- Startgerüst beinhaltet nur statischen Web-Wallet-UI-Entwurf, CLI/Node/Miner sind nicht produktive Programme.

## Proof of Potato: Richtungsentscheid v0.2

**Neue verbindliche Produktprinzipien** stehen in `docs/decisions/0003-pop-fenster-und-gebuehren.md` und `docs/PROTOKOLL_ENTWURF.md`.

Eine PoP-Runde enthält **drei hintereinander liegende Aufgabenfenster** mit einer neuen, pro Identität/Chain/Runde/Fenster gebundenen, begrenzten PoW-Aufgabe. Fenster 1 ist kostenlos, Fenster 2 und 3 freiwillig und **solange kein gültiges Ticket vorliegt** gegen vorherige bestätigte Gebühren nutzbar. Die Gebühren enthalten jeweils fixe Kosten und eine progressive Komponente. Als Maßstab dienen finalisierte PoP-Gewinne der letzten ungefähr 90 Tage pro registrierter Identität/Betreibergruppe, **nicht die aktuelle Wallet-Balance**; alter Erfolg fällt aus der Bemessung heraus, kein permanent fortschreitender Langzeitvorteil.

Nach dem ersten erfolgreichen Nachweis erhält diese Identität **maximal ein Ticket** und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster werden **verbrannt**; normale Transfergebühren sind zur Validator-Finanzierung vorgesehen, genaue Verteilung offen.

Die **Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emission, Coin-Maximum, Zufallsbeacon und Validatoranzahl** sind weiter unentschieden. Alle genannten Zahlen aus früheren Beispielen bleiben hypothetisch. Pi-4-Benchmark, Simulation und ein neues ADR sind Pflicht vor Implementierung konsenskritischer PoP-Regeln.

## Sicherheitsgrenzen

- Eine zugelassene Node-ID ist kein kryptografischer Beweis für ein physisches Gerät. Anfangs manuelle Registry; Betreibergruppen und mehrere Geräte auditiert verwalten. Verschieben von Coins soll die Gebührenbasis nicht zurücksetzen, Identitätswechsel bleiben Sybil-Angriffsfläche.
- Starke CPUs können endliche Nonce-Räume schneller durchsuchen. Gleichheit nur bei rechtzeitig vollständig bearbeiteter erlaubter Aufgabe, nicht mathematisch hardwareunabhängig.
- Keine lokalen Uhrzeit-, Betriebssystem-, Zufallsgenerator- oder Float-Operationen in der State-Machine, die zwischen Validatoren abweichen können.
- Mining-Fenster-Gebühren und Zufallsgewinne können regulatorische Pflichten auslösen. Vorerst ausschließlich private Test-PTM ohne wirtschaftlichen Wert.
- Kein automatisches Bezahlen durch den Miner mit privaten Wallet-Schlüsseln. Die Wallet autorisiert später separat, begrenzt und widerrufbar.

## Entwicklungsreihenfolge

1. **M1:** Architektur-/Coin-/PoP-Parameter dokumentieren, Gebühren-/Fairness-Simulation, Pi-4-Benchmark, ADRs akzeptieren.
2. **M2:** Ledger, Accounts, deterministischer State, Signaturen, Genesis, Nonce, Tests; **parallel funktionale Web-Wallet** nach festgelegter Schnittstelle.
3. **M3:** CometBFT anbinden (1, danach 4 Validatoren), Synchronisation/Ausfalltests.
4. **M4:** PoP-Registry, Fenster, signierte Proofs/Gebühren, Ticketcommit, nachweisbare Ziehung, Mint/Burn und Negativtests.
5. **M5–M6:** Pi-/Office-PC-Builds, Web-Wallet vervollständigen, private Mehrhost-Tests, Doku/Release.

Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung, Tests inkl. `gofmt`, `go test ./...`, `go vet ./...`, kurze Dokumentation und Git-Review. Keinen Fortschritt erfinden.