Der Newsletter dieser Woche verweist auf eine lehrreiche Implementierung der elliptischen Kurven-Kryptografie für Bitcoins secp256k1-Kurve. Ebenfalls enthalten sind unsere regulären Abschnitte mit Beschreibungen von Diskussionen über Konsensänderungen, Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur-Software.

Nachrichten

  • ● Lehrreiche Implementierung für Versuchszwecke von secp256k1: Sebastian Falbesoner, Jonas Nick und Tim Ruffing haben in der Bitcoin-Dev-Mailingliste bekanntgegeben, dass eine Python-Implementierung verschiedener Funktionen im Zusammenhang mit der in Bitcoin verwendeten Kryptografie vorliegt. Dabei wird ausdrücklich darauf hingewiesen, dass die Implementierung “INSECURE” (im Original in Großbuchstaben) und “für Prototyping, Experimente und Bildungszwecke” gedacht ist.

    Zudem weisen sie darauf hin, dass Referenz- und Testcode für mehrere BIPs (340, 324, 327 und 352) bereits “benutzerdefinierte und teils leicht abweichende Implementierungen von secp256k1” enthält. Man erhofft sich, die Situation in Zukunft zu verbessern – eventuell beginnend mit einem kommenden BIP für ChillDKG (siehe Newsletter #312).

Konsensänderungen

Ein monatlicher Abschnitt, der Vorschläge und Diskussionen zu Änderungen der Bitcoin-Konsensregeln zusammenfasst.

  • ● Zahlreiche Diskussionen über den Diebstahl durch Quantencomputer und entsprechende Gegenmaßnahmen: In mehreren Gesprächen wurde erörtert, wie Bitcoin-Nutzer reagieren könnten, wenn Quantencomputer leistungsfähig genug wären, um Bitcoins zu stehlen.

    • ● Sollten gefährdete Bitcoins vernichtet werden? Jameson Lopp veröffentlicht in der Bitcoin-Dev-Mailingliste verschiedene Argumente, die dafür sprechen, Bitcoins, die durch Quantenangriffe gefährdet sind, nach einer hinreichenden Migrationsfrist zu vernichten. Zu seinen Argumenten zählen:

      • ● Argument der Präferenz der Allgemeinheit: Er geht davon aus, dass die Mehrheit es vorziehen würde, ihr Geld zu vernichten, statt es einem Angreifer mit schnellem Quantencomputer zu überlassen – zumal dieser zu den wenigen privilegierten Personen gehören würde, die frühzeitig Zugang zu Quantencomputern erhalten.

      • ● Argument des kollektiven Schadens: Viele der gestohlenen Bitcoins wären entweder dauerhaft verloren oder für den langfristigen Halter vorgesehen. Durch einen schnellen Gebrauch der gestohlenen Coins könnte die Kaufkraft der verbleibenden Bitcoins sinken, was unter anderem die Miner-Einnahmen reduziert und die Netzwerksicherheit beeinträchtigt.

      • ● Argument des minimalen Nutzens: Obwohl der Diebstahl zur Finanzierung der Entwicklung von Quantencomputern beitragen könnte, bietet er keinen direkten Nutzen für ehrliche Teilnehmer des Bitcoin-Protokolls.

      • ● Argument klarer Fristen: Niemand kann lange im Voraus wissen, wann ein Quantencomputer Bitcoins stehlen kann, aber ein spezifisches Datum, an dem gefährdete Coins vernichtet werden, kann präzise angekündigt werden. Diese klare Frist würde den Nutzern mehr Anreiz geben, ihre Bitcoins rechtzeitig zu sichern, wodurch insgesamt weniger Coins verloren gehen.

      • ● Argument der Miner-Anreize: Wie oben erwähnt, würde der Diebstahl durch Quantencomputer wahrscheinlich die Miner-Einnahmen reduzieren. Eine Mehrheit der Hashrate könnte die Ausgabe von gefährdeten Bitcoins zensieren, selbst wenn der Rest der Bitcoin-Nutzer eine andere Lösung bevorzugt.

      Lopp führt auch mehrere Argumente gegen die Vernichtung gefährdeter Bitcoins an, kommt jedoch zu dem Schluss, dass die Vernichtung vorzuziehen ist.

      Nagaev Boris fragt, ob UTXOs, die über die Migrationsfrist hinaus timelocked sind, ebenfalls vernichtet werden sollten. Lopp weist auf bestehende Fallstricke bei langen Timelocks hin und sagt, dass er persönlich “etwas nervös wird, wenn er Gelder für mehr als ein oder zwei Jahre sperrt.”

    • ● Sicherer Nachweis des UTXO-Besitzes durch Offenlegung eines SHA256-Preimages: Martin Habovštiak veröffentlicht in der Bitcoin-Dev-Mailingliste eine Idee, die es jemandem ermöglichen könnte, den Besitz eines UTXO nachzuweisen, selbst wenn ECDSA und Schnorr-Signaturen unsicher wären (z. B. nach der Existenz schneller Quantencomputer). Wenn das UTXO ein SHA256-Commitment (oder ein anderes quantensicheres Commitment) zu einem Preimage enthält, das nie zuvor offengelegt wurde, könnte ein mehrstufiges Protokoll zur Offenlegung dieses Preimages mit einer Konsensänderung kombiniert werden, um Quanten-Diebstahl zu verhindern. Dies ist im Wesentlichen dasselbe wie ein früherer Vorschlag von Tim Ruffing (siehe Newsletter #141), der allgemein als Guy Fawkes signature scheme bekannt ist. Es ist auch eine Variante eines Schemas, das Adam Back 2013 erfunden hat, um die Widerstandsfähigkeit gegen Miner-Zensur zu verbessern. Kurz gesagt, könnte das Protokoll wie folgt funktionieren:

      1. Alice erhält Gelder zu einem Output, der in irgendeiner Weise ein SHA256-Commitment macht. Dies kann ein direkt gehashter Output sein, wie P2PKH, P2SH, P2WPKH oder P2WSH – oder es kann ein P2TR-Output mit einem Skriptpfad sein.

      2. Wenn Alice mehrere Zahlungen an dasselbe Output-Skript erhält, muss sie entweder keine davon ausgeben, bis sie bereit ist, alle auszugeben (definitiv erforderlich für P2PKH und P2WPKH; wahrscheinlich auch praktisch erforderlich für P2SH und P2WSH), oder sie muss sehr vorsichtig sein, um sicherzustellen, dass mindestens ein Preimage von ihr nicht offengelegt wird (leicht möglich mit P2TR-Keypath gegenüber Scriptpath-Ausgaben).

      3. Wenn Alice bereit ist, auszugeben, erstellt sie privat ihre Ausgabetransaktion normal, sendet sie jedoch nicht. Sie erhält auch einige Bitcoins, die durch einen quantensicheren Signaturalgorithmus gesichert sind, damit sie Transaktionsgebühren zahlen kann.

      4. In einer Transaktion, die einige der quantensicheren Bitcoins ausgibt, verpflichtet sie sich zu den quantenunsicheren Bitcoins, die sie ausgeben möchte, und verpflichtet sich auch zu der privaten Ausgabetransaktion (ohne sie offenzulegen). Sie wartet darauf, dass diese Transaktion tief bestätigt wird.

      5. Nachdem sie sicher ist, dass ihre vorherige Transaktion praktisch nicht reorganisiert werden kann, offenbart sie ihr zuvor privates Preimage und die quantenunsichere Ausgabe.

      6. Knoten im Netzwerk durchsuchen die Blockchain, um die erste Transaktion zu finden, die sich zu dem Preimage verpflichtet. Wenn diese Transaktion sich zu Alices quantenunsicherer Ausgabe verpflichtet, führen sie ihre Ausgabe aus. Andernfalls tun sie nichts.

      Dies stellt sicher, dass Alice keine quantenanfälligen Informationen offenlegen muss, bis sie bereits sichergestellt hat, dass ihre Version der Ausgabetransaktion Vorrang vor jedem Versuch hat, von einem Quantencomputer-Betreiber ausgegeben zu werden. Für eine genauere Beschreibung des Protokolls siehe Ruffings Beitrag von 2018. Obwohl im Thread nicht diskutiert, glauben wir, dass das oben beschriebene Protokoll als Soft Fork bereitgestellt werden könnte.

      Habovštiak argumentiert, dass Bitcoins, die sicher mit diesem Protokoll ausgegeben werden können (z. B. deren Preimage noch nicht offengelegt wurde), nicht vernichtet werden sollten, selbst wenn die Community beschließt, dass sie quantenanfällige Bitcoins im Allgemeinen vernichten möchte. Er argumentiert auch, dass die Fähigkeit, einige Bitcoins im Notfall sicher auszugeben, die Dringlichkeit der Einführung eines quantensicheren Schemas kurzfristig verringert.

      Lloyd Fournier sagt, “wenn dieser Ansatz Akzeptanz findet, denke ich, dass die Hauptmaßnahme, die Benutzer ergreifen können, darin besteht, zu einer Taproot-Wallet zu wechseln”, da diese die Möglichkeit bietet, Keypath-Ausgaben unter den aktuellen Konsensregeln zu ermöglichen, einschließlich des Falles von Output linking, aber auch Widerstand gegen Quanten-Diebstahl, wenn Keypath-Ausgaben später deaktiviert werden.

      In einem separaten Thread (siehe nächster Punkt) stellt Pieter Wuille fest, dass UTXOs, die für Quanten-Diebstahl anfällig sind, auch Schlüssel umfassen, die nicht öffentlich verwendet wurden, aber mehreren Parteien bekannt sind, wie in verschiedenen Formen von Multisig (einschließlich LN, DLCs und Treuhanddiensten).

    • ● Entwurf eines BIP zur Vernichtung quantenunsicherer Bitcoins: Agustin Cruz veröffentlicht in der Bitcoin-Dev-Mailingliste ein Entwurf-BIP, das mehrere Optionen für einen allgemeinen Prozess zur Vernichtung von Bitcoins beschreibt, die für Quanten-Diebstahl anfällig sind (falls dies zu einem erwarteten Risiko wird). Cruz argumentiert, “indem wir eine Frist für die Migration durchsetzen, bieten wir rechtmäßigen Eigentümern eine klare, nicht verhandelbare Gelegenheit, ihre Gelder zu sichern […], eine erzwungene Migration mit ausreichender Vorankündigung und robusten Schutzmaßnahmen ist sowohl realistisch als auch notwendig, um die langfristige Sicherheit von Bitcoin zu schützen.”

      Sehr wenig der Diskussion im Thread konzentrierte sich auf das Entwurf-BIP. Die meisten Diskussionen drehten sich darum, ob die Vernichtung quantenanfälliger Bitcoins eine gute Idee ist, ähnlich wie der Thread, der später von Jameson Lopp gestartet wurde (wie im vorherigen Unterpunkt beschrieben).

  • ● Mehrere Diskussionen über ein CTV+CSFS-Softfork: Mehrere Gespräche untersuchten verschiedene Aspekte eines Softforks in den OP_CHECKTEMPLATEVERIFY (CTV) und OP_CHECKSIGFROMSTACK (CSFS) Opcodes.

    • ● Kritik an der CTV-Motivation: Anthony Towns postete eine Kritik an der in BIP119 beschriebenen Motivation für CTV, die, wie er argumentierte, durch die Hinzufügung von CTV und CSFS zu Bitcoin untergraben würde. Einige Tage nach Beginn der Diskussion wurde BIP119 von seinem Autor aktualisiert, um den umstrittenen Text zu entfernen; siehe Newsletter #347 für unsere Zusammenfassung der Änderung und die ältere Version von BIP119 für den Referenzwert. Einige der diskutierten Themen umfassten:

      • ● CTV+CSFS ermöglicht die Erstellung einer perpetuellen Covenant: CTVs Motivation sagte: “Covenants wurden aus historischer Sicht als nicht geeignet für Bitcoin angesehen, da sie zu komplex sind und das Risiko bergen, die Fungibilität der durch sie gebundenen Coins zu verringern. Dieses BIP führt eine einfache Covenant namens template ein, die eine begrenzte Anzahl hochwertiger Anwendungsfälle ermöglicht, ohne ein signifikantes Risiko einzugehen. BIP119-Vorlagen ermöglichen non-recursive vollständig aufgezählte Covenants ohne dynamischen Zustand” (Hervorhebung im Original).

        Towns beschreibt ein Skript, das sowohl CTV als auch CSFS verwendet, und verlinkt auf eine Transaktion, die es auf dem MutinyNet Signet verwendet, die nur durch das Senden des gleichen Betrags an das Skript selbst ausgegeben werden kann. Obwohl es einige Debatten über Definitionen gab, hat der Autor von CTV zuvor eine funktional identische Konstruktion als rekursive Covenant beschrieben, und Optech folgte dieser Konvention in seiner Zusammenfassung dieses Gesprächs (siehe Newsletter #190).

        Olaoluwa Osuntokun verteidigte CTVs Motivation in Bezug auf Skripte, die es verwenden, die “vollständig aufgezählt” und “ohne dynamischen Zustand” bleiben. Dies scheint einem Argument zu ähneln, das der Autor von CTV (Jeremy Rubin) 2022 gemacht hat, als er den Typ der pay-to-self-Covenant, den Towns entworfen hat, als “rekursiv, aber vollständig aufgezählt” bezeichnete. Towns entgegnete, dass die Hinzufügung von CSFS den angeblichen Vorteil der vollständigen Aufzählung untergräbt. Er bat um eine Aktualisierung der CTV- oder CSFS-BIPs, um Anwendungsfälle zu beschreiben, die “irgendwie sowohl beunruhigend sind als auch nach Kombination von CTV und CSFS nicht möglich bleiben”. Dies könnte in der jüngsten Aktualisierung von BIP119 geschehen sein, die einen “selbstreplizierenden Automaten (umgangssprachlich als SpookChains bezeichnet)” beschreibt, der mit SIGHASH_ANYPREVOUT möglich wäre, aber nicht mit CTV+CSFS.

      • ● Werkzeuge für CTV und CSFS: Towns notierte, dass er es schwierig fand, bestehende Werkzeuge zu verwenden, um sein rekursives Skript zu entwickeln, was auf einen Mangel an Einsatzbereitschaft für die Bereitstellung hinweist. Osuntokun sagte, dass die Werkzeuge, die er verwendet, “ziemlich einfach” seien. Weder Towns noch Osuntokun erwähnten, welche Werkzeuge sie verwendet haben. Nadav Ivgi stellte ein Beispiel mit seiner Minsc-Sprache vor und sagte, dass er daran arbeitet, Minsc zu verbessern, um solche Dinge einfacher zu machen. Es unterstützt Taproot, CTV, PSBT, Deskriptoren, Miniscript, pures Script, BIP32 und mehr. Allerdings gab er zu, dass vieles davon noch nicht dokumentiert ist.

      • ● Alternativen: Towns vergleicht CTV+CSFS mit seinem Basic Bitcoin Lisp Language (bll) und Simplicity, die eine alternative Skriptsprache bieten würden. Antoine Poinsot schlägt vor, dass eine alternative Sprache, die einfach zu verstehen ist, weniger riskant sein könnte als eine kleine Änderung des aktuellen Systems, die schwer zu verstehen ist. Der Entwickler Moonsettler argumentiert, dass die schrittweise Einführung neuer Funktionen in das Bitcoin-Script es sicherer macht, weitere Funktionen hinzuzufügen, da jede Erhöhung der Ausdrucksfähigkeit es weniger wahrscheinlich macht, dass wir auf eine Überraschung stoßen.

        Sowohl Osuntokun als auch James O’Beirne kritisierten die Bereitschaft von bll und Simplicity im Vergleich zu CTV und CSFS.

    • ● Vorteile von CTV+CSFS: Steven Roose postete auf Delving Bitcoin, um vorzuschlagen, CTV und CSFS zu Bitcoin hinzuzufügen, als ersten Schritt zu weiteren Änderungen, welche die Ausdrucksfähigkeit weiter erhöhen würden. Der Großteil der Diskussion konzentrierte sich auf die Qualifizierung der möglichen Vorteile von CTV, CSFS oder beider zusammen. Dies umfasste:

      • ● DLCs: Sowohl CTV als auch CSFS können einzeln die Anzahl der benötigten Signaturen reduzieren, um DLCs zu erstellen, insbesondere DLCs für das Unterzeichnen einer großen Anzahl von Varianten eines Vertrags (z. B. ein BTC-USD-Preisvertrag, der in Ein-Dollar-Schritten denominiert ist). Antoine Poinsot verlinkte auf eine kürzliche Ankündigung eines DLC-Service-Providers, der seinen Betrieb einstellte, als Beweis dafür, dass Bitcoin-Benutzer nicht sehr an DLCs interessiert sind, und verlinkte auf einen Beitrag von Jonas Nick vor einigen Monaten, der sagte: “DLCs haben auf Bitcoin keine bedeutende Akzeptanz erlangt, und ihre begrenzte Verwendung scheint nicht auf Leistungsbeschränkungen zurückzuführen zu sein. “ Antworten verlinkten auf andere noch funktionierende DLC-Service-Provider, einschließlich einem, der behauptet, 30 Millionen US-Dollar an Finanzierung beschafft zu haben.

      • ● Vaults: CTV vereinfacht die Implementierung von Vaults, die heute auf Bitcoin mithilfe von presigned Transaktionen und (optional) privater Schlüssellöschung möglich sind. Anthony Towns argumentiert, dass dieser Typ von Vault nicht sehr interessant ist. James O’Beirne widerspricht, dass CTV oder etwas Ähnliches eine Voraussetzung für die Erstellung von fortgeschritteneren Vault-Typen ist, wie z.B. seinen BIP345 OP_VAULT-Vaults.

      • ● Rechenschaftspflichtige Computing-Verträge: CSFS kann viele Schritte in rechenschaftspflichtigen Computing-Verträgen wie BitVM eliminieren, indem es die aktuelle Notwendigkeit ersetzt, Script-basierte Lamport-Signaturen auszuführen. CTV könnte in der Lage sein, einige zusätzliche Signaturoperationen zu reduzieren. Poinsot fragt wiederum, ob es eine signifikante Nachfrage nach BitVM gibt. Gregory Sanders antwortet, dass er es interessant finden würde, Token in beide Richtungen zu überbrücken, als Teil der geschützten Client-seitigen Validierung (siehe Newsletter #322). Allerdings bemerkt er auch, dass weder CTV noch CSFS das Vertrauensmodell von BitVM wesentlich verbessern, während andere Änderungen in der Lage sein könnten, das Vertrauen zu reduzieren oder die Anzahl der teuren Operationen auf andere Weise zu reduzieren.

      • ● Verbesserung im Liquid-Timelock-Skript: James O’Beirne leitete Kommentare von zwei Blockstream-Ingenieuren, dass CTV, in seinen Worten, “drastisch das [Blockstream] Liquid Timelock-Fallback-Skript verbessern würde, das eine periodische Verschiebung von Coins erfordert.” Nach Anfragen um Klarstellung erklärte der ehemalige Blockstream-Ingenieur Sanket Kanjalkar kanjalkar liquid, dass der Vorteil eine signifikante Einsparung an On-Chain-Transaktionsgebühren sein könnte. O’Beirne teilte auch weitere Details von Andrew Poelstra, dem Forschungsdirektor von Blockstream, mit.

      • ● LN-Symmetrie: CTV und CSFS können gemeinsam verwendet werden, um eine Form von LN-Symmetrie zu implementieren, die einige der Nachteile von LN-Penalty-Kanälen eliminiert, die derzeit in LN verwendet werden, und möglicherweise die Erstellung von Kanälen mit mehr als zwei Parteien ermöglicht, was die Liquiditätsverwaltung und die On-Chain-Effizienz verbessern könnte. Gregory Sanders, der eine experimentelle Version von LN-Symmetrie (siehe Newsletter #284) mithilfe von SIGHASH_ANYPREVOUT (APO) implementiert hat, bemerkt, dass die CTV+CSFS-Version von LN-Symmetrie nicht so funktionsreich ist wie die APO-Version und Kompromisse erfordert. Anthony Towns fügt hinzu, dass niemand bekannterweise Sanders’ experimentellen Code für APO aktualisiert hat, um ihn auf moderner Software zu verwenden und neu eingeführte Relay-Features wie TRUC und ephemeral Anchors zu nutzen, geschweige denn, dass jemand den Code auf CTV+CSFS portiert hat, was unsere Fähigkeit einschränkt, diese Kombination für LN-Symmetrie zu bewerten.

        Poinsot fragt, ob die Implementierung von LN-Symmetrie für LN-Entwickler eine Priorität wäre, wenn ein Soft Fork es ermöglichen würde. Zitate von zwei Core Lightning-Entwicklern (die auch Co-Autoren des Papiers sind, das wir jetzt LN-Symmetrie nennen), deuteten darauf hin, dass es für sie eine Priorität ist. Im Gegensatz dazu sagte Matt Corallo, der Leitende Entwickler von LDK, zuvor, “Ich finde [LN-Symmetrie] nicht besonders interessant in Bezug auf ‘wir müssen das erledigen’”.

      • ● Ark: Roose ist der CEO eines Unternehmens, das eine Ark-Implementierung entwickelt. Er sagt: “CTV ist ein Game-Changer für Ark […] die Vorteile von CTV für die Benutzererfahrung sind unbestreitbar, und es ist ohne Zweifel, dass beide [Ark]-Implementierungen CTV nutzen werden, sobald es verfügbar ist.” Towns bemerkte, dass niemand Ark mit entweder APO oder CTV für Tests implementiert hat; Roose schrieb kurz darauf Code dazu, nannte es “erstaunlich einfach”, und sagte, dass es die Integrationstests der bestehenden Implementierung bestanden hat. Er quantifizierte einige der Verbesserungen: Wenn sie zu CTV wechseln, “könnten wir etwa 900 Zeilen Code entfernen […] und unser eigenes Rundprotokoll auf zwei statt drei reduzieren, [plus] die Bandbreitenverbesserung, da wir keine Signier-Nonces und Teil-Signaturen mehr übertragen müssen.”

        Roose startete später einen separaten Thread, um die Vorteile von CTV für Ark-Benutzer zu diskutieren (siehe unsere Zusammenfassung unten).

    • ● Vorteile von CTV für Ark-Benutzer: Steven Roose postete auf Delving Bitcoin eine kurze Beschreibung des Ark-Protokolls, das derzeit auf Signet bereitgestellt wird und coventless Ark (clArk) genannt wird, und wie die Verfügbarkeit des OP_CHECKTEMPLATEVERIFY (CTV)-Opcodes eine Covenant-nutzende Version des Protokolls für Benutzer attraktiver machen könnte, wenn es schließlich auf Mainnet bereitgestellt wird.

      Ein Designziel für Ark ist es, asynchrone Zahlungen zu ermöglichen: Zahlungen, die vorgenommen werden, wenn der Empfänger offline ist. In clArk wird dies durch den Ausgeber und einen Ark-Server erreicht, der die bestehende Kette von presigned Transaktionen des Ausgebers erweitert, sodass der Empfänger letztendlich die exklusive Kontrolle über die Mittel übernehmen kann. Die Zahlung wird als Ark-out-of-round-Zahlung (arkoor) bezeichnet. Wenn der Empfänger online kommt, kann er wählen, was er tun möchte:

      • ● Ausstieg nach einer Verzögerung: Die gesamte Kette von presigned Transaktionen wird übertragen, um den Joinpool (genannt Ark) zu verlassen. Dies erfordert das Warten auf die Ablaufzeit eines Timelocks, der vom Ausgeber vereinbart wurde. Wenn die presigned Transaktionen zu einer angemessenen Tiefe bestätigt sind, kann der Empfänger sicher sein, dass er treuhänderische Kontrolle über die Mittel hat. Allerdings verliert er die Vorteile, die mit der Teilnahme an einem Joinpool verbunden sind, wie z.B. schnelle Abwicklung und geringere Gebühren durch UTXO-Teilung. Er muss möglicherweise auch Transaktionsgebühren zahlen, um die Kette von Transaktionen zu bestätigen.

      • ● Nichts: Im normalen Fall wird eine presigned Transaktion in der Kette von Transaktionen schließlich ablaufen und es dem Server ermöglichen, die Mittel zu beanspruchen. Dies ist kein Diebstahl - es ist ein erwarteter Teil des Protokolls - und der Server kann entscheiden, ob er einen Teil oder alle der beanspruchten Mittel an den Benutzer zurückgibt. Bis zum Ablauf kann der Empfänger einfach warten.

        Im pathologischen Fall können der Server und der Ausgeber jederzeit kolludieren, um eine alternative Kette von Transaktionen zu signieren und die Mittel zu stehlen, die an den Empfänger gesendet wurden. Beachten Sie: Die Privatsphäre-Eigenschaften von Bitcoin ermöglichen es sowohl dem Server als auch dem Ausgeber, dieselbe Person zu sein, sodass eine Kollusion möglicherweise nicht erforderlich ist. Wenn der Empfänger jedoch eine Kopie der Kette von Transaktionen aufbewahrt, die vom Server co-signiert wurde, kann er beweisen, dass der Server die Mittel gestohlen hat, was möglicherweise ausreicht, um andere Menschen davon abzuhalten, diesen Server zu verwenden.

      • ● Aktualisierung: Mit Hilfe des Servers kann der Empfänger atomar die Eigentumsrechte an den Mitteln in der vom Ausgeber co-signierten Transaktion auf eine andere presigned Transaktion mit dem Empfänger als Co-Signer übertragen. Dies verlängert das Ablaufdatum und eliminiert die Möglichkeit, dass der Server und der vorherige Ausgeber kolludieren, um die zuvor gesendeten Mittel zu stehlen. Allerdings erfordert die Aktualisierung, dass der Server die aktualisierten Mittel bis zum Ablaufdatum zurückhält, was die Liquidität des Servers reduziert. Deshalb verlangt der Server vom Empfänger einen Zinssatz bis zum Ablaufdatum (der im Voraus bezahlt wird, da das Ablaufdatum festgelegt ist).

      Ein weiteres Designziel für Ark ist es, es Teilnehmern zu ermöglichen, LN-Zahlungen zu empfangen. In seinem ursprünglichen Beitrag und einer Antwort beschreibt Roose, dass bestehende Teilnehmer, die bereits Mittel innerhalb des Joinpools haben, bis zu den Kosten einer On-Chain-Transaktion bestraft werden können, wenn sie die erforderliche Interaktivität für den Empfang einer LN-Zahlung nicht ausführen. Allerdings können diejenigen, die noch keine Mittel in dem Joinpool haben, nicht bestraft werden, sodass sie die interaktiven Schritte verweigern und kostenlos Probleme für ehrliche Teilnehmer verursachen können. Dies scheint effektiv zu verhindern, dass Ark-Benutzer LN-Zahlungen empfangen können, es sei denn, sie haben bereits eine moderate Menge an Mitteln auf dem Ark-Server, den sie verwenden möchten.

      Roose beschreibt dann, wie die Verfügbarkeit von CTV es ermöglichen würde, das Protokoll zu verbessern. Die wichtigste Änderung betrifft die Erstellung von Ark-Runden. Eine Ark-Runde besteht aus einer kleinen On-Chain-Transaktion, die sich auf einen Baum von Off-Chain-Transaktionen bezieht. Dies sind presigned Transaktionen im Falle von clArk, die erfordern, dass alle Ausgeber in dieser Runde für die Signierung verfügbar sind. Wenn CTV verfügbar wäre, könnte jede Zweigstelle im Baum von Transaktionen ihre Nachfolger mithilfe von CTV ohne Signierung verpflichten. Dies ermöglicht die Erstellung von Transaktionen sogar für Teilnehmer, die zum Zeitpunkt der Erstellung der Runde nicht verfügbar sind, mit folgenden Vorteilen:

      • ● In-Runde nicht-interaktive Zahlungen: Anstatt mit Ark-out-of-round (arkoor)-Zahlungen, kann ein Ausgeber, der bereit ist, auf die nächste Runde zu warten, den Empfänger in der Runde bezahlen. Für den Empfänger hat dies einen großen Vorteil: Sobald die Runde zu einer angemessenen Tiefe bestätigt ist, erhält er treuhänderische Kontrolle über die empfangenen Mittel (bis das Ablaufdatum näherkommt, zu dem Zeitpunkt kann er entweder aussteigen oder günstig aktualisieren). Anstatt auf mehrere Bestätigungen zu warten, kann der Empfänger wählen, sofort den Anreizen zu vertrauen, die durch das Ark-Protokoll für den Server geschaffen werden, um ehrlich zu operieren (siehe Newsletter #253). In einem separaten Punkt bemerkt Roose, dass diese nicht-interaktiven Zahlungen auch batched werden können, um mehrere Empfänger auf einmal zu bezahlen.

      • ● In-Runde-Akzeptanz von LN-Zahlungen: Ein Benutzer könnte anfordern, dass eine LN-Zahlung (HTLC) an einen Ark-Server gesendet wird, der Server würde dann die Zahlung halten, bis seine nächste Runde, und er würde CTV verwenden, um eine HTLC-gesperrte Zahlung an den Benutzer in die Runde aufzunehmen - nach dem der Benutzer den HTLC-Preimage bekanntgeben könnte, um die Zahlung zu erhalten. Allerdings bemerkte Roose, dass dies immer noch die Verwendung von “verschiedenen Missbrauchsschutzmaßnahmen” erfordern würde (wir glauben, dass dies aufgrund des Risikos ist, dass der Empfänger den Preimage nicht bekanntgibt, was dazu führt, dass die Mittel des Servers bis zum Ende der Ark-Runde gesperrt bleiben, was möglicherweise zwei oder mehr Monate dauern könnte).

        David Harding antwortete auf Roose und bat um weitere Details und verglich die Situation mit LN-JIT-Kanälen, die ein ähnliches Problem mit der Nicht-Offenlegung von HTLC-Preimages haben, das Probleme für Lightning-Service-Provider (LSPs) verursacht. LSPs lösen dieses Problem derzeit durch die Einführung von trust-basierten Mechanismen (siehe Newsletter #256). Wenn dieselben Lösungen für CTV-Ark geplant wären, würden diese Lösungen auch sicherstellen, dass die in-Runde-Akzeptanz von LN-Zahlungen in clArk möglich ist.

      • ● Weniger Runden, weniger Signaturen und weniger Speicher: clArk verwendet MuSig2, und jede Partei muss an mehreren Runden teilnehmen, mehrere teilweise Signaturen generieren und abgeschlossene Signaturen speichern. Mit CTV müsste weniger Daten generiert und gespeichert werden und weniger Interaktion wäre erforderlich.

  • ● OP_CHECKCONTRACTVERIFY-Semantik: Salvatore Ingala postete auf Delving Bitcoin, um die Semantik des vorgeschlagenen OP_CHECKCONTRACTVERIFY (CCV)-Opcodes zu beschreiben, und verlinkte zu einem ersten Entwurf eines BIP und einem Implementierungsentwurf für Bitcoin Core. Seine Beschreibung beginnt mit einer Übersicht über das Verhalten von CCV: Es ermöglicht die Überprüfung, ob ein öffentlicher Schlüssel sich auf eine beliebige Datenmenge bezieht. Es kann sowohl den öffentlichen Schlüssel der Taproot-Ausgabe, die ausgegeben wird, als auch den öffentlichen Schlüssel einer Taproot-Ausgabe, die erstellt wird, überprüfen. Dies kann verwendet werden, um sicherzustellen, dass Daten aus der ausgegebenen Ausgabe auf die erstellte Ausgabe übertragen werden. In Taproot kann eine Modifikation der Ausgabe sich auf Tapblätter wie Tapscripts beziehen. Wenn die Modifikation sich auf ein oder mehrere Tapscripts bezieht, legt sie eine encumbrance (Ausgabebedingung) auf die Ausgabe, die es ermöglicht, Bedingungen, die auf der ausgegebenen Ausgabe platziert wurden, auf die erstellte Ausgabe zu übertragen - allgemein (aber umstritten) als Covenant im Bitcoin-Jargon bezeichnet. Der Covenant kann die Erfüllung oder Modifikation der Belastung ermöglichen, was (jeweils) den Covenant beenden oder seine Bedingungen für zukünftige Iterationen modifizieren würde. Ingala beschreibt einige der Vorteile und Nachteile dieses Ansatzes:

    • ● Vorteile: native Unterstützung für Taproot, erhöht nicht die Größe von Taproot-Einträgen im UTXO-Set und Ausgabewege, die keine zusätzlichen Daten erfordern, müssen diese nicht in ihrem Witness-Stack enthalten (es gibt also keine zusätzlichen Kosten in diesem Fall).

    • ● Nachteile: funktioniert nur mit Taproot und die Überprüfung von Modifikationen erfordert elliptische Kurvenoperationen, die teurer sind als (zum Beispiel) SHA256-Operationen.

    Die Übertragung der Ausgabebedingungen von der ausgegebenen Ausgabe auf eine erstellte Ausgabe kann nützlich sein, aber viele Covenants werden sicherstellen wollen, dass einige oder alle Bitcoins in der ausgegebenen Ausgabe an die erstellte Ausgabe weitergegeben werden. Ingala beschreibt die drei Optionen von CCV für die Handhabung von Werten.

    • ● Ignorieren: Die Beträge werden nicht überprüft.

    • ● Abziehen: Der Betrag einer Ausgabe, die an einem bestimmten Index (z.B. der dritten Ausgabe) erstellt wird, wird vom Betrag der Ausgabe abgezogen, die an demselben Index ausgegeben wird, und der verbleibende Wert wird verfolgt. Zum Beispiel, wenn die Ausgabe, die an Index drei ausgegeben wird, 100 BTC wert ist und die Ausgabe, die an Index drei erstellt wird, 70 BTC wert ist, dann verfolgt der Code den verbleibenden Wert von 30 BTC. Die Transaktion wird als ungültig markiert, wenn die erstellte Ausgabe größer ist als die ausgegebene Ausgabe (da dies den verbleibenden Wert verringern würde, vielleicht sogar unter Null).

    • ● Standard: Die Transaktion wird als ungültig markiert, es sei denn, der Betrag der Ausgabe, die an einem bestimmten Index erstellt wird, ist größer als der Betrag der ausgegebenen Ausgabe plus die Summe aller vorherigen Residuen, die noch nicht mit einem default check verwendet wurden.

    Eine Transaktion ist gültig, wenn eine Ausgabe mehr als einmal mit deduct überprüft wird oder wenn sowohl deduct als auch default auf der gleichen Ausgabe verwendet werden.

    Ingala stellt mehrere visuelle Beispiele für Kombinationen der oben genannten Operationen bereit. Hier ist unsere textuelle Beschreibung seines Beispiels “Teilbetrag senden”, das möglicherweise für ein Vault nützlich sein könnte: Eine Transaktion hat eine Eingabe (die eine Ausgabe ausgibt) im Wert von 100 BTC und zwei Ausgaben, eine im Wert von 70 BTC und die andere im Wert von 30 BTC. CCV wird während der Transaktionsvalidierung zweimal ausgeführt:

    1. CCV mit deduct operiert auf Index 0 für 100 BTC, die ausgegeben werden, um 70 BTC zu erstellen, was einen Restbetrag von 30 BTC ergibt. In einem BIP345-Style-Vault würde CCV diese 70 BTC zurück an das gleiche Skript geben, durch das sie zuvor gesichert waren.

    2. Beim zweiten Mal wird default auf Index 1 verwendet. Obwohl es in dieser Transaktion eine Ausgabe gibt, die auf Index 1 erstellt wird, gibt es keine entsprechende Ausgabe, die auf Index 1 ausgegeben wird, so dass der implizite Betrag 0 verwendet wird. Zu diesem Nullbetrag wird der Restbetrag von 30 BTC aus dem deduct Aufruf auf Index 0 addiert, was bedeutet, dass die erstellte Ausgabe mindestens 30 BTC entsprechen muss. In einem BIP345-Style-Vault würde CCV das Ausgabeskript anpassen, um es zu ermöglichen, diesen Wert an eine beliebige Adresse auszugeben, nachdem ein Timelock abgelaufen ist, oder ihn jederzeit an die Haupt-Vault-Adresse des Benutzers zurückzugeben.

    Mehrere alternative Ansätze, die Ingala in Betracht gezogen und verworfen hat, werden sowohl in seinem Beitrag als auch in den Antworten diskutiert. Er schreibt: “Ich denke, die beiden Betragsverhaltensweisen (Standard und Abziehen) sind sehr ergonomisch und decken die überwiegende Mehrheit der wünschenswerten Betragsprüfungen in der Praxis ab.”

    Er bemerkt auch, dass er “vollständig ausgestattete Vault-Implementierungen mit OP_CCV plus OP_CTV erstellt hat, die ungefähr äquivalent sind zu […BIP345…]”. Darüber hinaus sei eine Version mit reduzierter Funktionalität, die nur OP_CCV verwendet, als Funktionstest in der Bitcoin Core-Implementierung von OP_CCV implementiert worden.

  • ● Entwurf für BIP veröffentlicht für Konsens-Reinigung: Antoine Poinsot postete auf der Bitcoin-Dev-Mailingliste einen Link zu einem Entwurf für ein BIP, den er für den Konsens-Reinigung-Vorschlag für ein Soft-Fork geschrieben hat. Er enthält mehrere Korrekturen:

    • ● Korrekturen für zwei verschiedene Time-Warp-Angriffe, die von einer Mehrheit der Rechenleistung verwendet werden könnten, um Blöcke mit beschleunigter Rate zu produzieren.

    • Eine Begrenzung für Signaturen-Operationen (Sigops) auf Legacy-Transaktionen, um die Erstellung von Blöcken zu verhindern, die sehr langsam zu validieren sind.

    • ● Eine Korrektur für die BIP34-Einzigartigkeit von Coinbase-Transaktionen, die doppelte Transaktionen vollständig verhindern sollte.

    • Ungültigmachung von zukünftigen 64-Byte-Transaktionen (berechnet mit der gestrippten Größe), um eine Art von Merkle-Baum-Schwachstelle zu verhindern.

    Technische Antworten waren für alle Teile des Vorschlags mit Ausnahme von zwei positiv. Der erste Einwand, der in mehreren Antworten geäußert wurde, war die Ungültigmachung von 64-Byte-Transaktionen. Die Antworten wiederholten vorherige Kritik (siehe Newsletter #319). Es gibt eine alternative Methode, um Merkle-Baum-Schwachstellen zu adressieren. Diese Methode ist relativ einfach für leichte (SPV) Wallets zu verwenden, aber könnte Herausforderungen für die SPV-Validierung in Smart Contracts, wie z.B. Bridges zwischen Bitcoin und anderen Systemen, darstellen. Sjors Provoost schlug vor, dass jemand, der eine on-chain-durchsetzbare Bridge implementiert, Code bereitstellt, der den Unterschied zwischen der Annahme, dass 64-Byte-Transaktionen nicht existieren, und der Verwendung der alternativen Methode zur Verhinderung von Merkle-Baum-Schwachstellen illustriert.

    Der zweite Einwand betraf eine späte Änderung an den Ideen, die in dem BIP enthalten sind, die in einem Beitrag auf Delving Bitcoin von Poinsot beschrieben wurde. Die Änderung erfordert, dass Blöcke, die nach der Aktivierung der Konsens-Reinigung erstellt werden, die Flagge setzen, der die Locktime ihrer Coinbase-Transaktion durchsetzbar macht. Wie zuvor vorgeschlagen, werden Coinbase-Transaktionen in Blöcken nach der Aktivierung ihre Locktime auf ihre Blockhöhe (minus 1) setzen. Diese Änderung bedeutet, dass kein Miner in der Lage ist, einen alternativen frühen Bitcoin-Block zu erstellen, der sowohl die Locktime nach der Aktivierung als auch die Durchsetzungsflagge verwendet (denn wenn sie es täten, wäre ihre Coinbase-Transaktion in dem Block, der sie enthält, aufgrund ihrer Verwendung einer weit in der Zukunft liegenden Locktime nicht gültig). Die Unfähigkeit, genau die gleichen Werte in einer vergangenen Coinbase-Transaktion zu verwenden, wie sie in einer zukünftigen Coinbase-Transaktion verwendet werden, verhindert die Schwachstelle von doppelten Transaktionen. Der Einwand gegen diesen Vorschlag war, dass es nicht klar war, ob alle Miner in der Lage sind, die Locktime-Durchsetzungsflagge zu setzen.

Veröffentlichungen und Release-Kandidaten

Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte ziehen Sie ein Upgrade auf neue Versionen in Betracht oder helfen Sie bei der Testung von Release-Kandidaten.

  • ● BDK wallet 1.2.0 fügt Flexibilität für Zahlungen an benutzerdefinierte Skripte hinzu, behebt einen Randfall im Zusammenhang mit Coinbase-Transaktionen und enthält mehrere weitere Funktionen und Fehlerbehebungen.

  • ● LDK v0.1.2 ist eine Veröffentlichung dieser Bibliothek für den Aufbau von LN-fähigen Anwendungen. Sie enthält mehrere Leistungsverbesserungen und Fehlerbehebungen.

  • ● Bitcoin Core 29.0rc3 ist ein Release-Kandidat für die nächste Hauptversion des vorherrschenden Full Nodes des Netzwerks. Bitte sehen Sie sich den Version 29 Testleitfaden an.

  • ● LND 0.19.0-beta.rc1 ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die wahrscheinlich getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen.

Wichtige Code- und Dokumentationsänderungen

Bedeutende kürzliche Ä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.

  • ● Bitcoin Core #31363 führt die TxGraph-Klasse ein (siehe Newsletter #341), ein leichtgewichtiges In-Memory-Modell von Mempool-Transaktionen, das nur Feerates und Abhängigkeiten zwischen Transaktionen verfolgt. Es enthält Mutationsfunktionen wie AddTransaction, RemoveTransaction und AddDependency sowie Inspektionsfunktionen wie GetAncestors, GetCluster und CountDistinctClusters. TxGraph unterstützt auch das Staging von Änderungen mit Commit- und Abbruch-Funktionalität. Dies ist Teil des Cluster-Mempool-Projekts und bereitet zukünftige Verbesserungen der Mempool-Eviction, der Reorganisationsbehandlung und der clusterbewussten Mining-Logik vor.

  • ● Bitcoin Core #31278 veraltet den settxfee-RPC-Befehl und die -paytxfee-Startoption, die es Benutzern ermöglichen, eine statische Gebühr für alle Transaktionen festzulegen. Benutzer sollten stattdessen auf Fee estimation zurückgreifen oder eine gebührenbasierte Transaktion festlegen. Sie sind für die Entfernung in Bitcoin Core 31.0 markiert.

  • ● Eclair #3050 aktualisiert, wie BOLT12-Zahlungsfehler weitergeleitet werden, wenn der Empfänger ein direkt verbundener Knoten ist, um immer die Fehlermeldung weiterzuleiten, anstatt sie mit einem nicht lesbaren invalidOnionBlinding-Fehler zu überschreiben. Wenn der Fehler ein channel_update enthält, überschreibt Eclair ihn mit TemporaryNodeFailure, um Details über unannounced channels zu vermeiden. Für blinded routes, die andere Knoten betreffen, überschreibt Eclair weiterhin Fehler mit invalidOnionBlinding. Alle Fehlermeldungen werden mit der blinded_node_id der Wallet verschlüsselt.

  • ● Eclair #2963 implementiert das One-Parent-One-Child (1p1c)-Package Relay, indem Bitcoin Cores submitpackage-RPC-Befehl während Kanalzwangsabschlüssen aufgerufen wird, um sowohl die Commitment-Transaktion als auch deren Anchor zusammen zu übertragen. Dies ermöglicht die Weiterleitung von Commitment-Transaktionen, auch wenn deren Feerate unter dem Mempool-Minimum liegt, erfordert jedoch die Verbindung zu Peers, die Bitcoin Core 28.0 oder höher ausführen. Diese Änderung entfernt die Notwendigkeit, die Feerate von Commitment-Transaktionen dynamisch festzulegen, und stellt sicher, dass Zwangsabschlüsse nicht stecken bleiben, wenn Knoten sich über die aktuelle Feerate uneinig sind.

  • ● Eclair #3045 macht das payment_secret-Feld im äußeren Onion-Payload optional für Single-Part-Trampoline payments. Zuvor enthielt jede Trampoline-Zahlung ein payment_secret, auch wenn keine Multipath payments (MPP) verwendet wurden. Da Zahlungsschlüssel möglicherweise erforderlich sind, wenn moderne BOLT11-Rechnungen verarbeitet werden, fügt Eclair einen Dummy ein, wenn keiner bereitgestellt wird.

  • ● LDK #3670 fügt Unterstützung für das Handling und den Empfang von Trampoline payments hinzu, implementiert jedoch noch keinen Trampoline-Routing-Service. Dies ist eine Voraussetzung für eine Art von Async payments, die LDK bereitstellen möchte.

  • ● LND #9620 fügt Testnet4-Unterstützung hinzu, indem die erforderlichen Parameter und Blockchain-Konstanten wie deren Genesis-Hash hinzugefügt werden.