Der Newsletter dieser Woche fasst einen Vorschlag zur Verbesserung redundanter LN-Überzahlungen zusammen und verlinkt zu einer Diskussion über potenzielle Partitionierungsangriffe gegen Full Nodes. Außerdem enthalten sind unsere regelmäßigen Abschnitte, die aktuelle Änderungen an Diensten und Client-Software beschreiben, neue Releases und Release-Kandidaten ankündigen und bemerkenswerte Änderungen an beliebter Bitcoin-Infrastruktursoftware zusammenfassen.

Nachrichten

  • ● LSP-finanzierte redundante Überzahlungen: Entwickler ZmnSCPxj veröffentlichte auf Delving Bitcoin einen Vorschlag, LSPs die zusätzliche Finanzierung (Liquidität) bereitstellen zu lassen, die für redundante Überzahlungen erforderlich ist. In den ursprünglichen Vorschlägen für redundante Überzahlungen zahlt Alice an Zed, indem sie mehrere Zahlungen über mehrere Routen sendet, wobei nur Zed eine der Zahlungen beanspruchen kann; die restlichen Zahlungen werden an Alice zurückerstattet. Der Vorteil dieses Ansatzes ist, dass die ersten Zahlungsversuche Zed erreichen können, während andere Versuche noch durch das Netzwerk reisen, was die Geschwindigkeit von Zahlungen im LN erhöht.

    Nachteile dieses Ansatzes sind, dass Alice zusätzliches Kapital (Liquidität) für die redundanten Zahlungen haben muss, Alice online bleiben muss, bis die redundante Überzahlung abgeschlossen ist, und jede festsitzende Zahlung verhindert, dass Alice dieses Geld ausgeben kann, bis der Zahlungsversuch abläuft (bis zu zwei Wochen bei häufig verwendeten Einstellungen).

    ZmnSCPxjs Vorschlag ermöglicht es Alice, nur den tatsächlichen Zahlungsbetrag (plus Gebühren) zu zahlen, während ihre Lightning Service Provider (LSPs) die Liquidität für das Senden der redundanten Zahlungen bereitstellen, wodurch der Geschwindigkeitsvorteil redundanter Überzahlungen erreicht wird, ohne dass sie zusätzliche Liquidität kurzzeitig oder bis zum Timeout benötigt. Die LSPs können auch die Zahlung abschließen, während Alice offline ist, sodass die Zahlung auch bei schlechter Verbindung von Alice abgeschlossen werden kann.

    Nachteile des neuen Vorschlags sind, dass Alice etwas Privatsphäre gegenüber ihren LSPs verliert und dass der Vorschlag mehrere Änderungen am LN-Protokoll zusätzlich zur Unterstützung redundanter Überzahlungen erfordert.

  • ● Partitionierungs- und Eclipse-Angriffe durch BGP-Abfangen: Entwickler cedarctic schrieb auf Delving Bitcoin über die Nutzung von Schwächen im Border Gateway Protocol (BGP), um Full Nodes daran zu hindern, sich mit Peers zu verbinden, was zur Partitionierung des Netzwerks oder zur Ausführung von Eclipse-Angriffen verwendet werden kann. Mehrere Gegenmaßnahmen wurden von cedarctic beschrieben, wobei andere Entwickler in der Diskussion weitere Gegenmaßnahmen und Wege zur Überwachung der Angriffserkennung beschrieben.

Änderungen an Diensten und Client-Software

In diesem monatlichen Feature heben wir interessante Updates zu Bitcoin-Wallets und -Diensten hervor.

  • ● Zero-Knowledge-Proof-of-Reserve-Tool: Zkpoor generiert Proof of Reserves mit STARK-Beweisen, ohne die Adressen oder UTXOs des Besitzers preiszugeben.

  • ● Alternative Submarine-Swap-Protokoll-Proof-of-Concept: Der Papa Swap Protokoll-Proof-of-Concept erreicht Submarine-Swap-Funktionalität, indem er eine Transaktion anstatt zwei erfordert.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von Release-Kandidaten.

  • ● Bitcoin Core 30.0rc1 ist ein Release-Kandidat für die nächste Hauptversion dieser Full Verification Node Software.

  • ● BDK Chain 0.23.2 ist ein Release dieser Bibliothek zum Erstellen von Wallet-Anwendungen, das Verbesserungen beim Umgang mit Transaktionskonflikten einführt, die FilterIter-API neu gestaltet, um BIP158-Filterfähigkeiten zu verbessern, und das Anchor- und Block-Reorg-Management verbessert.

Wichtige Code- und Dokumentationsänderungen

Wichtige aktuelle Änderungen in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #33268 ändert, wie Transaktionen als Teil einer Benutzer-Wallet erkannt werden, indem die Anforderung entfernt wird, dass der Gesamtbetrag der Inputs einer Transaktion null Sats übersteigt. Solange eine Transaktion mindestens einen Output einer Wallet ausgibt, wird sie als Teil dieser Wallet erkannt. Dies ermöglicht es, Transaktionen mit null-wertigen Inputs, wie das Ausgeben eines P2A ephemeral Anchor, in der Transaktionsliste eines Benutzers zu erscheinen.

  • ● Eclair #3157 aktualisiert die Art, wie es Remote-Commitment-Transaktionen bei Wiederverbindung signiert und sendet. Anstatt das zuvor signierte Commitment erneut zu senden, signiert es mit den neuesten Nonces aus channel_reestablish neu. Peers, die keine deterministischen Nonces in Simple Taproot Channels verwenden, haben bei Wiederverbindung eine neue Nonce, wodurch die vorherige Commitment-Signatur ungültig wird.

  • ● LND #9975 fügt P2TR Fallback-On-Chain-Adress-Unterstützung zu BOLT11-Rechnungen hinzu, entsprechend dem in BOLTs #1276 hinzugefügten Test-Vektor. BOLT11-Rechnungen haben ein optionales f-Feld, das es Benutzern ermöglicht, eine Fallback-On-Chain-Adresse einzuschließen, falls eine Zahlung nicht über das LN abgeschlossen werden kann.

  • ● LND #9677 fügt die Felder ConfirmationsUntilActive und ConfirmationHeight zur PendingChannel-Response-Message hinzu, die vom PendingChannels-RPC-Befehl zurückgegeben wird. Diese Felder informieren Benutzer über die Anzahl der Bestätigungen, die für die Channel-Aktivierung erforderlich sind, und die Blockhöhe, bei der die Finanzierungstransaktion bestätigt wurde.

  • ● LDK #4045 implementiert den Empfang einer Async Payment durch einen LSP-Knoten, indem er ein eingehendes HTLC im Namen eines oft-offline Empfängers akzeptiert, es hält und später bei Signalisierung an den Empfänger weitergibt. Dieser PR führt ein experimentelles HtlcHold-Feature-Bit ein, fügt ein neues hold_htlc-Flag zu UpdateAddHtlc hinzu und definiert den Freigabepfad.

  • ● LDK #4049 implementiert die Weiterleitung von BOLT12-Rechnungsanfragen von einem LSP-Knoten an einen online Empfänger, der dann mit einer neuen Rechnung antwortet. Wenn der Empfänger offline ist, kann der LSP-Knoten mit einer Fallback-Rechnung antworten, wie durch die serverseitige Logik-Implementierung für Async Payments ermöglicht (siehe Newsletter #363).

  • ● BDK #1582 refaktoriert die Typen CheckPoint, LocalChain, ChangeSet und spk_client, um generisch zu sein und eine T-Payload zu akzeptieren, anstatt auf Block-Hashes fixiert zu sein. Dies bereitet bdk_electrum darauf vor, vollständige Block-Header in Checkpoints zu speichern, was Header-Redownloads vermeidet und gecachte Merkle-Beweise sowie Median Time Past (MTP) ermöglicht.

  • ● BDK #2000 fügt Block-Reorg-Behandlung zu einer refaktorierten FilterIter-Struktur hinzu (siehe Newsletter #339). Anstatt ihren Ablauf über mehrere Methoden zu verteilen, verknüpft dieser PR alles mit der next()-Funktion und vermeidet so Timing-Risiken. Ein Checkpoint wird bei jeder Blockhöhe ausgegeben, um sicherzustellen, dass der Block nicht veraltet ist und das BDK auf der gültigen Chain ist. FilterIter scannt alle Blöcke und holt diejenigen, die Transaktionen enthalten, die für eine Liste von Script-Pubkeys relevant sind, unter Verwendung von Compact Block Filters wie in BIP158 spezifiziert.

  • ● BDK #2028 fügt ein last_evicted-Timestamp-Feld zur TxNode-Struktur hinzu, um anzuzeigen, wann eine Transaktion aus dem Mempool ausgeschlossen wurde, nachdem sie durch RBF ersetzt wurde. Dieser PR entfernt auch die TxGraph::get_last_evicted-Methode (siehe Newsletter #346), da das neue Feld sie ersetzt.