Zum Inhalt springen
buybitcoinsmart

Glossar / Entwicklerreferenz

PaymentDetails

Was ist PaymentDetails?
PaymentDetails ist die innere BIP70-Nachricht, die eine Zahlung tatsächlich beschrieb: welche Ausgaben zu bezahlen sind, wie viel, wann die Anforderung abläuft und wohin die signierte Transaktion zu senden ist.

Spezifiziert im BIP-70.

PaymentDetails war der Teil, den ein Händler tatsächlich signierte, und der äußere Umschlag trug nur das Zertifikat, das ihn belegte. Er enthielt sieben Felder: einen Netzwerknamen mit der Voreinstellung main, eine Liste von Ausgaben, einen erforderlichen Zeitstempel, einen optionalen Ablauf, ein Memo, eine Callback-URL und einen undurchsichtigen merchant_data-Block. Ein BIP21-URI plus eine Bezahlseite erledigt dieselbe Aufgabe heute ohne Signatur und ohne Server.

So funktioniert es

Status: historisch. Bitcoin Core entfernte BIP70 in Version 0.20.0 am 3. Juni 2020, und PaymentDetails hat keine aktive Implementierung. Diese Website dokumentiert es, weil die Feldnamen weiterhin in alten Integrationsleitfäden und in der Entwicklerreferenz von bitcoin.org auftauchen.

Protocol Buffers, nicht JSON, transportierten die Struktur. Diese Wahl war aus einem Grund wichtig, bei dem es sich lohnt innezuhalten: Der Händler serialisierte PaymentDetails zu einer Byte-Zeichenkette und legte genau diese Bytes in die äußere PaymentRequest als undurchsichtiges Feld statt als verschachtelte Nachricht. Die Signatur deckte die Byte-Zeichenkette ab, sodass keine Bibliothek, die dieselben Felder in einer anderen Reihenfolge neu kodierte, eine gültige Signatur ungültig machen konnte.

Die sieben Felder teilten sich in Anweisungen und Buchführung.

  • network, eine Zeichenkette mit der Voreinstellung "main", wobei "test" der einzige weitere definierte Wert ist.
  • outputs, eine wiederholte Liste, deren jeder Eintrag einen Betrag in Satoshis mit einem Skript paart. Mehr als eine Ausgabe war zulässig, und Händler nutzten das, um eine einzelne Kundenzahlung auf eine Hot Wallet und Cold Storage aufzuteilen, ohne den Kunden um zwei Sendungen zu bitten.
  • time, ein erforderlicher Unix-Zeitstempel, der festhielt, wann die Anforderung erstellt wurde.
  • expires, ein optionaler Unix-Zeitstempel, nach dem eine Wallet die Zahlung ablehnen sollte. Dies ist das Feld, das BIP70 wie ein Kartenterminal wirken ließ, weil ein Händler einen Fiat-Preis nennen und ihn für ein festes Zeitfenster garantieren konnte.
  • memo, eine UTF-8-Notiz, die dem Zahler angezeigt wurde.
  • payment_url, wohin die Wallet ihre Payment-Nachricht nach dem Senden in das Netzwerk schickte.
  • merchant_data, undurchsichtige Bytes, die unverändert zurückgegeben wurden, damit der Händler eine Zahlung einem Warenkorb zuordnen konnte.

Nur time und die Skripte der Ausgaben waren verpflichtend. Alles andere konnte ein Händler weglassen, und die meisten taten es.

Wo Sie es sehen

Die Idee hinter PaymentDetails überlebte die Nachricht, und das ist das Nützliche, was es zu bemerken gilt.

Der Preisablauf wird heute an der Kryptobörse statt in Ihrer Wallet geregelt. Kaufen Sie über einen Sofortkauf-Bildschirm, erhalten Sie einen genannten Kurs mit einem Countdown daneben; lassen Sie den Countdown ablaufen, wird das Angebot zum neuen Preis neu erstellt. Das ist expires, neu implementiert in einer Web-App, und es schützt den Verkäufer vor Volatilität auf genau dieselbe Weise. Die Orderzuordnung in einem Orderbuch an einer Kryptobörse erledigt dieselbe Aufgabe anders, indem sie nie einen festen Preis nennt.

Das Gegenstück zur gesamten Nachricht auf der Händlerseite ist ein Rechnungsdatensatz in einer Checkout-Software. BTCPay Server und ähnliche Werkzeuge erzeugen einen BIP21-URI, halten ihn eine konfigurierte Anzahl von Minuten offen und gleichen die eingehende Transaktion mit einer internen Bestellkennung ab, und genau dafür war merchant_data gedacht.

PaymentDetails vs. Beleg

PaymentDetails war die Anforderung; der Beleg in BIP70 war die PaymentACK-Nachricht, die der Händler danach zurückschickte. Die eine beschrieb, was geschehen sollte, der andere bestätigte, dass der Händler es gesehen hatte. Keines von beiden war eine Tatsache der Blockchain, und das ist die Einschränkung, die unterschätzt wurde: Eine signierte Empfangsbestätigung eines Händlers beweist, dass der Server des Händlers etwas gesagt hat, nicht dass eine Transaktion bestätigt wurde. Bestätigungen, nicht Belege, sind es, die eine Bitcoin-Zahlung abwickeln.

Nicht zu verwechseln mit

Häufig gestellte Fragen

Warum speicherte BIP70 PaymentDetails als rohe Bytes statt als verschachtelte Nachricht?

Damit die Signatur eine exakte Byte-Zeichenkette abdeckte. Protocol Buffers erlauben, dieselben Felder auf verschiedene gültige Arten neu zu kodieren, und die Signatur über den serialisierten Block bedeutete, dass keine Bibliothek eine gültige Signatur versehentlich ungültig machen konnte, indem sie ihn neu serialisierte.

Verwandte Begriffe

Mehr zum Thema Entwicklerreferenz

Diese Seite auf Englisch lesen