Bitcoin Optech Newsletter #429

Silent payments for multiparty wallets

Bitcoin Optech hebt ein von Oleksandr Kurbatov vorgestelltes Protokoll hervor, das Silent‑Payment‑Transaktionen aus Wallets ermöglicht, die Mehrparteien‑Signatur‑Schemata wie FROST und MuSig2 nutzen. Das Design lässt einen Koordinator gewichtete ECDH‑Shares von jedem Signierer sammeln und anschließend einen AggDLEQ‑Proof aggregieren, der BIP374 erfüllt. Da der Proof‑Austausch innerhalb des Koordinations‑Channels des Wallets bleibt, sind keine neuen PSBT‑Felder oder BIP‑Änderungen nötig. Kurbatov weist darauf hin, dass ein Papier mit formalen Sicherheitsbeweisen intern geprüft wird, aber die Kernbehauptung – dass korrupte Signierer und der Koordinator keinen Proof fälschen können – von einer Annahme abhängt, deren Härte noch offen ist.

Core Lightning denial‑of‑service vulnerability

Der Newsletter beschreibt zudem einen selbst‑referenziellen Channel‑Announcement‑Bug, entdeckt von Nishant Bansal, in Core‑Lightning (CLN) Versionen 25.02 bis 26.04. Die Software prüfte nicht, dass Node‑IDs in einem Channel‑Announcement eindeutig sind, sodass ein speziell präpariertes Announcement auf‑Disk gespeichert und bei jedem Neustart den Node zum Absturz brachte. Der Angriff erforderte nur ein finanziertes 2‑of‑2‑Output und minimale On‑Chain‑Gebühren. Der Bug wurde verantwortungsbewusst gemeldet, in CLN 26.04.1 gepatcht und in BOLT 7 via Anforderung #1333 übernommen. Betreiber, die noch vulnerable Releases nutzen, werden dringend zum schnellen Upgrade aufgefordert.

Updated Bitcoin Core security policy

Antoine Poinsot kündigte eine Änderung im Umgang von Bitcoin Core mit „leicht auffindbaren“ Bugs an – also solchen, die mit einfachen Prompt‑Anfragen an große Sprachmodelle oder einfachem Fuzzing entdeckt werden können. Anstatt bis zu einem großen Release zu warten, back‑portet das Projekt nun Fixes auf jeden gepflegten Branch, veröffentlicht schnell Point‑Releases und publiziert gleichzeitig Advisories. Die drei genannten Schwachstellen (Core #36665, #36667, #36669) wurden unter diesem neuen Regime behoben, wodurch das getaggte Release 32.0 übersprungen und stattdessen 32.1 veröffentlicht wurde, das zudem mempool‑basierte Gebühren‑Schätzung, PSBTv2‑Defaults und schnellere Block‑Validierung mitbringt.

Caveats and implications

Obwohl das Silent‑Payment‑Protokoll mit bestehenden Standards kompatibel zu sein scheint, beruht seine Sicherheit auf einer unbewiesenen Annahme, sodass Entwickler es als experimentell behandeln sollten, bis peer‑reviewte Beweise vorliegen. Der CLN‑Bug zeigt, wie subtile Protokoll‑Checks zu systemweiten Abstürzen führen können und unterstreicht die Wichtigkeit zeitnaher Upgrades. Die Policy‑Änderung von Bitcoin Core spiegelt den wachsenden Einfluss von KI‑unterstützter Code‑Analyse und die Notwendigkeit einer schnellen Reaktion auf gering‑schwere, aber breit ausnutzbare Probleme wider.

What readers should do

Wallet‑Entwickler sollten das AggDLEQ‑Verfahren in Testumgebungen ausprobieren, aber die kommenden Sicherheits‑Audits abwarten, bevor sie es produktiv einsetzen. Node‑Operatoren sollten prüfen, dass sie CLN ≥ 26.04.1 und Bitcoin Core ≥ 32.1 laufen lassen und die empfohlenen Point‑Releases für ältere Branches anwenden. Auf dem neuesten Stand zu bleiben reduziert das Risiko sowohl neuartiger Protokoll‑Angriffe als auch der wachsenden Klasse leicht auffindbarer Bugs.