Silent Payments

Stellt Bob eine gewöhnliche Bitcoin-Adresse auf seine Website, kann jeder deren Eingänge im Explorer verfolgen. Ein Blockexplorer ist eine Anwendung, mit der sich Transaktionen und Blöcke eines bestimmten Netzwerks nachschlagen lassen. Jedem eine neue Adresse zu geben ist besser, doch jemand muss sie bereitstellen. Silent Payments lösen genau dieses Problem: Bob veröffentlicht feste Angaben, aus denen Alice einen Output für die jeweilige Zahlung erstellt: einen Eintrag mit Betrag und Bedingung für das spätere Ausgeben. Der öffentliche Kontakt erscheint daher nicht wiederholt als dieselbe Empfangsadresse in der Blockchain. [1] [3] [9] [7]

Eine Silent-Payments-Adresse enthält einen öffentlichen scan key und einen öffentlichen spend key. Ein privater Schlüssel ist ein geheimer Zahlenwert; der zugehörige öffentliche Schlüssel kann weitergegeben werden. Die Namen beschreiben ihre Aufgaben: Der scan key gehört zur Zahlungssuche, der spend key zum Ausgeben. Die zugehörigen privaten Schlüssel bleiben bei Bob. Im Mainnet, dem Hauptnetz von Bitcoin, beginnt sie mit sp1 und verwendet Bech32m. Sie ist weder eine gewöhnliche Taproot-Adresse mit bc1p noch eine Wallet-Sicherung. Das öffentliche Schlüsselpaar erlaubt kompatiblen Sendern, das Zahlungsziel zu berechnen, gibt aber weder Ausgaberechte noch eine Liste von Bobs Eingängen preis. [1] [5] [9]

Um Bob zu bezahlen, wählt Alices Wallet zuvor empfangene Beträge aus. Verweise darauf bilden die Inputs der neuen Transaktion. Für die Berechnung des Ziels werden Schlüssel aus Inputs verwendet, die den Regeln von BIP352 entsprechen; nicht jeder Input-Typ ist geeignet. Alice kombiniert deren private Schlüssel mit Bobs öffentlichem scan key mittels ECDH. Dieses kryptografische Verfahren erlaubt beiden Seiten, unabhängig dasselbe Geheimnis zu berechnen, ohne private Schlüssel auszutauschen. Aus dem Geheimnis und der Bindung an die konkreten Inputs leitet die Wallet eine Anpassung von Bobs öffentlichem spend key ab. So entsteht der neue Output-Schlüssel. Die Input-Bindung verhindert die Wiederverwendung des Ziels bei erneut benutztem Input-Schlüssel. Nutzt Alice RBF, ersetzt also eine unbestätigte Transaktion etwa zur Erhöhung der Gebühr, und ändert dabei die Inputs, muss die Wallet das Ziel neu berechnen. Das alte Ergebnis darf sie nicht einfach übernehmen. [1] [4]

Bobs Wallet durchsucht geeignete Transaktionen und berechnet mit seinem privaten scan key und öffentlichen Input-Daten mögliche Outputs. Findet sie eine Übereinstimmung, erfasst sie den Output als seine Mittel. In der Blockchain ist es ein Taproot-Output ohne besondere Benachrichtigung. Bob muss weder beim Senden online sein noch Alice vorher antworten; seine Wallet muss die erforderlichen Daten aber später verarbeiten. [1] [6]

Der scan key dient zum Auffinden, der spend key zusammen mit abgeleiteten Daten zum Ausgeben. Der private spend key kann vom Online-Scanner getrennt bleiben. Ein gestohlener privater scan key allein ermöglicht es nicht, Coins auszugeben, kann aber zusammen mit öffentlichen Daten Eingänge offenlegen. Ihn einem fremden Scan-Server zu geben hat daher Folgen für die Privatsphäre. Seed und privater spend key werden diesem Server nicht übermittelt. [1]

Silent Payments brauchen keine besondere Benachrichtigungstransaktion, doch Rechenleistung und Datenübertragung sind nicht kostenlos. Der Empfänger prüft geeignete Transaktionen mithilfe der beschriebenen kryptografischen Berechnungen. Auf dem Telefon zählen Indexierung, Datenquelle und Zeit seit dem letzten Scan. Eine gewöhnliche Adressliste reicht nicht. Ein Knoten ist ein Programm, das Transaktionen und Blöcke prüft und sich mit anderen Netzwerkteilnehmern austauscht. Ein eigener Knoten und ein externer Anbieter haben unterschiedliche Anforderungen und Auswirkungen auf Privatsphäre und Verfügbarkeit. [1] [2] [8]

Bob kann labels verwenden, also abgeleitete Zahlungsvarianten etwa für verschiedene Projekte. Dafür muss er nicht jede Variante vollständig unabhängig durchsuchen. Die öffentlichen Varianten teilen jedoch den scan key, sodass Beobachter ihren gemeinsamen Eigentümer erkennen können. Ein Label hilft Bob beim Zuordnen von Eingängen, schafft aber keine getrennte anonyme Identität. Das besondere Wechselgeld-Label kennzeichnet den Rest einer eigenen Zahlung. Gibt Bob einen zuvor empfangenen Betrag aus, der größer ist als Zahlung und Gebühr zusammen, geht der Rest an seine Wallet zurück. Gemeint ist keine Rückerstattung durch einen Händler. BIP352 reserviert dafür das Label m = 0. Bei der Wiederherstellung sucht die Wallet immer danach und darf es nicht als Kontakt für Zahlungen anderer Personen veröffentlichen. [1] [4]

Angenommen, Bob verliert sein Telefon, hat aber noch seine Sicherung. Der Seed ist der geheime Ausgangswert, aus dem eine Wallet Schlüssel ableitet. Nutzer sichern ihn gewöhnlich über eine Seed Phrase, Wiederherstellungswörter in einer festgelegten Reihenfolge. Diese Wörter allein bedeuten jedoch nicht, dass jede Anwendung Silent Payments finden kann. Sie muss dieselbe Schlüsselableitung und die Suche nach diesen Zahlungen unterstützen. Eine Sicherung der verwendeten labels und des Datums der ersten Wallet-Nutzung erleichtert die Wiederherstellung. Für die aktuellen Mittel kann die Wallet die nötigen Transaktionsdaten zu verbleibenden UTXOs durchsuchen: einzeln empfangenen, noch nicht ausgegebenen Beträgen. Die vollständige Historie erfordert einen umfassenderen Scan der Blockchain. Eine leere Anzeige vor dessen Abschluss bedeutet daher nicht zwangsläufig verlorenes Geld. [1]

Silent Payments erschweren Verknüpfungen durch wiederverwendete Adressen, verbergen aber weder Beträge noch Bestätigungszeit oder die Vorgeschichte ausgegebener Inputs. Alice kennt ihre eigene Zahlung an Bob; eine Bestellung kann persönliche Angaben enthalten. Führt Bob später mehrere UTXOs in einer Transaktion zusammen, kann das ihre Verbindung offenlegen. Silent Payments sind kein CoinJoin, und die Kombination ist nicht automatisch sicher: BIP352 weist auf einen fehlenden formalen Sicherheitsbeweis für zusammenarbeitende unabhängige Sender hin. [1] [3]

BIP352 nennt josibake, Ruben Somsen und Sebastian Falbesoner als Autoren; die Nummer wurde 2023 vergeben. Bei der Prüfung am 17. Oktober 2026 lautet der Status Complete. Das bedeutet keine Unterstützung in jeder Wallet: Senden, Empfangen, Scannen und Wiederherstellen müssen getrennt geprüft werden. Das Protokoll nutzt vorhandenes Taproot und benötigt keinen neuen Soft Fork, also eine vom Netzwerk übernommene Verschärfung der Gültigkeitsregeln. Ältere Anwendungen ohne Unterstützung können eine sp1-Adresse nicht korrekt verarbeiten. [1] [2]