Silent Payments erklärt - Teil 1

You can also read the English version of this article.

Wir sind stolz darauf, bekanntgeben zu können, dass die BitBox02 die erste Hardware-Wallet ist, die Bitcoin Silent Payments sicher durchführen kann! In dieser Blogpost-Serie wollen wir euch zeigen, wie Silent Payments funktionieren und was die BitBox02 im Hintergrund tut, um sicherzustellen, dass diese Zahlungen sicher durchgeführt werden.

Die Unterstützung für das Senden an Silent Payments-Adressen wird allen BitBox02-Nutzern in einem zukünftigen Update zur Verfügung gestellt.

• Teil I erklärt, wie Silent Payments im Allgemeinen funktionieren
• In Teil II erfährst du, was deine BitBox02 im Hintergrund tut, um Silent Payments auf sichere Weise zu unterstützen.

Silent Payments sind ein BIP (Bitcoin improvement proposal) für ein neues Bitcoin-Adressformat. Der Hauptvorteil besteht darin, dass es sich um eine statische Adresse handelt. Damit entfällt die Notwendigkeit, mehrere Adressen zu verwenden, während gleichzeitig die Privatsphäre gewahrt bleibt. Wenn du mehr über die Grundlagen dieses Konzepts erfahren möchtest, sieh dir unseren früheren Artikel über wiederverwendbare Zahlungscodes an.

Aktuell muss ein Empfänger mit dem Absender interagieren, um seine Privatsphäre zu wahren und ihm für jede Transaktion eine neue Adresse zu geben. Das führt zu einem schlechten Benutzererlebnis oder zu operativen Schwierigkeiten.

Zum Beispiel:

• Abhebung von einer Börse: Für jede Abhebung musst du eine neue, unbenutzte Empfangsadresse von der BitBoxApp erhalten, die neue Adresse bei der Börse registrieren und auf der BitBox und auf einem zweiten Gerät verifizieren, dass es die richtige Adresse ist.
• Einzahlung bei einer Börse: Für jede Einzahlung musst du eine neue Einzahlungsadresse bei der Börse erstellen und diese auf einem zweiten Gerät und auf deiner BitBox verifizieren, bevor du die Coins versendest.
• Spenden sammeln: Du musst einen Server wie BTCPay Server einrichten und betreiben, um neue Adressen für jeden Spender zu erstellen.

Viele Bitcoin-Dienste und -Nutzer/innen umgehen die oben genannten Schwierigkeiten, indem sie eine einzige Adresse verwenden und damit ihre Privatsphäre gefährden, da alle Transaktionen, die mit dieser Adresse verbunden sind, leicht identifiziert und analysiert werden können.

Silent Payments sind die Lösung für diese Herausforderungen. Sie verwenden statische Adressen, die wiederverwendet werden können, während Transaktionen, die an sie getätigt werden, nur vom Absender und vom Empfänger identifiziert werden können. Spendenorganisationen könnten ihre Spendenadresse öffentlich auf ihrer Website veröffentlichen, ohne dass jemand erkennen kann, wer gespendet hat oder wie viel. Börsen könnten eine einzige Silent Payments-Adresse für alle Abhebungen registrieren.

Transaktionen heute

Eine Bitcoin-Transaktion besteht aus Inputs und Outputs.

Die Outputs erzeugen neue UTXOs (nicht verbrauchte Transaktions-Outputs), und die Inputs verbrauchen bestehende UTXOs. Wenn du mehr darüber erfahren möchtest, was UTXOs sind, schau dir unseren Blogbeitrag zu diesem Thema an.

In der Regel wird ein UTXO mit einem einzigen öffentlichen Schlüssel gelockt und mit einer Signatur ausgegeben, die mit dem entsprechenden privaten Schlüssel erstellt wurde. Wenn du Bitcoin an eine Adresse sendest, verschlüsselt die Adresse üblicherweise einen öffentlichen Schlüssel (oder den Hash eines öffentlichen Schlüssels).

Silent Payments nutzen einige interessante kryptografische Techniken, um für jede Transaktion, die an eine Silent Payments-Adresse gesendet wird, einen neuen, unbenutzten öffentlichen Schlüssel zu erhalten. Nun wollen wir etwas Wissen und eine Vorstellung davon bekommen, wie das funktioniert. Im Folgenden wird die Funktionsweise von Silent Payments vereinfacht und auf einfacher Ebene beschrieben. Die vollständigen Details findest du im offiziellen Vorschlag.

Eine kurze Einführung: Private Schlüssel, öffentliche Schlüssel

Ein privater Schlüssel ist einfach eine große Zahl, die so groß ist, dass sie nicht erraten werden kann, zum Beispiel:

92193805913277071008055984303319191614197341949664602874511898854633635443214

Für jeden privaten Schlüssel gibt es einen entsprechenden öffentlichen Schlüssel. Die Kenntnis eines öffentlichen Schlüssels allein verrät nichts über seinen privaten Schlüssel.

Die öffentlichen Schlüssel sind technisch gesehen Teil einer mathematischen Gruppe, in der die Addition eine besondere Bedeutung hat. Wenn du mehr darüber erfahren möchtest, findest du eine hervorragende Einführung in dieses Thema in der Blogserie „Elliptic Curve Cryptography: a gentle introduction“.

Die Formel zur Ableitung eines öffentlichen Schlüssels aus einem privaten Schlüssel lautet:

PublicKey = privateKey×G,

wobei G ein vordefinierter Wert ist, der Generator genannt wird. Der Generator ist ein spezieller öffentlicher Schlüssel. Jeder andere öffentliche Schlüssel kann aus ihm durch Addition erzeugt werden.

Wenn dein privater Schlüssel zum Beispiel 2 ist, ist dein öffentlicher Schlüssel 2×G = G + G. Wenn dein privater Schlüssel 3 ist, ist dein öffentlicher Schlüssel 3×G = G + G + G, und so weiter. In der Praxis würde dein privater Schlüssel natürlich eine große Zahl sein, die nicht erraten werden kann, wie im obigen Beispiel.

Abgesehen davon, dass eine Division hier nicht möglich ist (sonst könntest du den privaten Schlüssel aus dem öffentlichen Schlüssel errechnen), funktioniert der Großteil der üblichen Mathematik auf die gleiche Weise. Bekannte Gesetze wie das Distributivgesetz gelten:

(a + b)×G = a×G + b×G.

Im weiteren Verlauf dieses Beitrags verwenden wir Kleinbuchstaben für private Schlüssel und Großbuchstaben für öffentliche Schlüssel. Zum Beispiel: a×G = A.

Elliptic-Curve Diffie-Hellman

Elliptic-Curve Diffie-Hellman (ECDH) ist ein einfaches Protokoll zur Erstellung eines gemeinsamen Geheimnisses zwischen zwei Parteien, Alice und Bob.

Nehmen wir an, Alice möchte eine Transaktion an Bob durchführen.

• Alice hat ein privates/öffentliches Schlüsselpaar: a×G = A.
• Bob hat ein privates/öffentliches Schlüsselpaar: b×G = B.

Sie können ein Geheimnis erstellen, das nur sie kennen, ohne etwas anderes als ihre öffentlichen Schlüssel mitzuteilen.

• Alice berechnet das gemeinsame Geheimnis als S = a×B.
• Bob errechnet das gemeinsame Geheimnis als S = b×A.

Man sieht, dass beide Werte gleich sind, wenn man B = b×G und A = a×G ersetzt:

S = a×B = a×(b×G) = a×b×G = b×a×G = b×(a×G) = b*A = S.

S=(a×b)×G ist technisch gesehen ein öffentlicher Schlüssel des privaten Schlüssels a×b und könnte im Output einer Transaktion verwendet werden, um Bitcoin an diese zu senden, aber er wäre dann nur durch die Kombination der privaten Schlüssel von Alice und Bob ausgabefähig.

Um das Teilen von privaten Schlüsseln zu vermeiden, kann er jedoch durch Hashing als neuer privater Schlüssel interpretiert werden:

s = hash(S). Die Coins, die an die Silent Payments Adresse geschickt werden, können dann mit dem öffentlichen Schlüssel gelockt werden

P = hash(S)×G = hash(a×B)×G = hash(b×A)×G. 

Die mit diesem öffentlichen Schlüssel gelockten Coins können entweder vom Absender Alice (mit ihrem privaten Schlüssel a) oder vom Empfänger Bob (mit seinem privaten Schlüssel b) ausgegeben werden. Wie können wir die Coins so locken, dass nur Bob sie ausgeben kann? Lasst es uns herausfinden.

Silent payments

Eine Silent Payments Adresse hat das Präfix sp1 (nicht das bekannte Präfix bc1) und sieht zum Beispiel so aus:

sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv

Sie ist ziemlich lang, da sie nicht nur einen, sondern zwei öffentliche Schlüssel des Empfängers verschlüsselt: einen öffentlichen Schlüssel B_scan zum Scannen und einen öffentlichen Schlüssel B_spend zum Ausgeben. Der zusätzliche öffentliche Schlüssel wird verwendet, um die Coins so zu locken, dass nur Bob sie ausgeben kann.

Anstatt den öffentlichen Schlüssel P = hash(S)×G zum Locken der Coins zu verwenden, fügt Alice Bobs zweiten öffentlichen Schlüssel hinzu:

P = B_spend + hash(S)×G. Sie berechnet das gemeinsame Geheimnis S, indem sie den öffentlichen Scan-Schlüssel von Bobs und ihren privaten Schlüssel verwendet: S=a×B_scan.

Alice kann diesen öffentlichen Schlüssel P erstellen, da sie B_spend und B_scan aus Bobs Silent Payments Adresse kennt und auch ihren privaten Schlüssel a kennt.

Der daraus resultierende öffentliche Schlüssel P wird als Taproot Output zur Transaktion hinzugefügt.

Nur Bob kann diese Coins ausgeben, indem er seine eigenen beiden privaten Schlüssel b_spend und b_scan benutzt. Um die Coins auszugeben, muss der private Schlüssel p des öffentlichen Schlüssels P bekannt sein.

P = B_spend + hash(S)×G

Ersetze B_spend = b_spend×G:

P = b_spend×G + hash(S)×G

Nach dem Distributivgesetz (a + b)×G = a×G + b×G ist dies gleichbedeutend mit:

P = (b_spend + hash(S))×G

Der private Schlüssel, mit dem Bob die Coins ausgeben kann, lautet also:

p = b_spend + hash(S).

Bob kann den Hash des geteilten Geheimnisses S mit Hilfe seines privaten Scan-Schlüssels berechnen: hash(S)=hash(b_scan×A) und den endgültigen privaten Schlüssel durch Addition von b_spend erstellen.

Welchen privaten Schlüssel verwendet Alice? Woher kennt Bob ihren öffentlichen Schlüssel?

Alice, die Coins an Bob schicken will, kennt Bobs öffentliche Schlüssel, da sie in Bobs Silent Payments Adresse kodiert sind.

Aber was ist mit den Schlüsseln von Alice? Woher kennt Bob den öffentlichen Schlüssel von Alice, um das gemeinsame Geheimnis wiederherzustellen, so dass er Zahlungen an seine Silent Payments Adresse erkennen und die Coins ausgeben kann? Es wäre unpraktisch, wenn der Empfänger mit jedem Absender interagieren müsste, um deren öffentliche Schlüssel zu erhalten. Die Lösung ist recht elegant: Die relevanten Schlüssel sind alle mit der Transaktion selbst verbunden!

Alice gibt ihre eigenen UTXOs in einer Transaktion an Bob aus, die bereits mit einem privaten/öffentlichen Schlüsselpaar gelockt sind. Sie braucht ihre privaten Schlüssel sowieso, um ihre Coins auszugeben, warum sollte sie sie also nicht auch für die Erstellung des gemeinsamen Geheimnisses verwenden?

Alice kann das gemeinsame Geheimnis für das Silent Payment berechnen, indem sie die privaten Schlüssel ihrer bestehenden UTXOs, die sie in der Transaktion verwendet, als Input verwendet.

Bob kann das gemeinsame Geheimnis berechnen, indem er die öffentlichen Schlüssel von Alice verwendet, die mit den Inputs der Transaktion verbunden sind.

Eine Transaktion kann viele Inputs auf einmal ausgeben, daher verwendet Alice einen kombinierten privaten Schlüssel, der die Summe aller privaten Schlüssel der Inputs ist:

a = a_1 + a_2 + ...

Und Bob verwendet den kombinierten öffentlichen Schlüssel von Alice, indem er die öffentlichen Schlüssel der Inputs der Transaktion addiert:

A = A_1 + A_2 + ...

Die Summe der privaten Schlüssel ist der private Schlüssel der Summe der öffentlichen Schlüssel, wiederum aufgrund des Distributivgesetzes:

A = (a_1 + a_2 + ...)×G = a_1×G + a_2×G + ... = A_1 + A_2 + ...

Damit Silent Payments funktionieren, muss jeder Input mit genau einem öffentlichen Schlüssel verknüpft sein. Daher sind bei Silent Payments nur die folgenden Inputs erlaubt: P2TR („Key Spends“), P2WPKH, P2WPKH-P2SH und P2PKH, oder anders gesagt: die derzeit am häufigsten verwendeten Single-Signature-Skripttypen. Wenn Alice ein native Multisig-Konto (ohne MuSig2 und andere Aggregationsverfahren, die zu einem einzigen öffentlichen Schlüssel führen) oder ein anderes Konto verwendet, das fortgeschrittene Skripte einsetzt, kann sie leider keine Silent Payments durchführen. Ich halte dies für einen großen Nachteil von Silent Payments und für ein großes Hindernis für ihre Einführung.

Sicherstellen, dass Adressen nicht wiederverwendet werden

Das Hauptziel von Silent Payments ist es, die Wiederverwendung von Adressen / öffentlichen Schlüsseln zu vermeiden. Bei dem oben beschriebenen Verfahren wird der öffentliche Schlüssel des Empfängers dynamisch aus den Schlüsseln von Alice in den Inputs der Transaktionen und Bobs Silent Payments Adresse erstellt. Wenn Alice jedoch immer nur eine Adresse verwenden würde, könnten mehrere Transaktionen, die sie an Bobs Silent Payments-Adresse tätigt, denselben Input-Schlüssel verwenden und folglich denselben Output-Schlüssel erzeugen.

Um dies zu verhindern, wird der Output-Schlüssel nicht wie folgt berechnet

P = B_spend + hash(S)×G

Stattdessen wird er wie folgt berechnet:

P = B_spend + hash(input_hash×S)×G

Dabei ist input_hash = hash(outpoint || A), der Hash des Outpoints eines der Inputs der Transaktion. Ein Outpoint ist eine Transaktions-ID zusammen mit einem Output-Index, der eine UTXO aus einer früheren Transaktion eindeutig identifiziert. Da UTXOs in Bitcoin nicht doppelt ausgegeben werden können, führt die Einbeziehung des Hashes einer UTXO-Kennung garantiert zu einem eindeutigen öffentlichen Output-Schlüssel, da keine zwei UTXOs die gleiche Kennung haben können. A ist aufgrund einer im BIP beschriebenen technischen Besonderheit im Hash enthalten.

In einem ersten Entwurf des Vorschlags wurde der Input-Hash über alle Transaktionsinputs, lexikografisch sortiert, errechnet. In meiner Überprüfung des Entwurfs habe ich darauf hingewiesen, dass dies für Hardware-Wallets problematisch ist (auf „ Show resolved “ klicken, um den Thread zu erweitern):

Das ist für Hardware-Wallets problematisch. Hardware-Wallets verfügen nur über begrenzten Speicherplatz und sind möglicherweise nicht in der Lage, alle Outpoints zu laden und zu sortieren. Daher müssten sie die Transaktionen darauf beschränken, dass die Inputs zum Zeitpunkt der Unterzeichnung bereits sortiert sind, was nicht wünschenswert ist und zu Kompatibilitätsproblemen führen würde.

Anstatt den Hash der sortierten Outpoints zu verwenden, könnten wir vielleicht etwas verwenden wie: [...]

In der anschließenden Diskussion mit vielen Teilnehmern wurde eine Lösung gefunden, die die Anforderungen erfüllt und für Hardware-Wallets umsetzbar ist: Hashing mit nur einem Input, dem kleinsten in lexikografischer Reihenfolge. Diese Lösung landete in der endgültigen Version des BIP und ermöglichte es uns, die Unterstützung für Silent Payments in der BitBox02 ohne Komplikationen umzusetzen.

Zusammenfassung

Wir haben das Konzept der Silent Payments vorgestellt, ein Bitcoin-Improvement-Proposal für ein neues Bitcoin-Adressformat, mit dem statische Adressen wiederverwendet werden können und gleichzeitig die Privatsphäre gewahrt bleibt. Wir haben uns mit den Grundlagen von privaten und öffentlichen Schlüsseln beschäftigt und den Prozess der Erstellung eines gemeinsamen Geheimnisses mit Hilfe der elliptischen Diffie-Hellman-Kurve (ECDH) besprochen und wie man damit Coins so locken kann, dass nur der Empfänger sie ausgeben kann.

Im nächsten Teil werden wir einen Blick darauf werfen, wie Silent Payments die Rolle von Hardware-Wallets verändern und was Hardware-Wallets tun müssen, um Silent Payments sicher zu unterstützen.

Du hast noch keine BitBox?

Deine Kryptowährungen sicher zu halten muss nicht schwer sein. Die BitBox02 Hardware Wallet speichert die privaten Schlüssel deiner Kryptowährungen offline. So kannst du deine Coins sicher verwalten.

Die BitBox02 gibt es auch als Bitcoin-only-Version mit einer radikal fokussierten Firmware: weniger Code bedeutet weniger Angriffsfläche, was deine Sicherheit weiter verbessert, wenn du nur Bitcoin speicherst.

Hol dir eine in unserem Shop!‌

Häufig gestellte Fragen (FAQ)

Was sind Silent Payments?
Silent Payments sind ein neues Bitcoin-Adressformat, das statische Adressen ermöglicht und gleichzeitig die Privatsphäre bewahrt, indem nur der Absender und Empfänger Transaktionen erkennen können.

Wie funktionieren Silent Payments?
Sie verwenden kryptografische Techniken, um für jede Transaktion, die an eine Silent Payments-Adresse gesendet wird, einen neuen öffentlichen Schlüssel zu generieren, ohne die Privatsphäre des Nutzers zu gefährden.

Welche Vorteile bieten Silent Payments?
Silent Payments eliminieren die Notwendigkeit, für jede Transaktion neue Adressen zu erstellen, und bieten so ein besseres Nutzererlebnis und höhere Privatsphäre.

Können Silent Payments von Börsen genutzt werden?
Ja, Börsen könnten eine einzige Silent Payments-Adresse für alle Abhebungen registrieren, ohne die Privatsphäre ihrer Nutzer zu gefährden.

Warum ist die BitBox02 relevant für Silent Payments?
Die BitBox02 ist die erste Hardware-Wallet, die Silent Payments sicher durchführen kann und wird in einem zukünftigen Update das Senden an Silent Payments-Adressen unterstützen.

Die BitBox-Produkte werden von Shift Crypto, einem privaten Unternehmen mit Sitz in Zürich, Schweiz, entwickelt und hergestellt. Unser Team aus Bitcoin-Entwicklern, Krypto-Experten und Sicherheitsingenieuren entwickelt Produkte, die unseren Kunden eine stressfreie Reise vom Anfänger zum Meister der Kryptowährung ermöglichen. Die BitBox02, unsere Hardware-Wallet der zweiten Generation, ermöglicht es den Nutzern, Bitcoin und andere Kryptowährungen zu speichern, zu schützen und mit Leichtigkeit zu handeln – zusammen mit der dazugehörigen Software, der BitBoxApp.