Neue Implementierung für den Bitcoin-Mixing-Service CoinJoin verbessert den Sybil-Widerstand

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining


Besuchen Sie den Originalartikel*

http://bitcoinmagazine.com/.image/c_limit,cs_srgb,fl_progressive,h_1200,q_auto:good,w_1200/MTc5Mjk3ODExODQ1MzU5Mjk5/knapsack-and-unequal-coinjoin-transaction-amounts.jpg

Der Bitcoin Optech-Newsletter dieser Woche beschreibt eine Verbesserung der JoinMarket-Implementierung für das CoinJoin-Bitcoin-Mischen und mehr.

Der Bitcoin Optech-Newsletter bietet den Lesern eine Zusammenfassung der wichtigsten technischen Neuigkeiten rund um Bitcoin sowie Ressourcen, die ihnen helfen, mehr zu erfahren. Um unseren Lesern zu helfen, über Bitcoin auf dem Laufenden zu bleiben, veröffentlichen wir unten die neueste Ausgabe dieses Newsletters. Denken Sie daran, sich zu abonnieren, um diesen Inhalt direkt in Ihren Posteingang zu erhalten.

Der Newsletter dieser Woche knüpft an eine frühere Beschreibung zu Treueanleihen in JoinMarket an und enthält unsere regulären Abschnitte mit der Zusammenfassung eines Bitcoin Core PR Review Club-Meetings, Vorschlägen zur Vorbereitung auf taproot, Ankündigungen von Releases und Release-Kandidaten sowie Beschreibungen bemerkenswerter Änderungen an beliebte Infrastrukturprojekte.

Nachrichten

  • Implementierung von Treueanleihen: Die JoinMarket 0.9.0-Implementierung von Coinjoin umfasst Unterstützung für Treueanleihen. Wie bereits im Newsletter #57 beschrieben, verbessern die Anleihen die Sybil-Resistenz des JoinMarket-Systems und erhöhen die Möglichkeit für Coinjoin-Initiatoren („Taker“), einzigartige Liquiditätsanbieter („Macher“) auszuwählen. Innerhalb weniger Tage nach der Veröffentlichung wurden über 50 BTC (derzeit mit einem Wert von über 2 Millionen US-Dollar) in zeitgebundenen Treueanleihen platziert.
    Obwohl die spezifische Implementierung für JoinMarket einzigartig ist, kann das Gesamtdesign in anderen dezentralen Protokollen, die auf Bitcoin aufbauen, nützlich sein.

Bitcoin Core PR Review Club

In diesem monatlichen Abschnitt fassen wir eine aktuelle Bitcoin Core PR Review Club treffen und einige der wichtigen Fragen und Antworten hervorheben. Klicken Sie unten auf eine Frage, um eine Zusammenfassung der Antwort aus dem Meeting anzuzeigen.

Verwenden Sie lieber txindex, wenn für GetTransaction verfügbar ist eine PR von Jameson Lopp, die die Leistung von GetTransaction (und damit auch des getrawtransaction RPC für Benutzer) verbessert, indem nach Möglichkeit der Transaktionsindex (txindex) verwendet wird. Diese Änderung behebt einen unerwarteten Leistungsverlust, bei dem ein Aufruf von getrawtransaction auf einem txindex-aktivierten Knoten erheblich langsamer ist, wenn er mit dem Hash des Blocks aufgerufen wird, der die Transaktion enthält. Der Bewertungsclub bewertete die Ursache dieses Leistungsproblems, indem er die Schritte zum Abrufen einer Transaktion mit und ohne txindex verglich.

  • Wie kann GetTransaction eine Transaktion vom Datenträger abrufen?
    Die Transaktion kann aus dem Mempool abgerufen werden (falls unbestätigt), indem der gesamte Block von der Festplatte abgerufen und nach der Transaktion gesucht wird, oder indem txindex verwendet wird, um die Transaktion selbst von der Festplatte abzurufen.
  • Warum ist Ihrer Meinung nach die Leistung schlechter, wenn der Block-Hash bereitgestellt wird (wenn txindex aktiviert ist)?
    Die Teilnehmer vermuteten, dass der Engpass in der Deserialisierung des Blocks lag. Ein weiterer einzigartiger Prozess für das Abrufen des gesamten Blocks – wenn auch weniger zeitaufwändig – ist eine lineare Suche durch die gesamte Liste der Transaktionen.
  • Wenn wir die Transaktion nach Block-Hash suchen, was sind die Schritte? Wie viele Daten werden deserialisiert?
    Wir verwenden zunächst den Blockindex, um die Datei und den Byte-Offset zu finden, die für den Zugriff auf den Block erforderlich sind. Wir holen und deserialisieren dann den gesamten Block und scannen die Liste der Transaktionen, bis wir eine Übereinstimmung finden. Dabei werden etwa 1-2 MB Daten deserialisiert.
  • Wenn wir die Transaktion mit dem txindex nachschlagen, was sind die Schritte? Wie viele Daten werden deserialisiert?
    Der txindex bildet von der Transaktions-ID auf die Datei, die Blockposition (ähnlich dem Blockindex) und den Offset innerhalb der blk*.dat-Datei ab, an der die Transaktion beginnt. Wir holen und deserialisieren den Blockheader und die Transaktion. Der Header ist 80B und ermöglicht es uns, den Block-Hash an den Benutzer zurückzugeben (das sind Informationen, die nicht im txindex gespeichert sind). Die Transaktion kann jede Größe haben, ist aber normalerweise tausendmal kleiner als der Block.
  • Die erste Version dieses PR beinhaltete eine Verhaltensänderung: Wenn GetTransaction ein falscher block_index bereitgestellt wird, suchen und geben Sie den tx trotzdem mithilfe des txindex zurück. Glauben Sie, dass diese Änderung eine Verbesserung darstellt und in diese PR aufgenommen werden sollte?
    Die Teilnehmer waren sich einig, dass dies hilfreich, aber irreführend sein könnte und dass es besser wäre, den Benutzer über die falsche Block-Hash-Eingabe zu informieren. Sie stellten auch fest, dass eine Leistungsverbesserung und Verhaltensänderung am besten in separate PRs aufgeteilt werden würden.

Vorbereitung auf Taproot #8: Multisignature Nonces

Eine wöchentliche Serie darüber, wie sich Entwickler und Service Provider auf die bevorstehende Aktivierung von taproot auf Blockhöhe 709.632 vorbereiten können.

In der Kolumne der letzten Woche haben wir über Multisignaturen geschrieben und ein Beispiel mit MuSig2 gegeben. Unsere Beschreibung scheint technisch korrekt gewesen zu sein, aber mehrere Kryptografen, die zu MuSig2 beigetragen haben, befürchteten, dass die von uns vorgeschlagene Verwendung gefährlich war. Wir haben unsere Beschreibung aktualisiert, um ihre unmittelbaren Bedenken auszuräumen, und haben dann damit begonnen, das Problem gründlicher zu untersuchen. In diesem Beitrag sehen wir uns an, was wir gelernt haben, die möglicherweise die größte Herausforderung für die sichere Implementierung von Multisignaturen darstellt: die Vermeidung von wiederholter Wiederverwendung.

Um eine Signatur in Bitcoin zu validieren, füllen Sie eine öffentlich bekannte Gleichung mit der Signatur, der signierten Nachricht (z. B. einer Transaktion), Ihrem öffentlichen Schlüssel und einer öffentlichen Nonce aus. Sie können diese Gleichung nur ausgleichen, wenn Sie Ihren privaten Schlüssel und die private Form der Nonce kennen. Somit hält jeder, der eine solche ausgewogene Gleichung sieht, die Signatur für diese Nachricht und den öffentlichen Schlüssel für gültig.

Die Motivation, die Signatur und die Nachricht in die Gleichung aufzunehmen, liegt auf der Hand. Der öffentliche Schlüssel ist ein Ersatz für Ihren privaten Schlüssel. Wozu dient die öffentliche Nonce? Wenn es nicht da wäre, wäre jeder andere Wert in der Gleichung außer Ihrem privaten Schlüssel bekannt, was bedeutet, dass wir die grundlegende Algebra verwenden könnten, um nach diesem einzigen unbekannten Wert aufzulösen. Aber die Algebra kann nicht nach zwei unbekannten Werten auflösen, daher dient die private Form der Nonce dazu, Ihren privaten Schlüssel geheim zu halten. Und genauso wie Ihr öffentlicher Schlüssel ein Ersatz für Ihren privaten Schlüssel in der Signaturgleichung ist, steht die öffentliche Form der Nonce für ihre private Form.

Nonces in diesem Zusammenhang sind nicht nur Zahlen einmal verwendet aber Zahlen, die immer nur einmal verwendet werden dürfen. Wenn Sie dieselbe Nonce mit zwei verschiedenen Signaturen wiederverwenden, können die beiden Signaturgleichungen kombiniert werden, die Nonce kann aufgehoben werden und jemand kann wieder nach dem einzigen verbleibenden unbekannten Wert auflösen – Ihrem privaten Schlüssel. Wenn Sie die BIP32-Standardableitung (nicht gehärtete Ableitung) verwenden, was wahrscheinlich fast alle Multisignatur-Wallets tun, bedeutet die Offenlegung eines privaten Schlüssels die Offenlegung jedes anderen privaten Schlüssels im selben BIP32-Pfad (und möglicherweise auch in anderen Pfaden) ). Das bedeutet, dass bei einer Multisignatur-Wallet, die Bitcoins an hundert verschiedene Adressen erhalten hat, jede dieser Adressen für den Unterzeichner kompromittiert wird, der auch nur eine einzige Nonce wiederverwendet.

Single-Sig-Wallets oder solche, die skriptbasiertes Multisig verwenden, können einen einfachen Trick anwenden, um die Wiederverwendung von Nonces zu vermeiden: Sie machen ihre Nonce abhängig von der Nachricht, die sie signieren. Wenn sich die Nachricht ändert, ändert sich die Nonce, und sie verwenden eine Nonce nie wieder.

Multisignaturen können diesen Trick nicht verwenden. Sie verlangen, dass jeder Mitunterzeichner nicht nur eine Teilunterschrift, sondern auch eine teilweise öffentliche Nonce beisteuert. Die partiellen öffentlichen Nonces werden miteinander kombiniert, um eine aggregierte öffentliche Nonce zu erzeugen, die in der zu signierenden Nachricht enthalten ist.

Das bedeutet, dass es nicht sicher ist, dieselbe partielle Nonce mehr als einmal zu verwenden, selbst wenn die Transaktion gleich bleibt. Wenn beim zweiten Unterzeichnen einer Ihrer Mitunterzeichner seine Teil-Nonce geändert hat (die aggregierte Nonce ändert), wird Ihre zweite Teilsignatur effektiv für eine andere Nachricht verwendet. Das enthüllt Ihren privaten Schlüssel. Da es für jede Partei unmöglich zirkulär ist, ihre private Nonce von allen partiellen öffentlichen Nonces der anderen Partei abhängig zu machen, gibt es keinen einfachen Trick, um die Wiederverwendung von Nonce in Mehrfachsignaturen zu vermeiden.

Auf den ersten Blick scheint dies kein großes Problem zu sein. Lassen Sie die Unterzeichner einfach jedes Mal, wenn sie etwas unterschreiben müssen, eine neue zufällige Nonce generieren. Dies ist schwieriger zu korrigieren, als es sich anhört – seit mindestens 2012 finden die Leute Bitcoin-Verlust-Bugs in Wallets, die davon abhingen, zufällige Nonces zu generieren.

Aber selbst wenn eine Wallet qualitativ hochwertige zufällige Nonces generiert, muss sie sicherstellen, dass jede Nonce nur maximal einmal verwendet wird. Das kann eine echte Herausforderung sein. In der Originalversion unserer Kolumne letzte Woche haben wir ein MuSig2-kompatibles Cold Wallet oder Hardware-Signiergerät beschrieben, das beim ersten Durchlauf eine große Anzahl von Nonces erstellen würde. Die Brieftasche oder das Gerät müsste dann sicherstellen, dass jede dieser Nonces nie mit mehr als einer Teilsignatur verwendet wurde. Obwohl das einfach klingt – erhöhen Sie einfach jedes Mal einen Zähler, wenn eine Nonce verwendet wird – es kann eine echte Herausforderung sein, wenn man sich mit all den Möglichkeiten befasst, wie Software und Hardware versehentlich ausfallen können, ganz zu schweigen davon, wie sie durch externe und möglicherweise böswillige Eingriffe beeinträchtigt werden können .

Der vielleicht einfachste Weg für ein Wallet, das Risiko der Wiederverwendung von Nonces zu reduzieren, besteht darin, Nonces für so kurze Zeit wie möglich aufzubewahren. Unser Beispiel von letzter Woche schlug vor, Nonces über Monate oder Jahre zu speichern, was nicht nur viele Möglichkeiten für Fehler bietet, sondern auch die Aufzeichnung von Nonces auf einem persistenten Speichermedium erfordert, das gesichert und wiederhergestellt oder auf andere Weise in einen unerwarteten Zustand versetzt werden kann . Eine alternative Möglichkeit, MuSig2 zu verwenden, besteht darin, Nonces nur bei Bedarf zu erstellen, z. B. wenn ein PSBT empfangen wird. Die Nonces konnten für die kurze Zeit, in der sie benötigt wurden, im flüchtigen Speicher gehalten und so in mehreren Fällen unerwarteter Ereignisse, wie z. B. einem Softwareabsturz oder einem Stromausfall, automatisch zerstört (unbrauchbar gemacht) werden.

Dennoch scheinen die Kryptografen, die an diesem Problem arbeiten, sehr besorgt über das Fehlen einer narrensicheren Möglichkeit, die Wiederverwendung in den ursprünglichen MuSig-Protokollen (MuSig1) und MuSig2 zu verhindern. MuSig-DN (deterministische Nonce) bietet zwar eine Lösung, aber sie ist komplex und langsam (eine Alpha-Implementierung dauert fast eine Sekunde, um einen Nonce-Proof auf einem 2,9 GHz Intel i7 zu erstellen; es ist uns nicht bekannt, wie lange das auf einem 16 MHz dauern könnte Hardware-Signaturgerät mit einem viel weniger ausgereiften Prozessor).

Unser Rat an alle, die Multisignatur-Signaturen implementieren, ist, in Erwägung zu ziehen, im IRC-Raum #secp256k1 oder an einem anderen Ort vorbeizuschauen, an dem sich Bitcoin-Kryptographen versammeln und Ihre Pläne beschreiben, bevor Sie größere Zeit- oder Ressourceninvestitionen tätigen.

Releases und Release-Kandidaten

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

  • C-Lightning 0.10.1 ist eine Version, die eine Reihe neuer Funktionen, mehrere Fehlerbehebungen und einige Aktualisierungen der Entwicklungsprotokolle (einschließlich dualer Finanzierung und Angebote) enthält.
  • Bitcoin Core 22.0rc2 ist ein Release-Kandidat für die nächste Hauptversion dieser vollständigen Node-Implementierung und der dazugehörigen Wallet und anderer Software. Zu den wichtigsten Änderungen in dieser neuen Version gehören die Unterstützung für I2P-Verbindungen, die Entfernung der Unterstützung für Version 2 Tor-Verbindungen und die verbesserte Unterstützung für Hardware-Wallets.

Bemerkenswerte Code- und Dokumentationsänderungen

Bemerkenswerte Änderungen diese Woche in Bitcoin-Kern, C-Blitz, Eclair, LND, Rost-Blitz, libsecp256k1, Hardware-Wallet-Schnittstelle (HWI), Rost Bitcoin, BTCPay-Server, Verbesserungsvorschläge für Bitcoin (BIPs), und Blitzbolzen.

  • Bitcoin Core #21528 zielt darauf ab, die p2p-Verbreitung von vollständigen Node-Listening-Adressen zu verbessern. Die Exposition gegenüber einem unterschiedlichen Satz von Adressen ist wichtig, damit Knoten gegen Netzwerkpartitionen wie Eclipse-Angriffe geschützt sind. Wenn Bitcoin Core-Knoten eine Adressnachricht mit 10 oder weniger Adressen erhalten, leiten sie diese an 1 oder 2 Peers weiter. Dies ist die primäre Technik, die verwendet wird, um Adressen selbst zu bewerben, so dass das Senden an Peers, die diese Adressen nicht weitergeben würden, die Verbreitung durch das Netzwerk effektiv stoppen oder „schwarzes Loch“ werden würde. Obwohl Verbreitungsfehler im böswilligen Fall nicht verhindert werden können, verbessert dieser Patch die Adressweitergabe für ehrliche Fälle, z. B. für reine Block-Relay-Verbindungen oder Light-Clients.
    Dieses Update identifiziert, ob eine eingehende Verbindung ein Kandidat für die Weiterleitung von Adressen ist oder nicht, basierend darauf, ob sie eine adressbezogene Nachricht über die Verbindung gesendet hat, z. B. addr, addrv2 oder getaddr. Diese Verhaltensänderung könnte problematisch sein, wenn es Software im Netzwerk gibt, die auf den Empfang von Adressnachrichten angewiesen ist, aber niemals eine adressbezogene Nachricht initiiert. Daher hat der Autor darauf geachtet, diese vorgeschlagene Änderung vor der Zusammenführung zu verbreiten, einschließlich der Veröffentlichung in der Mailingliste und der Suche nach anderen Open-Source-Clients, um die Kompatibilität zu bestätigen.
  • LND #5484 ermöglicht das Speichern aller Daten in einer einzigen externen Etcd-Datenbank. Dadurch werden Bereitstellungen mit hoher Verfügbarkeit verbessert, indem Änderungen an der Clusterführung sofort vorgenommen werden. Die entsprechende LND-Clustering-Dokumentation wurde zuvor im Newsletter Nr. 157 behandelt.
  • Rust-Lightning #1004 fügt ein neues Ereignis für PaymentForwarded hinzu, mit dem nachverfolgt werden kann, wann eine Zahlung erfolgreich weitergeleitet wurde. Da für eine erfolgreiche Weiterleitung Gebühren für den Knoten anfallen können, ermöglicht dies die Verfolgung dieser Einnahmen für die Buchhaltungsdatensätze des Benutzers.
  • BTCPay Server #2730 macht den Betrag beim Erstellen von Rechnungen optional. Dies vereinfacht den Zahlungsfluss in Fällen, in denen der Betreiber die Wahl des Betrags an den Benutzer delegiert, z.B. beim Aufladen eines Kontos.

Den Originalbeitrag finden Sie hier.

Bitte abonnieren Sie den Bitcoin Optech Newsletter direkt, um diese Inhalte jeden Monat direkt in Ihren Posteingang zu erhalten.

Free Bitcoins: FreeBitcoin | BonusBitcoin

Coins Kaufen: Bitcoin.deAnycoinDirektCoinbaseCoinMama (mit Kreditkarte)Paxfull

Handelsplätze / Börsen: Bitcoin.de | KuCoinBinanceBitMexBitpandaeToro

Lending / Zinsen erhalten: Celsius NetworkCoinlend (Bot)

Cloud Mining: HashflareGenesis MiningIQ Mining

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close