R-Parameter

Beim Scannen eines QR-Codes mit einem R-Parameter wird Ihre Wallet angewiesen, eine Webseite abzurufen, bevor sie Ihnen etwas anzeigt. BIP72 erschien am 29. Juli 2013 und verwendete ein einfaches r statt der Schreibweise req-r, die obligatorischen Schlüsseln vorbehalten ist, damit ältere Wallets es ignorieren und stattdessen an die Adresse zahlen konnten. Keine Bezahlseite, auf die Sie heute treffen, wird Ihnen einen liefern.

So funktioniert es

Der R-Parameter ist ein Abfrageschlüssel, der eine prozentkodierte HTTPS-URL enthält, und BIP72 definierte zwei Formen dafür. Die kompatible Form behält eine normale Adresse im URI und hängt den Schlüssel dahinter an, sodass eine Wallet, die noch nie vom Zahlungsprotokoll gehört hat, an die Adresse zahlt, während eine Wallet, die r versteht, die Adresse ignoriert und die Anfrage abruft. Die reduzierte Form lässt die Adresse ganz weg und ergibt etwas wie bitcoin:?r=https://store.example/i/8f3a, das ältere Software überhaupt nicht bezahlen kann.

Den Schlüssel optional zu machen, war eine bewusste Auslegung von BIP21, dessen Grammatik nicht erkannte Parameter in zwei Klassen teilt: Alles mit dem Präfix req- muss dazu führen, dass eine Wallet den URI ablehnt, alles andere darf übersprungen werden. Die Bezeichnung des Feldes als r statt req-r war daher die Entscheidung für eine Graceful Degradation. BIP72 beschrieb auch das umgekehrte Verhalten ausführlich, sodass ein Händler, der eine Zahlung an eine bloße Adresse wirklich nicht akzeptieren konnte, req-r schreiben und inkompatible Wallets zum Anhalten zwingen konnte, statt Geld zu senden, das die Bezahlseite nicht abgleichen würde.

Was von der URL zurückkam, war ein Protocol Buffer, der unter dem MIME-Typ ausgeliefert wurde, den BIP71 dafür registriert hatte. BIP73 fügte dann die Inhaltsaushandlung hinzu, wodurch derselbe Link einer Wallet eine Zahlungsanforderung und einem Browser eine gewöhnliche menschliche Webseite zurückgeben konnte, unterschieden anhand des Accept-Headers, den der Client sendete.

Wo er auftritt

Der R-Parameter taucht im aktuellen Gebrauch nirgends auf. Bitcoin Core hat aufgehört, diesen URLs zu folgen, als Version 0.20.0 die Unterstützung für das Zahlungsprotokoll entfernte, und die Händlerwerkzeuge, die sie einst erzeugten, wurden durch Software ersetzt, die einfache BIP21-URIs und Lightning-Rechnungen ausgibt. Eine Bezahlseite, die noch immer einen R-Parameter erzeugt, betreibt eine Integration, die seit Jahren niemand angefasst hat, und über einen anderen Weg zu zahlen ist die vernünftige Antwort.

Die Gewohnheit, die dieses Feld bei Ihnen hinterlassen sollte, überdauert das Feld. Ein QR-Code ist für einen Menschen unlesbar, daher ist das Scannen eines Codes ein Vertrauensakt in das, was ihn erzeugt hat: einen Bildschirm, eine gedruckte Rechnung, einen Aufkleber an einer Maschine. Der R-Parameter machte das wörtlich, indem er Ihrer Wallet eine URL zum Kontaktieren gab, was zudem Ihre IP-Adresse dem Server des Händlers preisgab, bevor Sie irgendetwas zugestimmt hatten. Dieselbe Preisgabe besteht in einer weniger spektakulären Form bei einem gewöhnlichen Adress-QR-Code, den jemand still und leise ausgetauscht hat. Bestätigen Sie das Ziel auf einer Anzeige, die der Scanner nicht steuert, was bei einer Hardware-Wallet der eigene Bildschirm des Geräts bedeutet, und vergleichen Sie genügend Zeichen, um sicher zu sein, statt einen Blick auf die ersten vier zu werfen.

R-Parameter vs. Bitcoin-URI

Ein Bitcoin-URI ist die ganze Zeichenkette; der R-Parameter war ein optionaler Schlüssel darin. Was sie trennt, ist die Richtung der Autorität. Schlüssel wie amount, label und message schmücken ein Ziel, das bereits im URI steht, und eine Wallet kann jeden einzelnen davon ignorieren und trotzdem Geld an die richtige Stelle senden. Der R-Parameter kehrte dieses Verhältnis um: Wo er verstanden wurde, setzte er die Adresse vollständig außer Kraft und verlagerte die Entscheidung darüber, wohin das Geld geht, von der Zeichenkette vor Ihnen auf einen Server irgendwo anders.