Silent Payments für Bitcoin biegt in die Zielgerade ein
Pssst ... Bild von Dennis Skley via flickr.com. Lizenz: Creative Commons.
Silent Payment Addresses sollen es ermöglichen, Bitcoins wiederholt an dieselbe Adresse zu senden, ohne an Privatsphäre zu verlieren. Das Protokoll könnte einen langen Wunsch der Bitcoin-Szene erfüllen – und hat nun endlich eine BIP-Nummer bekommen.
Bitcoin-Transaktionen sind, wie ihr hoffentlich alle wisst, pseudonym. Sie sind nicht anonym, weil sie an eine Adresse gebunden sind, aber pseudonym, weil diese Adresse nicht an eure Identität gekoppelt ist. Wenn es euch gelingt, diese Verbindung zu vermeiden, bietet euch Bitcoin eine angemessene finanzielle Privatsphäre.
Wenn … es gelingt.
Denn es ist nicht ganz trivial, zu verhindern, dass Experten für die Onchain-Spionage, deren Server die Blockchain ununterbrochen auswerten, mehr über einen wissen, als man ahnt, enthüllt zu haben. Es passiert schnell, dass man durch ein paar unbedachte Transaktionen versehentlich eine ganze Wallet kompromittiert hat, ohne es auch nur zu bemerken.
Das wichtigste Werkzeug, wie man seine Privatsphäre bei Bitcoin wahrt, ist das Wissen: Wissen darum, wie Transaktionen funktionieren, wie Blockchain-Analysten arbeiten, welche Wallets am besten geeignet sind, um privat zu bleiben.
Eine elementare Praxis, um zumindest eine Basis-Privatsphäre zu halten, ist es, für jede eingehende Zahlung eine neue Adresse zu verwenden. Dies macht es für Blockchain-Beobachter deutlich schwieriger, eure Wallets zu identifizieren. Allerdings ist es nicht in jeder Situation möglich, neue Adressen zu verwenden, etwa wenn man auf einer Webseite eine Adresse für Spenden postet.
Vorschläge, wie man dieses Problem lösen kann, wurden im letzten Jahrzehnt viele gemacht. Doch Silent Payments könnte der erste sein, der es in naher Zukunft in die Wallets schafft.
Die Magie der Kryptographie
Silent Payments ist eines der Protokolle, bei denen die Mathematik der Kryptographie magisch wird. Sie macht etwas, von dem man gedacht hätte, dass es gar unmöglich sein sollte, aber das vollkommen logisch wird, wenn man sich die Gleichungen anschaut.
Zunächst generiert der Empfänger einer Zahlung, erklärt Ruben Somsen, der Erfinder des Protokolls, “eine sogenannte Silent Payment Adresse und veröffentlicht diese.“ Bis hierhin ist der Vorgang ganz normal. Interessant wird es, wenn der Sender ins Spiel kommt. Denn dieser bezahlt nicht direkt an die Adresse, sondern „nimmt einen öffentlichen Schlüssel seiner gewählten Inputs und benutzt diesen, um ein geteiltes Secret abzuleiten, durch das er dann die Silent Payment Adresse modifiziert.“
Ich vermute, ihr habt so wenig verstanden wie ich beim ersten Anlauf. Der Sender verändert die Adresse, so dass die öffentlich sichtbare Adresse für einen Beobachter wertlos wird. Er generiert eine neue Adresse anstelle des Empfängers. Doch wie kann dieser dennoch einen Zugriff auf die Adresse haben, die er gar nicht gebildet hat?
Um das zu verstehen, muss man wissen, dass es es gibt zwar für jeden der möglichen 2256 privaten Schlüssel nur einen passenden öffentlichen Schlüssel gibt, aber die Adresse, die aus dem öffentlichen Schlüssel abgeleitet wird, in einem Format ist, welches nur maximal 2160 Adressen zulässt. Es gibt also eine fast unendliche Anzahl von möglichen Adressen je öffentlichem Schlüssel. Die Silent Payment Address enthält nun die Informationen, die der Sender braucht, um aus dem öffentlichen Schlüssel neue Adressen abzuleiten, welche der Empfänger mit seinem privaten Schlüssel öffnen kann.
Der Empfänger hat also bereits den privaten Schlüssel, noch bevor der Sender eine Adresse generiert hat. Aber woher weiß er überhaupt von der Adresse? Er hat sie ja nicht gebildet, und es ist zu unmöglich, alle potenziellen Adressen zu kennen. Das ist die schwierigere Frage, die eine Variante des Diffie-Hellman-Schlüsseltauschs beantwortet: Der Sender verwendet einen Input der Transaktion als Geheimnis, um die Adresse anzupassen. Damit wird die Blockchain zum Nachrichtenkanal. Dem Empfänger ist es möglich, durch einige Kalkulationen, die nur er, als Besitzer des privaten Schlüssels, ausführen kann, zu erkennen, ob ein beliebiger Input ein Geheimnis für seine Silent Payment Address ist.
Der Empfänger muss also, um von der Theorie in die Praxis zurückzugehen, “lediglich” jeden einzelnen Input der Blockchain scannen und verarbeiten, um zu erfahren, ob eine stille Zahlung erhalten hat. Über diese kann er dann in seiner Wallet verfügen, während ein Blockchain-Beobachter im Dunkeln bleibt.
Wie aufwändig ist es für die Wallet?
Silent Payments haben einen klaren Vorteil gegenüber anderen Konzepten: Weder müssen die Parteien einer Zahlung eine bestimmte Information austauschen, etwa einen Xpub-Key, was seine ganz eigenen Nachteile hat, noch müssen sie anderweitig miteinander kommunizieren oder Informationen per OP_Return in der Blockchain hinterlassen. Kein bisheriges Verfahren hat die Usererfahrung ganz normaler Adressen so gut rekonstruiert wie Silent Payments.
Der offensichtliche Nachteil ist aber, dass das Scannen der gesamten Blockchain nicht eben eine triviale Aufgabe ist, die etwa für Light-Clients gar nicht zu erfüllen ist. Man braucht einen Full Node, und der muss mehrere Stunden lang arbeiten, um zu erkennen, ob man bezahlt wurde. Dies ist ein äußerst schwerer Hemmschuh dafür, dass sich das Verfahren jemals in der Praxis durchsetzt.
Glücklicherweise lässt sich dieses Problem entschärfen. Man könnte etwa nur das UTXO-Set scannen anstatt die gesamte Blockchain, also 4-5 Gigabyte anstatt ein halbes Terrabyte. Dadurch entgehen dem Scan zwar bereits ausgegebene Transaktionen, aber er findet das gesamte verfügbare Guthaben. Nach einer einmaligen Synchronisierung ist es zudem nur noch notwendig, neue UTXO-Einträge zu prüfen, und weil Silent Payments im Taproot-Format sind, reicht es auch, nur Taproot-Outputs zu erkennen.
Damit werden Silent Payment Addresses gar nicht so unpraktisch, wie es auf den ersten Blick erscheint. Gut umgesetzt sollten nicht nur Bitcoin Nodes, sondern auch SPV-Wallets und womöglich auch Electrum-Wallets in der Lage sein, Silent Payments relativ zügig zu erkennen. Im Grunde steht der Implementierung nichts mehr im Weg – außer die übliche Prozedur der Core-Entwicklung.
Von Version zu Version
Das Silent Payment Protocoll existiert bereits seit ein paar Jahren und gilt als hoffnungsvollstes Verfahren, um das Problem der wiederverwendbaren Adressen zu lösen. Im Lauf dieser Jahre wurde das Protokoll vielfach diskutiert und angepasst.
Nachdem Ruben und seine Mitentwickler im vergangenen Jahr mehrere Versionen entwickelt haben, traten sie im Juni 2023 mit der vierten oder fünften Version an die Mailing-List der Bitcoin-Entwickler, um sich für ein „Bitcoin Improvement Proposal“ (BIP) zu qualifizieren. Ein BIP ist die Voraussetzung, um eine Idee in den Bitcoin-Client zu bringen.
In diesem Zuge erhielt Silent Payment Addresses die BIP-Nummer 352, doch es gab auch weitere Diskussionen und Anmerkungen. Ruben und sein Team haben diese umgesetzt und im August eine Version vorgestellt, die nun annährend final ist. Die Änderungen seit Juni bleiben bei Details, die das generelle Konzept nicht anrühren, sondern nur die Umsetzung um einige kleine Parameter anpassen. Das ist ein ziemlich gutes Zeichen für die Reife und Akzeptanz des Vorschlags.
Dennoch gibt es noch die eine oder andere Frage. Peter Todd merkt an, dass Silent Payment Addresses ein Ablaufdatum haben sollten, falls jemand eine Wallet verliert. Denn anders als normale Adressen seien Silent Payment Addresses explizit dafür gemacht, wiederverwendet zu werden, weshalb es möglich ist, dass jemand die Adresse einmal speichert und immer wieder an sie bezahlt. Ein Ablaufdatum könnte einfach durch ein 3-Byte-Feld an die Adresse angehängt werden und solche Verluste verhindern.
Die Diskussion zu Silent Payment Addresses ist damit noch nicht ganz am Ende. Aber sie hat einen Zustand erreicht, bei dem dem die Chance, es bald als Teil der Bitcoin-Wallets zu sehen, gar nicht so gering ist.
Hoi, ein paar Entwickler haben nach 9 Jahren erkannt, dass Moneros Stealth Adressen (die es als BIP47 auch für Bitcoin gab) doch nicht sooo doof sind?
Tim Ruffing, ein Kryptograph aus den USA (der nicht direkt mit Monero verbunden ist, aber auch immer wieder gute Inputs einbringt) merkte das auch passend an: https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8?permalink_comment_id=4116972#gistcomment-4116972
Den initialen Sync sehe ich als überhaupt kein Problem an, die meisten User werden sich eine neue Wallet in der Software erstellen, die das zügig unterstützt und der initiale Sync entfällt, da höchstwahrscheinlich niemand eine Zahlung zu einem früheren Datum als der Walleterstellung an eine passende Adresse geschickt hat. Im laufenden Betrieb ist das überhaupt kein Problem, da nur neue UTXO gescannt werden müssen. Ich habe mir die Implementierung hier noch nicht im Detail angesehen, aber bei Monero ist das mittlerweile selbst mit Remote Nodes kein Problem, da größtenteils nur Blockheader übertragen werden müssen, und dank kürzlich eingeführter “View Tags” müssen nur 1/256 in Frage kommender Transaktionen geprüft werden. In der Praxis bedeutet das, dass ein Sync eines Mobile Wallets, welches ca. 5.000 Blöcke zurück ist (etwa eine Woche), meist unter 30 Sekunden dauert. Anders als bei Bitcoin kann man auch einen Teil seiner Privatsphäre mit dem “Private View Key” an einen Light Wallet Node abgeben, der dann die Blockchain im Hintergrund scannt und immer synchronisiert ist, er sieht dann zwar alle eingehenden UTXO, aber kann nicht über diese verfügen und weiß auch nicht, ob und wann diese ausgegeben wurden. Beides ist jedenfalls viel zugänglicher auch für Mobile Wallets als etwa LN mit Interaktivität, Channel Management, eingehender Liquidität, Routen usw., denn man kann getrost Monate oder Jahre offline sein und seine Transaktionen dieser gesamten Zeit erhalten.
Einen großen Nachteil bei Bitcoin sehe ich darin, dass man auf Teufel komm raus die Abwärtskompatibilität aufrecht erhalten will, die in Wahrheit keine ist. Veraltete Nodes und Wallets meinen zu wissen, was auf der Blockchain los ist, haben derweil keine Ahnung davon, was aus meiner Sicht noch gefährlicher ist. Sie wissen weder was auf SegWit noch bei Taproot los ist, haben also ein verzerrtes Bild vom aktuellen Stand. Auch könnten sie nicht mit einem wiederholt neuen Adressformat etwas anfangen und könnten nicht an dieses senden. Warum macht man es nicht zum Standard, wie auch bei Monero, damit jeder User von der verbesserten Privatsphäre profitiert, die der durchschnittliche Bitcoin User nur meint zu haben.
Der zweite Punkt ist, dass man jedes Feature in alle Richtungen durchdenken muss, was zwar prinzipiell gut ist, aber wenn man keine realistische Möglichkeit zur Nachbesserung hat, kann man keine künftigen Technologien oder Erkenntnisse einplanen, die schlicht nicht verfügbar sind und das ist beim technologischen Fortschritt gewaltig. Siehe oben genannte View Tags von Monero, die (wenn ich mich richtig erinnern kann), die einzige Veränderung der Stealth Adressen war, nach ca. 8 Jahren, die Performance beim Scannen der Transaktionen wurde allerdings mehrfach an anderer Stelle verbessert.
Nichtsdestotrotz befürworte ich diesen Vorschlag, jede Verbesserung der Privatsphäre ist positiv zu bewerten!
Wenn man schon an BTC herumändert, dann konsequent. Statt sich gegenseitig zu bekämpfen, sollte man mit offenen Augen schauen, was andere Projekte machen und was man voneinander lernen kann, wie @Paul auch andeutet. Dieses Softgeforke halte ich auch für problematisch. Welche Regeln gelten nun? Man stelle sich vor, die Mehrheit der Hashrate würde zum Vor-Segwit zurückkehren. Das würde interessant ;-).
Ein ganz einfacher Ansatz zur Erhöhung der Privatsphäre ist übrigens, beliebig viele Transaktionen pro Block zuzulassen. Der Suchraum für Analysen wächst enorm. Was das Scannen der UTXO Mengen betrifft, so hat man bei BTC immer noch nicht die Sicht akzeptiert, wie man sie bei BSV propagiert: Alice gibt eine Transaktion zusammen mit zugehörigen Merklepfaden an Bob. Bob kann anhand dieser Information + der Liste der Blockheader (4MB pro Jahr) verifizieren. Und dann registriert Bob die Trx im Netzwerk, und bekommt dann davon den Merklepfad. Richtig verbreitet ist es aber auch bei BSV (noch?) nicht.
Hm, aber wenn ich das empfangene Geld dann transferieren muss, ist der dabei eingesetzte und in dieser Transaktion nun auch veröffentlichte Public Key, doch für alle abgeleiteten Silent Adressen derselbe, oder verstehe ich da was falsch?
Dann könnte man zwar voll viel Geld auf verschiedenen Adressen heimlich empfangen, aber sobald man es für etwas ausgeben möchte, wäre es wieder verknüpft.
Das ist analog zu HD-Wallets, die keine Adressen wiederverwenden, also so gut wie alle modernen “nur” ein Problem, wenn Du alle UTXO bündelst, um sie z.B. an eine Börse zu schicken, dann offenbarst Du zwar nicht direkt Deine wirkliche Adresse, aber dass alle UTXO in einer Wallet mit den zugehörigen Keys lagen. Stealth Adressen bieten lediglich Receiver Privacy, keine Sender Privacy und wenn ein Angreifer Dich enttarnen wollte, schickt er eben regelmäßig etwas “Dust”, also kleine Beträge an die Donation Adresse und sobald deren UTXO mit anderen zu einer Transaktion gebündelt werden, sieht man die anderen Sender.
Am Beispiel der kanadischen Trucker, deren PayPal Accounts geschlossen wurden und sie dann auf Bitcoin umgestiegen sind, um Spenden zu sammeln, deren Adressen auf Börsen geblacklistet wurden, wäre das nicht direkt möglich. Wenn Behörden aber kleine Beträge mitgespendet hätten, würden sie erkennen, sobald sich diese bewegen und könnten die Transaktion an eine Börse erkennen und dort ggf. Alarm schlagen (wenn es noch nicht zu spät wäre, weil die Coins schon getradet wurden).
Deswegen ja der ganze Aufwand mit Ring Signaturen bei Monero, bei denen jede UTXO mit aktuell 15 anderen gebündelt wird, bald wahrscheinlich 64 oder 128 und es nicht erkennbar ist, welche ausgegeben wurde. Leider führt das aber auch dazu, dass es keine UTXO gibt, sondern TXO, da man nicht sagen kann, welche bereits ausgegeben wurden und welche nicht. Beim Bündeln mehrere TXO wird für jede einzelne ein eigener Ring mit ganz unterschiedlichen anderen gebaut.
Ja das meine ich. An DustPayments hatte ich dabei noch nicht mal gedacht, aber die Dustpayments könnte man auf den heimlichen Empfängeradresse prinzipiell ja einfach liegen lassen – wenn man dem Reiz des Ausgebens da wiederstehen kann ;-).
Hm, geht mir ähnlich. 🙂
Beim grundsätzlichen Diffie-Hellmann Schlüsselaustausch wird ein gemeinsamer geheimer shared Key erzeugt den beide, Empfänger und Sender, anschliessend kennen.
Das ist hier glaub ich auch so. Dann wäre es tatsächlich nicht immer derselbe Public-Key der die anschliessende Tx ausgeben würde.
Der Sender hätte bis zum Weitertransfer nach wie vor Zugriff auf den versendeten Betrag. Ich versteh nicht ganz, ob das vorgeschlagenen Verfahren dass vermeidet.
Im Falle einer anonymen Spende wäre das aber vermutlich eh kein Problem. Wer anonym spendet, zieht sein Spende vermutlich auch nicht gleich wieder ein.
Als nachweisbare Zahlung für irgendetwas, kann man es dank der Deniability seitens des Empfängers eh nicht wirklich verwenden.
Wenn der Sender den privaten Key (wenn auch nur des von ihm gesendeten Outputs) kennen würde, wäre es katastrophal, also ausgeschlossen.
Bei HD-Wallets, die im Normalfall immer eine neue Adresse für Change & Co. erstellen wird für jede (Sub-)Adresse durch Hinzufügen einer Art Index an den Hauptschlüssel ein neues Schlüsselpaar erzeugt, das ist einfach, da lokal.
Monero nutzt auch das Diffie-Hellman Verfahren für seine Stealth Adressen, es ist hier auf Seite 45 unten genau erklärt: https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
Hier hat das sogar jemand mit Bezug auf Bitcoins ursprüngliche Stealth Adressen erklärt: https://monero.stackexchange.com/questions/1500/what-is-a-stealth-address
Hierbei muss man beachten, dass Monero zwei Schlüsselpaare statt einem wie bei Bitcoin hat. Einen jeweils einen privaten und öffentlichen Spend und einen View Key. Mit dem öffentlichen Spend Key und einem Zufallsstring erstellt man die Stealth Adresse, die man nur mit dem privaten View Key zuordnen kann. Zum Ausgeben benötigt man aber zusätzlich noch den privaten Spend Key, den der Sender zu keinem Zeitpunkt hat. Ob das bei Bitcoin auch durch ein zusätzliches Schlüsselpaar gelöst werden soll, kann ich leider nicht beurteilen, da ich mich leider noch nicht im Detail mit Silent Payments beschäftigt habe.
Warum wäre das denn eigentlich katastrophal? Im Falle einer anonymen Spende hat der Spender ein großes Interesse daran, dass die Spende auch ankommt. Einen Publicity Gain hat er ja sowieso nicht davon.
Von einem späteren Zurückziehen des Betrags hätte er also nichts.
Zudem könnte man den Spende-Transfer erst als abgeschlossen werten, wenn der Betrag vom Empfänger weitertransferiert worden wäre.
Da keine dritte Partei den gemeinsamen Schlüssel kennt, weiss zudem jeder der beiden Parteien, dass wenn er den Betrag nicht selbst transferiert hat, es die andere Partei gewesen sein muss.
Das was Du beschreibst, lässt sich schön mit MultiSig abbilden und ein Transfer ohne Finalität, da man selbst den Key noch kennt, ist kein Transfer. Schlimmer noch, er ermöglicht Anschuldigungen, da man nicht weiß, wer die Coins schließlich verwendet hat…
Glaub ich nicht. Eine Multisigadresse zu bilden benötigt vorige bidirectionale Kommunikation zwischen Spender und Empfänger. Silent Payments hingegen nicht. Da veröffentlicht der Empfänger ja nur eine Silent Paymentadresse. Der Spender bildet damit die neue geheime Adresse und hat wenn ichs richtig verstehe über das gemeinsam bekannte Secret weiter Zugriff, falls der Empfänger z.B. den Betrag innerhalb von einem Zeitraum x (z.B. 3 Tagen) nicht weiter transferiert hat, kann er ihn zurückbuchen.
Prinzipiell kann es nur der jeweils andere gewesen sein. Und eine anonyme Spende über Silent Payments ist eh eine Art Geschenk, ein Quittung gibt es dafür eh nicht. Somit wären Anschuldigungen sinnfrei. So eine Spende gibt es ohne Gegenleistung, Und zurückverlangen kann ich sie natürlich auch nicht.
Ich vermute nicht. Um ehrlich zu sein habe ich die unterliegende Mathematik / Kryptographie nur im Ansatz verstanden.