Der Newsletter dieser Woche beschreibt ein vorgeschlagenes BIP zur Erstellung signierter Nachrichten für nicht-legacy Adressen und fasst eine Diskussion über das nachweisliche Verbrennen kleiner Bitcoin-Beträge zum Schutz vor Denial-of- Service Attacken zusammen. Ebenfalls enthalten sind unsere regelmäßigen Abschnitte mit beliebten Fragen und Antworten aus dem Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release candidates sowie Zusammenfassungen erwähnenswerter Änderungen an beliebter Bitcoin Infrastruktursoftware.

News

  • ● Multiformat single-sig message signing: Bitcoin Core und viele andere Wallets unterstützen seit langem das Signieren und Verifizieren beliebiger Nachrichten, wenn der Schlüssel mit dem sie signiert wurden zu einer P2PKH-Adresse gehört. Für alle andere Adresstypen, einschließlich Adressen die single-sig P2SH-P2WPKH, native P2WPKH und P2TR-Ausgaben abdecken, unterstützt Bitcoin Core das Signieren oder Verifizieren von beliebigen Nachrichten nicht.

    Ein früherer Vorschlag, BIP322, zur Bereitstellung vollständig generischer Nachrichten Signierung, die mit jedem Skript funktionieren könnte, wurde noch nicht in Bitcoin Core integriert (bitcoin core #24058) oder zu anderen uns bekannten, populären Wallets hinzugefügt.

    Diese Woche schlug Ali Sherief vor, dass derselbe Signieralgorithmus der für P2WPKH verwendet wird, auch für andere Outputtypen verwendet werden könnte. Für die Verifizierung sollten Programme herleiten, wie der Schlüssel abzuleiten sei (falls erforderlich) und die Signatur anhand des Adresstyps verifizieren. Z.B. wenn eine bech32-Adresse mit einem 20-Byte Datenelement vorliegt, ist anzunehmen, dass es sich um eine P2WPKH-Ausgabe handelt.

    Der Entwickler Peter Gray merkte an, dass ColdCard Wallets bereits auf diese Weise Signaturen erstellen und der Entwickler Craig Raw entgegnete, dass das Sparrow Wallet in der Lage ist diese Signaturen zu validieren. Der Ansatz sei, zuerst den BIP137 Validierungsregeln zu folgen und erst dann dem Vorgehen von Electrum.

    Sherief plant ein BIP zu schreiben, welches das Verhalten spezifiziert.

  • ● Proof of micro-burn: mehrere Entwickler diskutierten Anwendungsfälle und Entwürfe von Onchain-Transaktionen, die bitcoins in kleinen Schritten zerstören (“burn” bitcoins) als Beweis des Ressourcenverbrauchs. Um ein Beispiel für einen Anwendungsfall von Ruben Somsen aus dem Thread zu erweitern, wäre die Idee es 100 Nutzern zu erlauben ihren E-Mails jeweils einen Beweis, dass $1 in bitcoins verbrannt wurden anzuhängen, was die Art von Anti-Spam-Schutz bieten würde der ursprünglich als Vorteil von hashcash vorgesehen war.

    Es wurden mehrere Lösungen mit Merkle-Bäumen diskutiert. Ein Teilnehmer meinte, dass die geringen Beträge um die es sich handelt nahelegen, dass Vertrauen (oder teilweises Vertrauen) der Beteiligten in eine zentrale Drittpartei eine vernünftige Lösung darstellen könnte, um unnötige Komplexität zu vermeiden.

Ausgewählte Q&A aus dem Bitcoin Stack Exchange

Bitcoin Stack Exchange ist eine der Plattformen auf denen Optech-Mitwirkende zuerst nach Antworten auf ihre Fragen suchen–oder wenn wir einige Augenblicke Zeit haben, anderen neugierigen oder verwirrten Nutzern aushelfen. In dieser monatlichen Rubrik stellen wir einige der populärsten Fragen und Antworten des letzten Monats vor.

Releases und Release candidates

Neue Releases und Release candidates für beliebte Bitcoin Infrastrukturprojekte. Bitte erwäge auf die neuen Versionen zu wechseln oder beim Testen von Release candidates auszuhelfen.

  • ● BTCPay Server 1.6.3 fügt neue Features, Verbesserungen und Bugfixes zu diesem populären, selbstgehosteten Zahlungsabwickler hinzu.

  • ● LDK 0.0.110 fügt mehrere neue Features für den Bau von LN-aktivierten Applikationen zur Bibliothek hinzu (viele davon in früheren Newslettern behandelt).

Nennenswerte Code- und Dokumentationsänderungen

Erwähnenswerte Änderungen diese Woche in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), und Lightning BOLTs.

  • ● Bitcoin Core #25351 stellt sicher, dass nach einem Import von Adressen, Schlüsseln oder Deskriptoren in ein Wallet der anschließende Re-scan nicht nur die Blockchain scannt, sondern auch prüft ob Transaktionen im Mempool für das Wallet relevant sind.

  • ● Core Lightning #5370 re-implementiert das commando Plugin und macht es zu einem Bestandteil von CLN. Commando erlaubt es einem Node, Befehle von autorisierten Peers über LN-Nachrichten zu empfangen. Peers werden autorisiert durch runes, einem selbsterstellten CLN-Protokoll, das auf einer vereinfachten Version von macaroons basiert. Obwohl Commando jetzt in CLN integriert ist, ist es nur funktionsfähig, wenn ein Benutzer Runen-Authentifizierungstoken erstellt. Weiter Informationen findest Du in den CLN-Handbuchseiten für commando und commando-rune.

  • ● BOLTs #1001 empfiehlt, dass Nodes, die eine Änderung ihrer Zahlungsweiterleitungsrichtlinien bekannt geben, noch für etwa 10 Minuten Zahlungen annehmen welche die alten Richtlinien erfüllen. Dadurch wird verhindert, dass Zahlungen fehlschlagen, wenn dem Absender die Aktualisierung der Richtlinien noch unbekannt war. Im Newsletter #169 findest Du ein Beispiel einer Implementierung, die eine solche Regel anwendet.