🎙️ Bitcoin Optech Podcast-Nachlese #415
Im offiziellen Recap diskutieren Mark „Murch“ Erhardt, Gustavo Flores Echaiz und Mike Schmidt gemeinsam mit Fabian Jahr, Kruw und Mojo den Newsletter #415. Die Folge steht stark im Zeichen von Privatsphäre – von Signaturaggregation über CoinJoin und Coinswap bis zu Silent Payments.
🔎 Die wichtigsten Erkenntnisse aus der Diskussion
1. CISA: halbe Aggregation ist flexibel, volle Aggregation besonders kompakt
Fabian Jahr ordnet die drei zusammengehörigen Entwürfe ein: BIP458 beschreibt die nicht-interaktive Halbaggregation, BIP459 die interaktive vollständige Aggregation nach dem DahLIAS-Verfahren, und ein weiterer Entwurf soll Cross-Input Signature Aggregation (CISA) für Taproot-Keypath-Spends ermöglichen. Bei der Halbaggregation bleiben die einzelnen R-Werte erhalten, während die S-Werte zusammengeführt werden. Die vollständige Aggregation erzeugt dagegen unabhängig von der Zahl der Signierer nur eine 64-Byte-Signatur.
Der Preis dafür sind zwei Kommunikationsrunden: Zuerst tauschen die Beteiligten öffentliche Nonces aus, danach partielle Signaturen. Ein Koordinator vereinfacht die Kommunikation, muss aber nicht vertrauenswürdig sein und kann selbst einer der Signierer sein. Für interaktive Transaktionen wie CoinJoins und PayJoins wäre diese maximale Kompression besonders interessant. Die Halbaggregation bleibt nützlich, weil sie ohne zusätzliche Interaktion auch asynchron funktioniert.
Jahr beschränkt den CISA-Entwurf bewusst auf Taproot-Keypath-Spends. Bei Scriptpath-Spends kollidiert die Aggregation mit dem zukünftigen Upgrade-Pfad über OP_SUCCESS: Eine spätere Neudefinition könnte verändern, ob eine partielle Signatur in die Aggregation eingeht, und damit einen Hardfork erzeugen. Adaptor-Signaturen können außerdem ausdrücklich von der Aggregation ausgenommen werden. (1:32)
2. ASMap soll Eclipse-Angriffe erschweren – und braucht überprüfbare Daten
ASMap hilft Bitcoin Core, ausgehende Verbindungen nicht nur nach IP-Adressen, sondern nach autonomen Systemen zu verteilen. Ohne diese Sicht könnte ein Node scheinbar verschiedene Peers auswählen, die tatsächlich alle beim selben Hoster oder im selben Netz liegen. Ein vielfältigeres Peer-Set erschwert Eclipse-Angriffe.
Die Datengrundlage ist schwierig: Internet-Routing über BGP verändert sich ständig und ist ursprünglich nicht authentifiziert. Die ASMap-Erzeugung nutzt deshalb RPKI-Daten und koordinierte Läufe mehrerer Teilnehmer, die ihre Ergebnisse vergleichen. Selbst nahezu zeitgleiche Läufe können abweichen. Das Dashboard zeigt, wie die Karten altern, wie stark sich Zuordnungen ändern und wie gut sie beobachtete Bitcoin-Nodes abdecken. Mehr unabhängige, übereinstimmende Erzeuger verringern die nötige Vertrauensannahme. (21:06)
3. Wasabi entfernt einen zentralen Abhängigkeitspunkt und verbindet Zahlung mit CoinJoin
Wasabi 2.8.0 lädt kompakte Blockfilter nun direkt aus Bitcoins P2P-Netz statt von einem zentralen Backend. Nach dem Ende von ZK Snacks entfällt damit ein wichtiger einzelner Ausfallpunkt für Nutzer ohne eigenen Full Node.
Spannender als die reine Release-Notiz ist die Einordnung der neuen „Payments in CoinJoin“-Funktion: Eine Wallet kann Eingänge anonymisieren, die eigentliche Zahlung ausführen und das Wechselgeld innerhalb derselben gemeinschaftlichen Transaktion wieder mischen. Laut Kruw spart das gegenüber drei getrennten Schritten rund 55 Prozent Gebühren. Ganz kostenlos ist die Privatsphäre aber nicht: Die Zerlegung in mehrere, wiederkehrende Ausgangsbeträge erschwert die Zuordnung, vergrößert jedoch die Transaktion und erzeugt Coins, die später wieder zusammengeführt werden müssen.
Bis zu vier Zahlungen lassen sich direkt in einer CoinJoin-Runde ausführen; reguläres Batching ist in der Oberfläche ohne diese Begrenzung möglich. Wasabi nutzt für Eingänge P2WPKH oder Taproot-Keypath-Spends und erzeugt seit Version 2.8.1 standardmäßig Taproot-Empfangsadressen. Silent Payments können bereits gesendet werden; der Empfang ist noch in Arbeit und hängt auch vom weiteren Bitcoin-Core-Support ab. (33:11)
4. Coinswap tauscht Transaktionshistorien statt nur Ein- und Ausgänge zu vermischen
Mojo erklärt Coinswap anschaulich als Eigentumstausch zweier UTXO-Historien. Alice und Bob sperren Coins zunächst jeweils in einer 2-von-2-Konstruktion und tauschen anschließend Schlüsselmaterial aus. Für Außenstehende sehen die Funding-Transaktionen wie gewöhnliche Zahlungen aus, während die weitere Historie nicht mehr derselben Person folgt. Mehrere Teilnehmer können zu einer Kette verbunden werden, ohne dass ein einzelner Teilnehmer den gesamten Weg kennt.
Um Betragskorrelationen zu erschweren, zerlegt die Implementierung jede Seite zufällig in mindestens zwei Funding-Transaktionen. HTLC-ähnliche Hash- und Timelock-Pfade sorgen dafür, dass ein Abbruch nicht zum Verlust der Coins führt. Maker stellen Liquidität bereit, verdienen Gebühren und hinterlegen eine zeitgesperrte Fidelity Bond. Die Markterkennung kombiniert Hinweise auf Nostr-Relays mit auf der Bitcoin-Blockchain verankerten Bond-Daten, sodass kein einzelner DNS- oder Webserver den Markt kontrolliert.
Version 0.2.2 ergänzt unter anderem Deniability Proofs: Wer durch den Tausch eine problematische UTXO-Historie erhält, kann kryptografisch belegen, dass sie aus einem Swap stammt. Nach einem mit Spiral Loupe unterstützten Sicherheitsaudit wurden außerdem Schwachstellen behoben. Das Projekt versteht sich ausdrücklich als Protokoll und Bibliothek, nicht als dominierende Endnutzer-Wallet. Der aktuelle Schwerpunkt liegt noch auf Signet; Mainnet-Reife und eine BTCPay-Server-Integration sind als nächste Schritte vorgesehen. (46:08)
5. Wavelength verbindet eine Ark-ähnliche Abrechnungsschicht mit Lightning
Wavelength soll selbstverwahrte Zahlungen in Apps einbettbar machen, ohne dass jeder Nutzer eigene Lightning-Kanäle und Liquidität verwalten muss. BOLT11-Rechnungen werden unterstützt; interne Transfers werden über eine Ark-ähnliche, von einem Operator koordinierte Abrechnungsschicht gebündelt. Trotzdem behalten Nutzer einen unilateralen Ausstieg auf die Bitcoin-Blockchain.
In der Diskussion wird Wavelength als Rückkehr zu einer frühen Ark-Idee eingeordnet: Ein Lightning-Zugang kann auf mehrere Nutzer verteilt werden, während die interne Buchführung außerhalb einzelner Nutzerkanäle stattfindet. Perspektivisch könnten Taproot Assets außerdem den Wechsel zwischen Bitcoin und Dollar-Assets innerhalb dieses Modells erleichtern. Der aktuelle Stand ist jedoch ausdrücklich Alpha und nur für Signet und Testnet gedacht. (1:10:01)
6. Ein kleiner RBF-Bug kann zu einem deutlichen Privatsphäre-Leak werden
Core Lightning #8935 behebt einen Fehler bei ersetzten Transaktionen. CLN speicherte eine ausstehende Transaktion unter ihrer ursprünglichen TXID, aktualisierte bei einem Fee-Bump zwar die Transaktion selbst, nicht aber den Schlüssel. Dadurch konnte der Node selbst nach Bestätigung der Ersatztransaktion weiter neue Versionen erzeugen und verbreiten.
Murch hebt den Datenschutzaspekt hervor: Andere Nodes leiten eine bereits bestätigte Transaktion nicht weiter. Wer trotzdem fortlaufend neue Varianten derselben Zahlung ankündigt, verrät sich sehr deutlich als Urheber. Der Fall zeigt ein allgemeines Problem bei RBF: Wallets müssen bis zur Bestätigung alle konkurrierenden Transaktionsvarianten einer Zahlung verfolgen, weil trotz eines Fee-Bumps auch eine ältere Version bestätigt werden kann. (1:28:43)
7. Silent Payments erreichen eine wichtige Grundlage für breitere Wallet-Unterstützung
libsecp256k1 #1765 integriert nach rund zweieinhalb Jahren Arbeit und mehreren Anläufen ein optionales Silent-Payments-Modul. Es stellt die elliptischen-Kurven-Operationen aus BIP352 direkt in der in vielen Bitcoin-Projekten verwendeten Kryptobibliothek bereit. Sender können daraus die individuellen Output-Keys ableiten; Empfänger mit Full Node können Zahlungen erkennen und die nötigen Tweaks zum Ausgeben ermitteln, während der eigentliche Spend-Key offline bleiben kann.
Der praktische Vorteil von Silent Payments ist eine wiederverwendbare Zahlungsanweisung, die trotzdem für jede Zahlung ein neues Output-Script erzeugt. Das eignet sich etwa für öffentliche Spendenadressen, ohne die übliche Wiederverwendung einer Onchain-Adresse. Weil libsecp256k1 weit über Bitcoin Core hinaus genutzt wird, sinkt nun auch für andere Wallets und Bibliotheken die Hürde zur Integration. Leichtgewichtige Scan-Verfahren sind allerdings noch nicht Teil dieses Moduls. (1:35:16)
👥 Teilnehmer: Mark „Murch“ Erhardt, Gustavo Flores Echaiz, Mike Schmidt, Fabian Jahr, Kruw und Mojo
🎧 Podcast: https://bitcoinops.org/en/podcast/2026/07/28/
📰 Newsletter: https://bitcoinops.org/en/newsletters/2026/07/24/
Inoffizielle deutsche Zusammenfassung. Quelle: Bitcoin Optech, CC BY-SA 2.0. Audio lokal maschinell transkribiert; fachlich anhand der Shownotes und des Newsletters abgeglichen.
#Bitcoin #Optech #BitcoinDE
Im offiziellen Recap diskutieren Mark „Murch“ Erhardt, Gustavo Flores Echaiz und Mike Schmidt gemeinsam mit Fabian Jahr, Kruw und Mojo den Newsletter #415. Die Folge steht stark im Zeichen von Privatsphäre – von Signaturaggregation über CoinJoin und Coinswap bis zu Silent Payments.
🔎 Die wichtigsten Erkenntnisse aus der Diskussion
1. CISA: halbe Aggregation ist flexibel, volle Aggregation besonders kompakt
Fabian Jahr ordnet die drei zusammengehörigen Entwürfe ein: BIP458 beschreibt die nicht-interaktive Halbaggregation, BIP459 die interaktive vollständige Aggregation nach dem DahLIAS-Verfahren, und ein weiterer Entwurf soll Cross-Input Signature Aggregation (CISA) für Taproot-Keypath-Spends ermöglichen. Bei der Halbaggregation bleiben die einzelnen R-Werte erhalten, während die S-Werte zusammengeführt werden. Die vollständige Aggregation erzeugt dagegen unabhängig von der Zahl der Signierer nur eine 64-Byte-Signatur.
Der Preis dafür sind zwei Kommunikationsrunden: Zuerst tauschen die Beteiligten öffentliche Nonces aus, danach partielle Signaturen. Ein Koordinator vereinfacht die Kommunikation, muss aber nicht vertrauenswürdig sein und kann selbst einer der Signierer sein. Für interaktive Transaktionen wie CoinJoins und PayJoins wäre diese maximale Kompression besonders interessant. Die Halbaggregation bleibt nützlich, weil sie ohne zusätzliche Interaktion auch asynchron funktioniert.
Jahr beschränkt den CISA-Entwurf bewusst auf Taproot-Keypath-Spends. Bei Scriptpath-Spends kollidiert die Aggregation mit dem zukünftigen Upgrade-Pfad über OP_SUCCESS: Eine spätere Neudefinition könnte verändern, ob eine partielle Signatur in die Aggregation eingeht, und damit einen Hardfork erzeugen. Adaptor-Signaturen können außerdem ausdrücklich von der Aggregation ausgenommen werden. (1:32)
2. ASMap soll Eclipse-Angriffe erschweren – und braucht überprüfbare Daten
ASMap hilft Bitcoin Core, ausgehende Verbindungen nicht nur nach IP-Adressen, sondern nach autonomen Systemen zu verteilen. Ohne diese Sicht könnte ein Node scheinbar verschiedene Peers auswählen, die tatsächlich alle beim selben Hoster oder im selben Netz liegen. Ein vielfältigeres Peer-Set erschwert Eclipse-Angriffe.
Die Datengrundlage ist schwierig: Internet-Routing über BGP verändert sich ständig und ist ursprünglich nicht authentifiziert. Die ASMap-Erzeugung nutzt deshalb RPKI-Daten und koordinierte Läufe mehrerer Teilnehmer, die ihre Ergebnisse vergleichen. Selbst nahezu zeitgleiche Läufe können abweichen. Das Dashboard zeigt, wie die Karten altern, wie stark sich Zuordnungen ändern und wie gut sie beobachtete Bitcoin-Nodes abdecken. Mehr unabhängige, übereinstimmende Erzeuger verringern die nötige Vertrauensannahme. (21:06)
3. Wasabi entfernt einen zentralen Abhängigkeitspunkt und verbindet Zahlung mit CoinJoin
Wasabi 2.8.0 lädt kompakte Blockfilter nun direkt aus Bitcoins P2P-Netz statt von einem zentralen Backend. Nach dem Ende von ZK Snacks entfällt damit ein wichtiger einzelner Ausfallpunkt für Nutzer ohne eigenen Full Node.
Spannender als die reine Release-Notiz ist die Einordnung der neuen „Payments in CoinJoin“-Funktion: Eine Wallet kann Eingänge anonymisieren, die eigentliche Zahlung ausführen und das Wechselgeld innerhalb derselben gemeinschaftlichen Transaktion wieder mischen. Laut Kruw spart das gegenüber drei getrennten Schritten rund 55 Prozent Gebühren. Ganz kostenlos ist die Privatsphäre aber nicht: Die Zerlegung in mehrere, wiederkehrende Ausgangsbeträge erschwert die Zuordnung, vergrößert jedoch die Transaktion und erzeugt Coins, die später wieder zusammengeführt werden müssen.
Bis zu vier Zahlungen lassen sich direkt in einer CoinJoin-Runde ausführen; reguläres Batching ist in der Oberfläche ohne diese Begrenzung möglich. Wasabi nutzt für Eingänge P2WPKH oder Taproot-Keypath-Spends und erzeugt seit Version 2.8.1 standardmäßig Taproot-Empfangsadressen. Silent Payments können bereits gesendet werden; der Empfang ist noch in Arbeit und hängt auch vom weiteren Bitcoin-Core-Support ab. (33:11)
4. Coinswap tauscht Transaktionshistorien statt nur Ein- und Ausgänge zu vermischen
Mojo erklärt Coinswap anschaulich als Eigentumstausch zweier UTXO-Historien. Alice und Bob sperren Coins zunächst jeweils in einer 2-von-2-Konstruktion und tauschen anschließend Schlüsselmaterial aus. Für Außenstehende sehen die Funding-Transaktionen wie gewöhnliche Zahlungen aus, während die weitere Historie nicht mehr derselben Person folgt. Mehrere Teilnehmer können zu einer Kette verbunden werden, ohne dass ein einzelner Teilnehmer den gesamten Weg kennt.
Um Betragskorrelationen zu erschweren, zerlegt die Implementierung jede Seite zufällig in mindestens zwei Funding-Transaktionen. HTLC-ähnliche Hash- und Timelock-Pfade sorgen dafür, dass ein Abbruch nicht zum Verlust der Coins führt. Maker stellen Liquidität bereit, verdienen Gebühren und hinterlegen eine zeitgesperrte Fidelity Bond. Die Markterkennung kombiniert Hinweise auf Nostr-Relays mit auf der Bitcoin-Blockchain verankerten Bond-Daten, sodass kein einzelner DNS- oder Webserver den Markt kontrolliert.
Version 0.2.2 ergänzt unter anderem Deniability Proofs: Wer durch den Tausch eine problematische UTXO-Historie erhält, kann kryptografisch belegen, dass sie aus einem Swap stammt. Nach einem mit Spiral Loupe unterstützten Sicherheitsaudit wurden außerdem Schwachstellen behoben. Das Projekt versteht sich ausdrücklich als Protokoll und Bibliothek, nicht als dominierende Endnutzer-Wallet. Der aktuelle Schwerpunkt liegt noch auf Signet; Mainnet-Reife und eine BTCPay-Server-Integration sind als nächste Schritte vorgesehen. (46:08)
5. Wavelength verbindet eine Ark-ähnliche Abrechnungsschicht mit Lightning
Wavelength soll selbstverwahrte Zahlungen in Apps einbettbar machen, ohne dass jeder Nutzer eigene Lightning-Kanäle und Liquidität verwalten muss. BOLT11-Rechnungen werden unterstützt; interne Transfers werden über eine Ark-ähnliche, von einem Operator koordinierte Abrechnungsschicht gebündelt. Trotzdem behalten Nutzer einen unilateralen Ausstieg auf die Bitcoin-Blockchain.
In der Diskussion wird Wavelength als Rückkehr zu einer frühen Ark-Idee eingeordnet: Ein Lightning-Zugang kann auf mehrere Nutzer verteilt werden, während die interne Buchführung außerhalb einzelner Nutzerkanäle stattfindet. Perspektivisch könnten Taproot Assets außerdem den Wechsel zwischen Bitcoin und Dollar-Assets innerhalb dieses Modells erleichtern. Der aktuelle Stand ist jedoch ausdrücklich Alpha und nur für Signet und Testnet gedacht. (1:10:01)
6. Ein kleiner RBF-Bug kann zu einem deutlichen Privatsphäre-Leak werden
Core Lightning #8935 behebt einen Fehler bei ersetzten Transaktionen. CLN speicherte eine ausstehende Transaktion unter ihrer ursprünglichen TXID, aktualisierte bei einem Fee-Bump zwar die Transaktion selbst, nicht aber den Schlüssel. Dadurch konnte der Node selbst nach Bestätigung der Ersatztransaktion weiter neue Versionen erzeugen und verbreiten.
Murch hebt den Datenschutzaspekt hervor: Andere Nodes leiten eine bereits bestätigte Transaktion nicht weiter. Wer trotzdem fortlaufend neue Varianten derselben Zahlung ankündigt, verrät sich sehr deutlich als Urheber. Der Fall zeigt ein allgemeines Problem bei RBF: Wallets müssen bis zur Bestätigung alle konkurrierenden Transaktionsvarianten einer Zahlung verfolgen, weil trotz eines Fee-Bumps auch eine ältere Version bestätigt werden kann. (1:28:43)
7. Silent Payments erreichen eine wichtige Grundlage für breitere Wallet-Unterstützung
libsecp256k1 #1765 integriert nach rund zweieinhalb Jahren Arbeit und mehreren Anläufen ein optionales Silent-Payments-Modul. Es stellt die elliptischen-Kurven-Operationen aus BIP352 direkt in der in vielen Bitcoin-Projekten verwendeten Kryptobibliothek bereit. Sender können daraus die individuellen Output-Keys ableiten; Empfänger mit Full Node können Zahlungen erkennen und die nötigen Tweaks zum Ausgeben ermitteln, während der eigentliche Spend-Key offline bleiben kann.
Der praktische Vorteil von Silent Payments ist eine wiederverwendbare Zahlungsanweisung, die trotzdem für jede Zahlung ein neues Output-Script erzeugt. Das eignet sich etwa für öffentliche Spendenadressen, ohne die übliche Wiederverwendung einer Onchain-Adresse. Weil libsecp256k1 weit über Bitcoin Core hinaus genutzt wird, sinkt nun auch für andere Wallets und Bibliotheken die Hürde zur Integration. Leichtgewichtige Scan-Verfahren sind allerdings noch nicht Teil dieses Moduls. (1:35:16)
👥 Teilnehmer: Mark „Murch“ Erhardt, Gustavo Flores Echaiz, Mike Schmidt, Fabian Jahr, Kruw und Mojo
🎧 Podcast: https://bitcoinops.org/en/podcast/2026/07/28/
📰 Newsletter: https://bitcoinops.org/en/newsletters/2026/07/24/
Inoffizielle deutsche Zusammenfassung. Quelle: Bitcoin Optech, CC BY-SA 2.0. Audio lokal maschinell transkribiert; fachlich anhand der Shownotes und des Newsletters abgeglichen.
#Bitcoin #Optech #BitcoinDE
1