Vertrauen & Privatsphäre
Was Sie selbst überprüfen können
Nichts davon setzt Vertrauen in den Betreiber voraus:
- Jede Zustandsänderung ist signiert. Die Schaltung prüft eine Ed25519-Signatur mit dem Schlüssel, den die Operation verlangt, sodass ein Name sich ohne den Schlüssel seines Inhabers nicht bewegen kann.
- Jeder Batch hat einen ZK-Beweis. Der Anchor-Vertrag nimmt ohne ihn keinen Root an;
geprüft wird gegen
programVkey— eine Festlegung auf die exakt kompilierte Schaltung, die Sie selbst neu bauen können. - Jede Auflösung kommt mit einem Merkle-Beweis. Sie können den Datensatz gegen einen Root prüfen und den Root gegen den Vertrag. Siehe Beweise prüfen.
- Jeder Root ist deterministisch. Jeder Indexer, der dieselben Befehle wiedergibt, muss denselben Root erzeugen, sodass Abweichungen sofort auffallen.
- Roots bilden eine Kette, jeder verankert an der PIVX-Blockhöhe, die er abdeckt.
Worauf Sie vertrauen müssen
Eine kurze, ehrliche Liste — alles andere auf dieser Seite können Sie selbst prüfen:
- PIVX und die BNB Smart Chain funktionieren wie vorgesehen — Transaktionen sind endgültig, die Ketten reorganisieren sich nicht über ihre Bestätigungsschwellen hinaus.
- Standardkryptografie ist sicher — SHA-256, Ed25519 und das SP1-Beweissystem.
- Eine Auszahlung erreicht die von Ihnen angegebene Adresse. Beträge, Gebühren und Verpflichtungen sind vollständig öffentlich prüfbar; das Ziel ist das eine Detail, das Sie selbst bestätigen statt eines außenstehenden Beobachters. Erläutert unter Guthaben und Auszahlungen.
Warum die Replikation die Registrierungsstelle rechenschaftspflichtig macht
Die Registrierungsstelle veröffentlicht ihre Protokolladresse und den zugehörigen Viewing Key. Das ist Absicht und trägt die eigentliche Last: Mit beidem kann jeder
- PIVX scannen und jeden Befehl und jede Zahlung ab Genesis entschlüsseln, in kanonischer Reihenfolge,
- sie durch den quelloffenen Indexer wiedergeben,
- den Zustands-Root unabhängig berechnen und
- ihn mit dem auf der BNB Smart Chain verankerten Root vergleichen.
Eine Registrierungsstelle, die einen bezahlten Befehl unterschlägt, eine Übertragung erfindet, ein Guthaben falsch verbucht oder Operationen umsortiert, erzeugt einen Root, den jeder unabhängige Indexer widerlegt. Für diese Prüfung braucht es weder Erlaubnis noch besonderen Zugang.
Die daraus folgende Eigenschaft ist Betrug wird sichtbar, nicht verhindert: Ein fehlerhafter Batch kann on-chain landen und danach widerlegt werden. Die Wiederherstellung ist sozial, nicht automatisch.
Guthaben und Auszahlungen
Geld fließt nicht direkt zwischen Käufer und Verkäufer. Verkaufserlöse werden dem Verkäufer abzüglich der Servicegebühr auf dem internen Guthaben gutgeschrieben, unterlegene Gebote auf einen umkämpften Namen werden dem Guthaben erstattet, und der Nutzer zahlt sich aus, wann er möchte. Erst das Guthaben macht Rückerstattungen überhaupt möglich: Eine abgeschirmte Transaktion trägt keine Absenderadresse, es gibt also keinen Ort, an den man eine irrtümliche Zahlung automatisch zurückschicken könnte.
Auszahlungen sind on-chain und zugeordnet
Die Registrierungsstelle veröffentlicht einen vollständigen Viewing Key, nicht nur einen für eingehende Zahlungen, sodass ausgehende Zahlungen ebenso sichtbar sind wie eingehende. Jede Auszahlung trägt ein Memo, das das abgerechnete Konto nennt:
Payout #{id}: {gross} PIVX for pubkey '{pubkey}' (including the {fee}% service fee)
Damit lässt sich das gesamte Buch von jedem rekonstruieren. Scannen Sie die Protokolladresse mit dem veröffentlichten Viewing Key, und Sie sehen für jeden öffentlichen Schlüssel:
- jede Gutschrift, die er erwirtschaftet hat — Verkaufserlöse und Rückerstattungen, abgeleitet aus dem öffentlichen Befehlsstrom
- jede Auszahlung, die er erhalten hat, zugeordnet über das Memo, mit dem Betrag aus dem Note-Wert
- die jeweils angewandte Servicegebühr
woraus sich ein laufendes Guthaben ergibt, das jeder unabhängig berechnen kann:
balance(pubkey) = Σ(sale proceeds net of fee) + Σ(refunds) − Σ(payouts sent) stays ≥ 0
Eine Auszahlung ohne zugehörige Verpflichtung, eine falsche Gebühr oder ein ins Minus laufendes Guthaben wären für jeden Beobachter sichtbar. Die Registrierungsstelle kann sich weder still selbst auszahlen noch eine Verpflichtung überspringen noch eine andere als die veröffentlichte Gebühr anwenden.
Beträge aus der Note lesen, nicht aus dem Memo
Das Memo nennt die Brutto-Verpflichtung — den Betrag vor der Servicegebühr —, während die Note den tatsächlich gezahlten Netto-Betrag trägt. Der Wert einer Note ist kryptografisch; den Memo-Text schreibt die Registrierungsstelle. Nehmen Sie beim Prüfen jeden Betrag aus dem Note-Wert und behandeln Sie das Memo rein als Zuordnung.
Was der Empfänger bestätigt statt eines Prüfers
Ein Detail fällt aus diesem Bild heraus, und man sagt es besser deutlich, als es implizit zu lassen. Eine Auszahlung wird auf der Website mit Ihrem Ed25519-Schlüssel autorisiert, und diese Anfrage läuft über HTTPS statt über die Kette. Ein außenstehender Beobachter sieht daher, dass für Ihr Konto eine korrekt bemessene Auszahlung erfolgt ist, hat aber keinen öffentlichen Nachweis darüber, welche Zieladresse Sie angegeben haben.
In der Praxis kann das niemand besser prüfen als Sie selbst, und zwar sofort: Sie wissen, was Sie angefordert haben und ob das Geld angekommen ist. Und diese Prüfung ist keine Ansichtssache — Sie behalten die von Ihnen signierte Anfrage, sodass sich eine Abweichung kryptografisch belegen und nicht bloß behaupten lässt.
| Bestätigt durch | |
|---|---|
| Domainzustand | Jeden Beobachter, automatisch — ein unabhängiger Indexer bemerkt eine Root-Abweichung von selbst |
| Auszahlungsbeträge, Gebühren, Verpflichtungen | Jeden Beobachter, über den veröffentlichten Viewing Key und die Memo-Zuordnung |
| Auszahlungsziel | Den Empfänger, anhand der von ihm signierten Anfrage |
Würde man Auszahlungen über den Memo-Transport leiten, rückte die letzte Zeile in die erste Kategorie, und zwar fast ohne Privatsphäreverlust, da Viewing Key und die den öffentlichen Schlüssel nennenden Memos diese Verbindung ohnehin offenlegen. Das wurde erwogen und zugunsten einer einfachen Auszahlung über die Website zurückgestellt; es bleibt eine vernünftige künftige Änderung und kein Mangel.
Bewahren Sie Ihre signierten Auszahlungsanfragen auf
Behalten Sie die signierte Anfrage, bis Sie den Geldeingang bestätigt haben. Sie ist es, die aus einer strittigen Auszahlung etwas macht, das Sie beweisen können.
Was ein bösartiger Indexer nicht kann
Er kann keinen Datensatz fälschen. Auflösungen kommen mit Merkle-Beweisen, und ein Root, den der Anchor-Vertrag nie angenommen hat, scheitert an der Prüfung aus Beweise prüfen.
Er kann keine Registrierung verbergen. Abwesenheit wird bewiesen, nicht behauptet: Ein
Blocked-Terminal trägt den vollständigen blockierenden Datensatz mit sich, sodass Sie die
Behauptung prüfen statt hinnehmen können. Und die gesamte Historie ist mit dem öffentlichen
Viewing Key aus der Kette neu ableitbar.
Er kann nicht verschwinden. Jeder Befehl liegt auf PIVX, und der Code ist quelloffen. Jeder kann das gesamte Register ab dem Genesis-Block neu aufbauen.
Private Auflösung über Tor
Eine Auflösung über das Clearnet verrät dem Server, welche Namen Sie nachschlagen und wann. Die Indexer-API ist deshalb auch als Tor-Hidden-Service veröffentlicht:
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion
Im Tor-Browser:
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/resolve/richard.pivx
Über die Kommandozeile, mit lokal laufendem Tor:
curl --socks5-hostname 127.0.0.1:9050 \
http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/info
Es ist dieselbe API mit denselben Daten, Merkle-Beweise inklusive, Sie verlieren also nichts. Der Server erfährt nie Ihre IP, und Ihr Provider sieht nur, dass Sie Tor genutzt haben.
Das Vertrauen nimmt die Prüfung, nicht der Transportweg
Tor schützt Ihre Privatsphäre vor dem Indexer. Ehrlicher wird der Indexer dadurch nicht — das leisten der Merkle-Beweis und der On-Chain-Root-Abgleich, und die sollten Sie unabhängig davon durchführen, wie Sie sich verbinden.