Der Newsletter dieser Woche fasst einen Beitrag darüber zusammen, dass Full Nodes Transaktionen ignorieren sollen, die ohne vorherige Anforderung weitergeleitet werden. Außerdem enthalten sind unsere regelmäßigen Abschnitte mit beliebten Fragen und Antworten aus dem Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktursoftware.

News

  • ● Ignorieren unaufgeforderter Transaktionen: Antoine Riard postete auf Bitcoin-Dev zwei Entwürfe für BIPs, die es einem Node ermöglichen würden zu signalisieren, dass er keine tx-Nachrichten mehr akzeptiert, die nicht zuvor mit einer inv-Nachricht angefordert wurden, sogenannte unaufgeforderte Transaktionen. Riard hatte die allgemeine Idee bereits 2021 vorgeschlagen (siehe Newsletter #136). Das erste vorgeschlagene BIP enthält einen Mechanismus, der es Knoten erlaubt, ihre Möglichkeiten zur Weiterleitung von Transaktionsrouting und Präferenzen zu signalisieren. Das zweite vorgeschlagene BIP verwendet diesen Signalisierungsmechanismus, um anzuzeigen, dass der Node unaufgeforderte Transaktionen ignorieren wird.

    Es gibt mehrere kleine Vorteile des Vorschlags, wie in einem Bitcoin Core Pull Request diskutiert, aber es widerspricht dem Design einiger älterer Lightweight-Clients und könnte Benutzer dieser Software daran hindern, ihre Transaktionen zu senden, so dass eine sorgfältige Implementierung erforderlich sein könnte. Obwohl Riard den erwähnten Pull Request eröffnete, schloss er ihn später wieder, nachdem er angedeutet hatte, dass er an seiner eigenen Full Node Implementierung auf Basis von libbitcoinkernel arbeiten wolle. Er deutete auch an, dass der Vorschlag helfen würde, einige der Angriffe zu adressieren, die er kürzlich offengelegt hatte (siehe Newsletter #332).

Ausgewählte Fragen und Antworten aus dem Bitcoin Stack Exchange

Bitcoin Stack Exchange ist einer der ersten Orte, an denen Optech-Mitwirkende nach Antworten auf ihre Fragen suchen - oder wenn wir ein paar freie Momente haben, um neugierigen oder verwirrten Benutzern zu helfen. In diesem monatlichen Feature heben wir einige der am besten bewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepostet wurden.

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 bei der Testung von Release-Kandidaten.

Wichtiger Code- und Dokumentationsänderungen

Wichtiger 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 und BINANAs.

  • ● Core Lightning #8116 ändert die Handhabung unterbrochener Kanalabschlussverhandlungen, um den Prozess auch dann erneut zu versuchen, wenn dies nicht erforderlich ist. Dies behebt ein Problem, bei dem ein Node, dem die CLOSING_SIGNED-Nachricht seines Peers fehlt, beim erneuten Verbinden einen Fehler erhält und eine einseitige Abschluss-Transaktion sendet. In der Zwischenzeit hat der Peer, der sich bereits im Zustand CLOSINGD_COMPLETE befindet, die gegenseitige Abschluss-Transaktion gesendet, was potenziell zu einem Wettlauf zwischen den beiden Transaktionen führen kann. Diese Korrektur ermöglicht es, die Verhandlungen fortzusetzen, bis die gegenseitige Abschluss-Transaktion bestätigt ist.

  • ● Core Lightning #8095 fügt dem setconfig-Befehl ein transient-Flag hinzu (siehe Newsletter #257), das dynamische Konfigurationsvariablen einführt, die vorübergehend angewendet werden, ohne die Konfigurationsdatei zu ändern. Diese Änderungen werden beim Neustart zurückgesetzt.

  • ● Core Lightning #7772 fügt dem chanbackup-Plugin einen commitment_revocation-Hook hinzu, der die emergency.recover-Datei (siehe Newsletter #324) aktualisiert, wann immer ein neues Widerrufsgeheimnis empfangen wird. Dies ermöglicht es Benutzern, eine Straftransaktion zu senden, wenn sie Mittel mit emergency.recover abheben, falls der Peer einen veralteten widerrufenen Zustand veröffentlicht hat. Dieser PR erweitert das statische Kanal-Backup SCB-Format und aktualisiert das chanbackup-Plugin, um sowohl das neue als auch das alte Format zu serialisieren.

  • ● Core Lightning #8094 führt eine zur Laufzeit konfigurierbare xpay-slow-mode-Variable in das xpay-Plugin ein (siehe Newsletter #330), das die Rückgabe von Erfolg oder Misserfolg verzögert, bis alle Teile einer Multipath-Zahlung (MPP) aufgelöst sind. Ohne diese Einstellung könnte ein Fehlerstatus zurückgegeben werden, selbst wenn einige HTLCs noch ausstehen. Wenn ein Benutzer erneut versucht und die Rechnung von einem anderen Node erfolgreich bezahlt, könnte eine Überzahlung auftreten, wenn das ausstehende HTLC ebenfalls beglichen wird.

  • ● Eclair #2993 ermöglicht es dem Empfänger, die Gebühren für den geblendeten Teil eines Zahlungspfads zu übernehmen, während der Absender die Gebühren für den nicht geblendeten Teil übernimmt. Zuvor zahlte der Absender alle Gebühren, was es ihm ermöglichen könnte, den Pfad zu entschlüsseln und potenziell zu entblenden.

  • ● LND #9491 fügt Unterstützung für kooperative Kanalabschlüsse hinzu, wenn aktive HTLCs mit dem lncli closechannel-Befehl verwendet werden. Wenn dies initiiert wird, wird LND den Kanal anhalten, um die Erstellung neuer HTLCs zu verhindern, und warten, bis alle bestehenden HTLCs aufgelöst sind, bevor der Verhandlungsprozess beginnt. Benutzer müssen den Parameter no_wait festlegen, um dieses Verhalten zu aktivieren; andernfalls wird eine Fehlermeldung angezeigt, die sie auffordert, ihn anzugeben. Dieser PR stellt auch sicher, dass die Einstellung max_fee_rate für beide Parteien bei einem kooperativen Kanalabschluss durchgesetzt wird; zuvor wurde sie nur auf die entfernte Partei angewendet.