PP-Händlerdaten

Einen Zahlungseingang einer Bestellung zuzuordnen, ist das unspektakuläre Problem, das jede Kasse lösen muss, und Bitcoin macht es schwerer, weil eine Transaktion keine Rechnungsnummer trägt. BIP70 löste es, indem das Protokoll der Wallet des Kunden ein Cookie mitgab und es zurückverlangte. Händler lösen dasselbe Problem heute mit einer Einmaladresse pro Bestellung, was einfacher und privater ist.

So funktioniert es

Status: historisch. Die Händlerdaten waren Feld 7 von PaymentDetails und Feld 1 der Payment-Nachricht, die zurückkam, und sie verschwanden mit dem Rest von BIP70, als Bitcoin Core 0.20.0 am 3. Juni 2020 veröffentlicht wurde.

Die Undurchsichtigkeit war der Zweck. Die Wallet sollte die Bytes als bedeutungslos behandeln und unverändert zurückgeben, sodass jeder Händler sein eigenes Schema erfinden konnte, ohne dass jemand anderes es verstehen musste.

Zwei Schemata waren verbreitet. Ein kurzer Suchschlüssel, etwa eine 16 Byte lange Bestellkennung, hielt die Anforderung klein und verlagerte die Arbeit in die Datenbank des Händlers. Ein in sich geschlossener Datenblock enthielt den gesamten Warenkorb und ließ den Server zustandslos bleiben, auf Kosten der Größe.

Das zweite Schema hat ein Loch, vor dem die Spezifikation warnte. Diese Bytes kommen aus Software zurück, die der Händler nicht steuert, also ist alles, was daraus gelesen wird, vom Angreifer gelieferte Eingabe. Ein Geschäft, das dort einen Preis oder einen Rabattcode speicherte und der zurückgegebenen Kopie vertraute, hatte sich selbst einen Gutscheingenerator gebaut. Das Gegenmittel ist das übliche für hin- und zurückgereichten Zustand: einen Message Authentication Code anhängen und ihn prüfen, bevor ein einziges Feld gelesen wird.

Die Größe war wichtiger, als es aussieht. Die gesamte signierte Anforderung musste den Kunden erreichen, und die Darstellung als QR-Code setzt dem eine harte Obergrenze: Das größte Symbol, Version 40 mit der niedrigsten Fehlerkorrekturstufe, fasst 2.953 Byte Binärdaten. Diese Obergrenze ist der Grund, warum BIP72 den Parameter r= definierte, damit ein kurzer Link auf eine über HTTPS ausgelieferte Anforderung zeigen konnte, statt sie mitzuführen.

Wo Sie es sehen

Die Aufgabe, die früher die Händlerdaten erfüllten, erfüllt heute die Adresse selbst.

Kassensoftware wie BTCPay Server leitet für jede Rechnung eine neue Adresse ab, sodass eine eingehende Zahlung ihre eigene Bestellung ohne Hin- und Rückweg und ohne zurückgegebenen Zustand kennzeichnet. Das ist BIP70 in zweifacher Hinsicht überlegen: Es gibt nichts, was ein Zahler manipulieren könnte, und es vermeidet die Adresswiederverwendung, die sonst die gesamten Einnahmen eines Händlers jedem offenlegen würde, der die Blockchain liest. Verwahrplattformen arbeiten genauso, und so landet eine Einzahlung auf Ihrem Konto und nicht auf dem eines anderen.

Eine Warnung sollten Sie aus alldem mitnehmen. Mehrere andere Netzwerke verlangen neben einer Einzahlung ein Memo oder ein Destination Tag, und wer es weglässt, dessen Guthaben landet auf einem Sammelkonto, ohne dass etwas es mit ihm verbindet. Bitcoin hat kein solches Feld. Wenn eine Einzahlungsseite Sie auffordert, einer Bitcoin-Transaktion ein Tag, ein Memo oder einen Referenzcode beizufügen, ist das Formular entweder falsch konfiguriert oder gefälscht, und die Rückholung einer wirklich fehlgeleiteten Einzahlung ist langsam und häufig unmöglich.

PP-Händlerdaten vs. PP-Memo

Händlerdaten waren für eine Maschine geschrieben; ein Memo war für einen Menschen geschrieben. Das eine wurde dem Kunden nie gezeigt, das andere existierte nur, um gezeigt zu werden. Ihre Fehlerarten unterscheiden sich entsprechend: Ein ungeprüftes Memo führt einen Menschen in die Irre, der einen Bestätigungsbildschirm liest, während ungeprüfte Händlerdaten die Buchhaltungssoftware des Händlers selbst in die Irre führen. Keines von beiden wurde auf dem Rückweg signiert, weshalb beide als nicht vertrauenswürdig behandelt werden mussten.