Silent Payments und die kommenden Privacy-Upgrades

Neugier

1. Wie kann eine einzige öffentliche Adresse unbegrenzt viele Zahlungen empfangen, ohne zu verraten, dass sie zur selben Entität gehören?
2. Warum zerstört ein einziger zusätzlicher Input des Empfängers die Annahme gemeinsamen Eigentums, auf die sich Chain-Analysten stützen?
3. Welcher kryptografische Trick ermöglicht es zwei Parteien, aus einem statischen Paar von Schlüsseln einen einzigartigen, nicht miteinander verknüpfbaren Ausgabeschlüssel abzuleiten?

Erkunden

Teil IVerbesserungen der Privatsphäre in Sicht

1. Bitcoin-Adressen sind wiederverwendbar, was On-Chain-Verknüpfungen erzeugt. Veröffentlicht ein Händler eine einzige Adresse für alle Kunden, ist jede Zahlung an diese Adresse im Ledger sichtbar miteinander verbunden. Diese Verknüpfbarkeit untergräbt die Privatsphäre, weil jeder den Geldfluss über die Zeit verfolgen kann. Silent Payments (BIP352) lösen dieses Problem mithilfe von Elliptic-Curve-Diffie-Hellman. Der Empfänger besitzt ein statisches Paar aus Scan-Key und Spend-Key. Jeder Sender kombiniert die Schlüssel seiner Inputs mit dem Scan-Key des Empfängers, um einen einzigartigen Tweak abzuleiten, und erzeugt so eine einmalige Taproot-Adresse, die von keinem anderen On-Chain-Output zu unterscheiden ist.
2. Da sich die abgeleitete Adresse bei jeder Transaktion ändert, erscheinen keine zwei Zahlungen an denselben Händler in den Blockchain-Daten als miteinander verbunden. Der Empfänger scannt die Chain mit seinen privaten Schlüsseln, um diese einzigartigen Outputs zu erkennen, ohne vorher mit dem Sender interagieren zu müssen. Damit entfällt die Notwendigkeit eines Drittanbieter-Servers oder einer Echtzeitkommunikation zur Erzeugung neuer Adressen. Der Vorgang ist für den Scannenden rechenintensiv, bietet aber beiden Parteien eine starke Unverknüpfbarkeit und stellt sicher, dass passive Beobachter die Einnahmen eines Händlers nicht einfach aufsummieren können.
3. Payjoin (BIP78) geht das Privatsphäre-Problem von einer anderen Seite an: über die Transaktionsstruktur. Chain-Analysten stützen sich auf die Common-Input-Ownership-Heuristik, um Inputs derselben Entität zusammenzufassen. In einer Standardtransaktion kontrolliert der Sender alle Inputs. Payjoin erlaubt es dem Empfänger, vor dem Signieren einen Input zur Transaktion beizusteuern. So werden die Coins des Empfängers in einer einzigen Transaktion mit denen des Senders gemischt, was die Annahme bricht, dass alle Inputs einer Partei gehören. Das Ergebnis sieht wie eine gewöhnliche Zahlung aus, sodass ein Analyst, der annimmt, alle Inputs gehörten dem Sender, den falschen Schluss zieht.
4. Version 2 (BIP77) macht es überflüssig, dass der Empfänger einen öffentlichen Server betreibt: Die beiden Seiten tauschen verschlüsselte PSBTs asynchron über einen Verzeichnisserver aus, der über Oblivious-HTTP-Relays erreicht wird, sodass das Verzeichnis die Nachrichten weder lesen noch IP-Adressen zuordnen kann. Zwar verbirgt das nicht, dass überhaupt eine Transaktion stattfindet, doch es erschwert das Clustering von Adressen erheblich, weil Inputs zweier verschiedener Eigentümer in einer Transaktion stehen, die so aussieht, als hätte sie nur einen Eigentümer.
5. Privatsphäre auf Netzwerkebene erfordert das Verbergen von Verkehrsmustern. Verschlüsselter Peer-to-Peer-Transport (BIP324) wurde 2024 mit Version 27 von Bitcoin Core zum Standard. Er verbirgt vor passiven Beobachtern den Inhalt der Nachrichten, also welche Transaktionen und Adressen eine Node weiterleitet; welche IP-Adressen mit welchen verbunden sind, bleibt sichtbar, und die Verschlüsselung ist nicht authentifiziert, verhindert also keinen aktiven Man-in-the-Middle-Angriff. BIP324 nutzt einen Schlüsselaustausch über elliptische Kurven, bei dem die Schlüssel so kodiert sind, dass sie wie zufällige Bytes aussehen, und anschließend ChaCha20-Poly1305-Verschlüsselung – dadurch ist es viel schwieriger, durch Mitschneiden des Datenverkehrs bestimmte Transaktionen bestimmten Nodes zuzuordnen.
6. Die Forschung an Cross-Input Signature Aggregation (CISA) geht weiter; damit könnten sich alle Inputs einer Transaktion eine einzige Signatur teilen. Gemeinschaftliche Transaktionen wie Coinjoins, die viele Inputs haben, würden dann günstiger als das getrennte Ausgeben derselben Coins, sodass Privatsphäre zur Gebührenersparnis wird. Anders als CoinJoin, das im Abschnitt zu Verwahrungsmechanismen behandelt wird, konzentrieren sich diese Upgrades auf kryptografische Struktur und Netzwerktransport statt auf soziale Koordination oder serververmitteltes Mixing.

Teil IISilent Payments

7. BIP-352, im Mai 2024 in das BIP-Repository aufgenommen, führt Silent Payments ein. Ein Empfänger veröffentlicht einen einzigen statischen Code, der aus zwei öffentlichen Schlüsseln besteht: einem Scan-Key und einem Spend-Key. Anders als herkömmliche Adressen bleibt dieser Code während der gesamten Lebensdauer der Wallet gleich. Die Wallet des Senders nutzt ihre eigenen privaten Input-Schlüssel, um für jede Zahlung eine neue, eindeutige Taproot-Adresse abzuleiten, sodass es weder über verschiedene Sender noch über verschiedene Transaktionen hinweg zu Adresswiederverwendung kommt.
8. Der Mechanismus beruht auf Elliptic-Curve-Diffie-Hellman (ECDH). Wenn Alice an Bobs Silent-Payment-Code sendet, kombiniert ihre Wallet ihren privaten Input-Schlüssel mit Bobs öffentlichem Scan-Key. Daraus entsteht ein gemeinsames Geheimnis, das als Tweak dient. Zu Bobs öffentlichem Spend-Key addiert, erzeugt dieser Tweak einen Ziel-Output P. Da die Ableitung von den Schlüsseln und Outpoints ihrer Inputs (einem „Input-Hash“) sowie einem Zähler für jeden Output abhängt, ergibt jede Zahlung eine eigene Adresse, die von keinem anderen Taproot-Output zu unterscheiden ist.
9. Der Preis dafür ist eine rechnerische Asymmetrie. Während Sender gewöhnliche Signaturvorgänge ausführen, müssen Empfänger die Blockchain aktiv scannen, um eingehende Zahlungen zu erkennen. Bob kann nicht einfach prüfen, ob eine bestimmte Adresse Guthaben aufweist; für jede Transaktion mit geeigneten Inputs kombiniert er seinen privaten Scan-Key mit der Summe der öffentlichen Schlüssel ihrer Inputs und prüft, ob ein Output übereinstimmt. Dieser Scanvorgang ist rechenintensiv und stellte leichtgewichtige SPV-Clients bislang vor Herausforderungen.
10. Die resultierenden Transaktionen fügen sich nahtlos in herkömmliche Bitcoin-Überweisungen ein. Es gibt keine zusätzlichen Datenfelder, keine größere Transaktionsgröße und keine Server Dritter zur Koordination. Ein außenstehender Beobachter sieht nur gewöhnliche Taproot-Inputs und -Outputs. Die Verbindung zwischen den Input-Schlüsseln des Senders und dem statischen Code des Empfängers ist kryptografisch verborgen, sodass Beobachter die Zahlung nicht mit dem veröffentlichten Code des Empfängers in Verbindung bringen können.
11. Die Unterstützung durch Wallets ist seit der Veröffentlichung der Spezifikation stetig vorangekommen. Cake Wallet führte die Unterstützung 2024 ein. Sparrow Wallet ergänzte im Oktober 2025 das Senden und im Mai 2026 das Empfangen. Nunchuk ergänzte 2026 das Senden. Bitcoin Core übernahm 2026 die zentrale BIP-352-Logik (PR #35301), während Senden und Empfangen in der Wallet noch geprüft wurden und noch in keinem Release enthalten waren.
12. Silent Payments lösen das Problem der Adresswiederverwendung, ohne dass eine Interaktion zwischen Sender und Empfänger oder Koordinationsserver wie bei CoinJoin-Protokollen nötig sind. Der Empfänger nutzt eine einzige statische Kennung für alle Zwecke – Gehälter, Rechnungen, Spenden –, während jeder eingehende UTXO auf einer eigenen, nicht verknüpfbaren Adresse landet. Das stärkt die Fungibilität, weil die Graphenanalyse mehrere Zahlungen nicht derselben Entität zuordnen kann, vorausgesetzt, der Scanvorgang des Empfängers ist robust und sicher.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• BIP 352: Silent Payments (Somsen, Baker et al., 2023)
• BIP 78: Payjoin v1 and BIP 77: Payjoin v2
• BIP 324: Encrypted Peer-to-Peer Transport
• Bitcoin Core 27.0 Release Notes (2024)
• Sparrow Wallet release notes (October 2025, May 2026)
• Cake Wallet documentation (2024)
• Bitcoin Core pull request #35301 (2026)