Bitcoin Silent Payments: Praxisleitfaden 2026

Ein Wort zur Finanzierung: CypherpunkGuide trägt keine Überwachungswerbung — keine Werbenetzwerke, keine Tracking-Pixel, keine gesponserten Inhalte. Finanziert wird die Seite aus transparenten Quellen: jetzt durch Spenden der Leserinnen und Leser; später durch ein Abo und durch redaktionell passende Affiliate-Links. Wir sind unseren Leserinnen und Lesern verpflichtet, nicht den Werbetreibenden.

Im Empfangen von Bitcoin steckt ein leiser Widerspruch. Jeder Ratgeber schärft dir ein, eine Adresse niemals wiederzuverwenden — die Wiederverwendung ist eines der saubersten Signale, die einer Analystin zur Verfügung stehen. Doch sobald du bezahlt werden willst — ein Trinkgeld-Hinweis im Profil, eine Spendenzeile in einer README, eine Rechnung, die du einmal verschickst und dann vergisst —, brauchst du eine Adresse, die bleibt, wo sie ist. Wechselnde Adressen und eine feste Identität stehen im Widerspruch zueinander.

Silent Payments (BIP-352) sind das Protokoll, das diesen Widerspruch auflöst: Du veröffentlichst eine Adresse, und jede Person, die dich bezahlt, leitet daraus eine andere On-Chain-Adresse ab. Wer die Chain beobachtet, sieht also zusammenhanglose Ausgaben ohne gemeinsames Ziel. Das ist eine der bedeutendsten Verbesserungen der Privatsphäre beim Empfangen seit Jahren. Es wird aber ebenso oft missverstanden, ist je nach Wallet nur halbfertig umgesetzt und bringt echte Kosten mit sich, über die begeisterte Berichte gern hinweggehen.

Ich schreibe unter einem Pseudonym und behandle jede Münze, die ich halte, als längst beobachtet — also wollte ich das Protokoll nicht auf Treu und Glauben hinnehmen. Bevor ich ein Wort dieses Leitfadens schrieb, habe ich BIP-352 von Grund auf in Python nachgebaut — mit libsecp256k1 über die Bibliothek coincurve — und gegen die offiziellen Testvektoren der Spezifikation laufen lassen: 28 von 28 Teilfällen beim Senden und 29 von 29 beim Empfangen stimmten überein, Bit für Bit, in unter 200 Millisekunden (Bundle-Log). Es folgt, was in der Praxis gilt: was das Protokoll schützt, welche Wallets es 2026 liefern und welche Scan-Kosten du verstehen solltest, bevor du dich darauf verlässt.

Was eine Silent Payment wirklich ist (und was sie nicht schützt)

#

Eine Silent Payment ist eine wiederverwendbare Bitcoin-Adresse nach BIP-352 — eine einzige Zeichenkette, die du nur ein einziges Mal veröffentlichst. Jede zahlende Person leitet daraus eine für dich einzigartige, nicht verknüpfbare On-Chain-Adresse ab. Sie schützt die Verbindung beim Empfangen — den Zusammenhang zwischen einzelnen Zahlungen an dieselbe Identität — und sonst nichts. Sie verbirgt keine Beträge, sie schützt deine Senderinnen nicht, und gegen die Aufzeichnungen abseits der Chain, die Coins an deinen Namen binden, richtet sie nichts aus.

Die Adresse besteht aus zwei öffentlichen Schlüsseln — einem scan key und einem spend key —, die zusammen kodiert sind. Auf dem Mainnet beginnt sie mit sp1, in einem Testnetz mit tsp1 (der menschenlesbare Teil ist sp bzw. tsp, und die 1 ist bloß das bech32m-Trennzeichen). Bezahlt dich jemand, verbindet seine Wallet die eigenen Eingabe-Schlüssel mit deinem scan key zu einem gemeinsamen Geheimnis und leitet daraus eine frische Taproot-Ausgabe ab, die nur du erkennen und ausgeben kannst. Keine zwei Zahlenden erzeugen dieselbe Ausgabe, und es gibt keine „Benachrichtigungs-Transaktion", die die Verbindung ankündigt — die entscheidende Verbesserung gegenüber dem älteren Zahlungscode-Ansatz aus BIP-47.

Was offen bleibt, sollte man klar benennen, denn das Wort „privat" verspricht in diesem Feld mehr, als es einlöst. Silent Payments sind ein Werkzeug fürs Empfangen. Der Betrag, den du empfängst, steht weiterhin sichtbar auf der Chain. Die Privatsphäre der zahlenden Person ist deren Sache, nicht deine. Und der stärkste Angriff auf ein namentlich bekanntes Pseudonym ist selten die Chain — es sind die Texte, die Metadaten, die KYC-Börse, an der Coins an einen Ausweis gebunden werden. Das ist das additive Modell, dargelegt in wie das On-Chain-Tracing wirklich funktioniert und, abseits der Chain, in KI-De-Anonymisierung. Silent Payments schließen eine bestimmte, wertvolle Lücke. Sie sind notwendig, nicht hinreichend.

Welche Wallets 2026 Silent Payments unterstützen

#

Die Unterstützung ist real, aber ungleich, und die nützlichste Gewohnheit ist, Senden und Empfangen getrennt zu prüfen — sie kamen zu verschiedenen Zeiten, in verschiedenen Wallets, manchmal mit Jahren dazwischen. An eine Silent-Payment-Adresse zu senden ist inzwischen verbreitet; auf eine solche zu empfangen — wofür die Wallet die Chain scannen muss — ist neuer und seltener. Die Tabelle unten fasst Primärquellen zum Stand 2026-07-09 zusammen; prüfe vor jeder echten Zahlung die Release Notes des jeweiligen Projekts, denn diese Liste ist in Bewegung.

Zwei Vorbehalte, die die Tabelle nur grob zusammenfasst. Erstens ist „Empfangen" die Zeile, auf die es ankommt, und zugleich die, die hinterherhinkt — eine Wallet lässt dich die sp1-Adresse einer Freundin oft längst bezahlen, bevor sie eine eigene für dich halten kann. Zweitens ist die Art, wie eine Wallet scannt, eine Entscheidung über Privatsphäre und nicht bloß über Tempo — davon handeln die nächsten beiden Abschnitte. Wie du die Coins, die du auf diesem Weg empfängst, überhaupt erst erwirbst, ohne an der Börse eine Identitätsspur zu hinterlassen — das steht in Bitcoin ohne KYC kaufen.

Senden: der einfache Teil

#

Das Senden an eine Silent-Payment-Adresse ist der unkomplizierte Teil des Protokolls, denn die Senderin erledigt alles lokal und muss nie etwas scannen. In einer Wallet, die es beherrscht — Sparrow ist die Referenz auf dem Desktop —, fügst du die sp1…-Adresse der Empfängerin genau wie jede andere ins Senden-Feld ein, und die Wallet erledigt die Ableitung unsichtbar.

Im Hintergrund nimmt deine Wallet die privaten Schlüssel der Eingaben, die sie gerade ausgibt, verbindet sie mit dem scan key der Empfängerin zu einem gemeinsamen Geheimnis und leitet daraus eine einmalige Taproot-Adresse für genau diese Zahlung ab. Weil die Ableitung deine Eingaben mit einrechnet, liefert dieselbe Empfangsadresse jedes Mal eine andere On-Chain-Ausgabe — immer wenn eine andere Person oder ein anderer Satz deiner Coins bezahlt. Von der Empfängerin braucht die Senderin nichts außer der veröffentlichten Adresse: kein Hin und Her, keine Benachrichtigung, keine Interaktion. Deshalb kam die Unterstützung fürs Senden zuerst und ist heute der Normalfall. Diese Ungleichheit ist die ganze Geschichte des nächsten Abschnitts: Die Kosten, die das Senden vermeidet, sind genau jene, die das Empfangen nicht vermeiden kann.

Empfangen: die Scan-Kosten, vor denen dich niemand warnt

#

Um Silent Payments zu empfangen, muss deine Wallet infrage kommende Ausgaben über die gesamte Blockchain hinweg durchgehen und jede einzelne gegen deine Schlüssel prüfen, um die für dich bestimmten Zahlungen zu finden — es gibt keine Adresse auf der Chain, die man einfach „nachschlagen" könnte. Diese Scan-Kosten sind der zentrale, selten benannte Kompromiss von BIP-352, und wie deine Wallet ihn auflöst, entscheidet über deinen Komfort und deine Privatsphäre zugleich. Die Veröffentlichung der Adresse ist gratis — herauszufinden, was an sie gesendet wurde, nicht.

Betreibst du einen eigenen Full Node — deinen eigenen, vollständigen Bitcoin-Knoten —, ist das Scannen eine lokale Berechnung über die Blockdaten: aufwendig, aber privat, weil nichts deinen Rechner verlässt. Die Reibung entsteht, sobald du auf einem Handy oder Laptop ohne Node empfangen willst. Hier kommt ein Indexing-Server ins Spiel: ein Dienst, der das Abscannen für dich übernimmt. Bei Sparrow ist das Frigate (ein Electrum-Server für Silent Payments, neueste Version v1.5.3), und unter frigate.2140.dev läuft eine öffentliche Instanz. Du „besuchst" sie nicht im Browser — sie spricht das Electrum-Protokoll, nicht HTTP. In Sparrow findest du sie unter Preferences → Server → Public Server und testest anschließend die Verbindung.

Jetzt der Teil, den die begeisterten Anleitungen auslassen — und es ist ein Punkt der Privatsphäre, keine Fußnote. Damit ein Server für dich scannt, übergibt ihm deine Wallet deinen scan private key und deinen spend public key. Selbst wenn der Server sie nur im Arbeitsspeicher hält, wie Frigate es vorsieht, kann ein bösartiger oder kompromittierter Indexer mit ihnen genau das Bild rekonstruieren, das Silent Payments einer Beobachterin verwehren sollen: die vollständige Liste der Zahlungen, die du empfangen hast. Der Praxisleitfaden auf bennet.org sagt es unumwunden — ein schlechter Server „könnte genau das Bild deines Empfangsverlaufs zeichnen, das Silent Payments verhindern sollen." Die ehrliche Einordnung ist also ein Spektrum: Der eigene Node ist vollständig privat und mehr Arbeit; ein öffentlicher Indexer ist bequem und verlangt, dass du seinem Betreiber deinen Empfangsverlauf anvertraust. Wähle bewusst — und lass „Ich nutze Silent Payments" nicht zu einem trügerischen Sicherheitsgefühl werden, wenn der Server einer fremden Person dein Scannen erledigt.

Ich habe BIP-352 von Hand nachgebaut

#

Der schnellste Weg, einem Privacy-Protokoll zu vertrauen, ist, es laufen zu lassen und gegen die eigenen Zahlen der Spezifikation zu prüfen — genau das habe ich getan, statt den Behauptungen zu glauben. Meine von Grund auf geschriebene Umsetzung reproduziert alle 57 Teilfälle der offiziellen Testvektoren exakt — 28/28 beim Senden, 29/29 beim Empfangen —, und das vollständige Protokoll samt der Skripte liegt diesem Artikel bei (bip352-verification.txt), sodass du sie selbst nachvollziehen kannst. Aufschlussreicher als die Zahl der bestandenen Fälle ist jedoch, einer einzelnen Zahlung Schritt für Schritt bei der Ableitung zuzusehen.

Nimm eine veröffentlichte Adresse und verfolge, was eine Senderin berechnet. Die Werte unten sind echt, aus den offiziellen Testvektoren der Spezifikation:

Nun die Eigenschaft, die das Ganze erst lohnend macht. Ich habe selbst eine zweite, unabhängige Senderin gebaut — anderes Schlüsselmaterial, eine gedachte andere Münze — und mit ihr dieselbe veröffentlichte Adresse bezahlt (nichts wird hier gesendet; wie schon oben ist das reine Ableitung). Ihre Ausgabe lautete 3f1dd702…879b98ad. Zwei Zahlungen, eine Adresse — und auf der Chain haben die beiden Ausgaben nichts gemeinsam: keine geteilte Adresse, keine sichtbare Verbindung. Nur wer den scan key hält, kann zurückrechnen und beide als die eigenen erkennen. Das ist die Garantie der Privatsphäre beim Empfangen, und du siehst im nachgezeichneten Ablauf, wie sie standhält, statt sie als bloße Behauptung hinzunehmen. Es ist das On-Chain-Gegenstück zum Wiederverwendungs-Problem, das Bitcoin On-Chain-Privatsphäre seziert — dieselbe Bündelung, die die Wiederverwendung einer Analystin gratis liefert, hält diese Ableitung gerade zurück.

Die Fallstricke: Multisig, Labels und das K_max-Limit

#

Über die Scan-Kosten hinaus entscheiden drei Details der Umsetzung, ob Silent Payments zu deinem Anwendungsfall passen — und jedes davon willst du lieber vorher kennen als hinterher. Es sind genau die Stellen, die die „So funktioniert’s"-Erklärungen meist übergehen.

• Multisig und gemeinschaftliche Transaktionen sind heikel. Weil eine Senderin die Zahlung aus den privaten Schlüsseln der ausgegebenen Eingaben ableitet, verträgt sich das Senden aus einer Multisignatur-Wallet oder einem CoinJoin nicht sauber mit BIP-352: Die Signierschlüssel sind auf mehrere Parteien verteilt, die sie nicht einfach zusammenlegen dürfen. Silent Payments lösen die Verknüpfung durch Wiederverwendung, nicht das Problem des Mischens; willst du Beträge und Transaktionsgraph verbergen, bleibt das die Domäne gemeinschaftlicher Transaktionen, behandelt in On-Chain-Privatsphäre. Sieh sie als Ergänzung, nicht als Ersatz.
• Labels sind Komfort mit einem Haken. Mit BIP-352 kann eine Empfängerin beschriftete Varianten einer Adresse ableiten — praktisch, um auseinanderzuhalten, welche Ausgabe aus welcher Quelle stammt. Die Label-Information ist nur für dich von Bedeutung, nicht für andere, und auf der Chain taucht sie nicht auf. Aber es ist eine Buchführung, die du unterhältst — und damit eine, die eine kompromittierte Wallet oder ein kompromittiertes Backup verraten kann. Komfort, ehrlich verbucht.
• Es gibt eine Empfänger-Obergrenze, K_max = 2323. Die Spezifikation (v1.1.0, März 2026; aktuell v1.1.1, April 2026) begrenzt, wie viele Ausgaben eine einzelne Gruppe ableiten darf — als Schutz gegen Transaktionen, die eigens gebaut sind, um die Scan-Arbeit einer Empfängerin in die Höhe zu treiben. Als Einzelperson stößt du nie daran — aber genau deshalb scheitert ein naives „zahle 3.000 Ausgaben an eine Adresse" schon im Ansatz, und es zeigt dir, dass die Autoren des Protokolls den Angriff über die Scan-Kosten ernst genommen haben.

Ein nüchterner Blick auf Light-Clients, denn hier halten viele das Scan-Problem bereits für gelöst: Mit Stand Mitte 2026 gibt es kein einziges produktionsreifes, vertrauensminimiertes Light-Client-Werkzeug, das du einfach installieren kannst. Der Wallet-Daemon blindbitd wurde im August 2025 archiviert; nur sein begleitender Indexer blindbit-oracle wird noch aktiv gepflegt, und die Light-Client-Spezifikation ist weiterhin in Arbeit. Experimentelle Bibliotheken wie bdk-sp gibt es, aber deren eigene Autoren raten von der Nutzung im Mainnet ab. Wenn ein Ratgeber den Empfang von Silent Payments per Handy als gelöste Sache ohne Kompromisse darstellt, ist er der Software voraus.

Fazit: Solltest du Silent Payments schon nutzen?

#

Silent Payments sind reif für eine bestimmte, wertvolle Aufgabe — eine wiederverwendbare, öffentliche Empfangsadresse, die keine Verbindung durch Wiederverwendung preisgibt — und noch nicht reif dafür, dein einziges Privacy-Werkzeug oder ein reibungsloser Standard fürs Handy zu sein. Passe das Werkzeug der Aufgabe an, und betreibe einen eigenen Node, wenn dein Empfangsverlauf heikel ist. Das ehrliche Ziel ist hier bessere Privatsphäre beim Empfangen, nicht Anonymität.

Wie dein Fall auch liegt, die Reihenfolge bleibt dieselbe wie immer: Benenne den Gegner, schließe zuerst die billigen und unumkehrbaren Verbindungen — Erwerb ohne KYC, wo es erlaubt ist, sorgsamer Umgang mit Coins, nie eine gewöhnliche Adresse wiederverwenden — und setze Silent Payments dort ein, wo sie die eine bestimmte Lücke schließen: eine veröffentlichte Adresse, die unverknüpfbar bleiben soll. Es ist ein echter Fortschritt. Es ist zugleich ein Werkzeug fürs Empfangen mit einer Scan-Rechnung, und zu wissen, wer diese Rechnung zahlt — du oder ein Server, dem du vertraust —, ist der Unterschied zwischen Privatsphäre und dem bloßen Gefühl davon.

Häufige Fragen

#

Was ist eine Silent-Payment-Adresse?

#

Eine Silent-Payment-Adresse ist eine wiederverwendbare Bitcoin-Adresse nach BIP-352, die du einmal veröffentlichen kannst — auf dem Mainnet beginnt sie mit sp1. Anders als bei einer gewöhnlichen Adresse leitet jede zahlende Person daraus eine andere, einmalige On-Chain-Adresse ab, sodass die Zahlungen an dich kein gemeinsames, verknüpfbares Ziel tragen. Sie kodiert zwei öffentliche Schlüssel (einen scan key und einen spend key) statt eines einzelnen Skripts.

Verbergen Silent Payments den Betrag, den ich empfange?

#

Nein. Silent Payments schützen die Verbindung beim Empfangen — den Zusammenhang zwischen einzelnen Zahlungen an dieselbe Identität — und sonst nichts. Der Betrag jeder Zahlung steht weiterhin in der öffentlichen Blockchain, die Privatsphäre deiner Senderinnen bleibt unberührt, und Aufzeichnungen abseits der Chain (etwa bei einer KYC-Börse) bleiben unangetastet. Für die Privatsphäre der Beträge sind Lightning oder gemeinschaftliche Transaktionen die passenden Werkzeuge.

Welche Wallets unterstützen 2026 Silent Payments?

#

Mit Stand 2026-07-09 unterstützt Sparrow sowohl das Senden (seit v2.3.0, Oktober 2025) als auch das Empfangen (seit v2.5.0, Mai 2026); Cake Wallet unterstützt beides mit Scannen auf dem Gerät (seit v4.18.0, Ende Mai 2024). Die Wallet-Unterstützung von Bitcoin Core ist noch nicht gemergt, das zugrunde liegende kryptografische Modul dagegen schon. Prüfe die Unterstützung für Senden und Empfangen immer getrennt und gleiche sie mit den aktuellen Release Notes ab.

Warum ist der Empfang einer Silent Payment langsam?

#

Weil es keine Adresse auf der Chain gibt, die man nachschlagen könnte. Um die an dich gesendeten Zahlungen zu finden, muss deine Wallet infrage kommende Ausgaben über die Blöcke hinweg scannen und jede gegen deine Schlüssel prüfen. Auf dem eigenen Node ist das eine private lokale Berechnung; ohne Node verlässt du dich auf einen Indexing-Server, der schneller ist, aber einen Vertrauens-Kompromiss mit sich bringt. Light-Client-Werkzeuge, die sowohl die Kosten als auch das Vertrauen beseitigen, sind noch in Arbeit.

Sind Silent Payments noch privat, wenn ich einen öffentlichen Server nutze?

#

Nur teilweise. Um für dich zu scannen, bekommt ein öffentlicher Indexer deinen scan private key und deinen spend public key. Selbst wenn diese Schlüssel nur im Arbeitsspeicher liegen, kann ein bösartiger oder kompromittierter Server mit ihnen den vollständigen Verlauf der Zahlungen rekonstruieren, die du empfangen hast — genau das, was Silent Payments einer Beobachterin der Chain verwehren sollen. Ein eigener Node verhindert das; ein öffentlicher Server tauscht diese Privatsphäre gegen Bequemlichkeit.

Drei Fäden dieser Seite laufen hier zusammen. Silent Payments beantworten die Empfangs-Hälfte des Wiederverwendungs-Problems, das Bitcoin On-Chain-Privatsphäre: Wie das Tracing funktioniert seziert — dort steht, was die Bündelung sieht und was nicht. Weil die Adresse nur so privat ist wie die Coins, die du auf sie empfängst, lies dazu Bitcoin ohne KYC kaufen, das den Identitätsanker weiter oben festmacht. Und weil die Chain nie die ganze Bedrohung ist, behandelt KI-De-Anonymisierung die Inferenz abseits der Chain, die parallel zu alldem läuft.