Sollte das Bitcoin „Dust Limit“ entfernt werden

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,h_1200,q_auto:good,w_1200/MTgzMjM5NTgzMDQyNTc3NDQ2/img_6289.png

Sollte das „Staublimit“, das Bitcoin-Transaktionen unter einem bestimmten Ausgabewert verweigert, abgeschafft werden?

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 fasst eine Diskussion über das Staublimit zusammen und enthält unsere regelmäßigen Abschnitte mit Beschreibungen von Änderungen an Diensten und Client-Software, wie Sie sich auf Taproot vorbereiten können, neue Releases und Release-Kandidaten und bemerkenswerte Änderungen an beliebter Bitcoin-Infrastruktursoftware.

Nachrichten

  • Diskussion zum Staublimit: Bitcoin Core und andere Node-Software verweigern standardmäßig die Weiterleitung oder das Mining von Transaktionen mit einem Ausgabewert unter einem bestimmten Betrag, dem Staublimit (der genaue Betrag variiert je nach Ausgabetyp). Dies macht es für Benutzer schwieriger, unwirtschaftliche Outputs zu erstellen – UTXOs, deren Ausgaben mehr kosten würden, als sie an Wert halten.
    Diese Woche veröffentlichte Jeremy Rubin auf der Bitcoin-Dev-Mailingliste ein Fünf-Punkte-Argument für die Aufhebung des Staublimits und gab an, dass der Grund für das Limit darin besteht, „Spam“- und „Staub-Fingerabdruck-Angriffe“ zu verhindern. Andere antworteten mit Gegenargumenten und stellten fest, dass die Grenze nicht existiert, um Spam zu verhindern, sondern um zu verhindern, dass Benutzer die Ressourcen von Full-Node-Betreibern dauerhaft verschwenden, indem sie UTXOs erstellen, für die die Benutzer keinen finanziellen Anreiz haben, sie jemals auszugeben. In Teilen der Diskussion wurden auch die Auswirkungen sowohl des Staubgrenzwerts als auch unwirtschaftlicher Emissionen auf Teile von LN beschrieben.
    Zum jetzigen Zeitpunkt sah es nicht so aus, als würde eine Einigung wahrscheinlich erzielt werden. Zumindest kurzfristig rechnen wir mit einer Beibehaltung der Staubgrenze.

Änderungen an Diensten und Client-Software

In diesem monatlichen Feature stellen wir interessante Updates zu Bitcoin-Wallets und -Diensten vor.

  • Spark Lightning Wallet fügt Unterstützung für BOLT12 hinzu: Die Version v0.3.0rc von Spark bietet teilweise Unterstützung für die Angebote von BOLT12.
  • Blockstream kündigt einen nicht verwahrten LN-Cloud-Service an, Greenlight: In einem kürzlich veröffentlichten Blogbeitrag beschreibt Blockstream seinen gehosteten C-Lightning-Nodes-in-the-Cloud-Service, der den Node-Betrieb (Blockstream) von der Kontrolle der vom Node gehaltenen Gelder trennt (Benutzer). Sphinx und Lastbit verwenden derzeit beide den Greenlight-Dienst.
  • BitGo kündigt native Ausgabe von Segwit-Änderungen an: Angesichts der Tatsache, dass die Akzeptanz von Segwit den Meilenstein von 75 % überschritten hat, kündigt BitGos Blog-Post ein Update ihrer Standard-Änderungsausgaben an, die von P2SH-verpackt zu nativen Segwit-Ausgaben wechseln.
  • Blockstream Green Desktop 0.1.10 veröffentlicht: Die Version 0.1.10 fügt standardmäßig Segwit-Single-Sig-Wallets und manuelle Münzauswahlfunktionen hinzu.

Vorbereitung auf taproot #9: Signaturadapter

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.

Stellen Sie sich vor, jemand bietet an, 1.000 BTC an eine bestimmte Wohltätigkeitsorganisation zu spenden, wenn jemand die sehr große Lieblingszahl dieser Person erraten kann. Eine einfache Möglichkeit für den Spender, dies zu tun, besteht darin, eine nicht signierte Transaktion zu erstellen, die die 1.000 BTC bezahlt, und dann eine verschlüsselte Kopie seiner Signatur für die Transaktion zu veröffentlichen, wobei die Lieblingsnummer der Entschlüsselungsschlüssel ist.

Theoretisch kann jeder, der die Nummer errät, die Signatur entschlüsseln und dann die Transaktion übertragen und die Wohltätigkeitsorganisation bezahlen. Wenn der Spender jedoch ein Standardverschlüsselungsschema wie AES verwendet, gibt es für Dritte keine einfache Möglichkeit, vor der Entschlüsselung zu wissen, dass die Signatur für diese Transaktion tatsächlich gültig ist. Jeder, der sich anstrengen möchte, Zahlen zu erraten, muss darauf vertrauen, dass der Spender aufrichtig ist und kein Troll.

Lassen Sie uns dieses Problem noch etwas erweitern. Dritte Alice und Bob wollen darauf wetten, ob die Unterschrift aufgedeckt wird oder nicht. Sie könnten den Unterzeichner vielleicht nach dem Hash der Signatur fragen und diesen als Hash in einer HTLC-Funktion verwenden, aber das erfordert wiederum das Vertrauen des Spenders, ehrlich zu handeln. Selbst wenn die Unterschrift schließlich enthüllt wurde, könnte der Spender den Vertrag von Alice und Bob sabotieren, indem er ihnen einen falschen Hash gibt.

Adapter Magie

Signaturadapter, auch allgemein genannt Adaptersignaturen und einmalig nachweisbar verschlüsselte Signaturen, sind eine Lösung für diese Probleme – und für viele andere Probleme, denen man heute tatsächlich in Produktionssystemen begegnet, die auf Bitcoin basieren. Obwohl mit dem bestehenden ECDSA-Signaturschema von Bitcoin verwendbar, ist es in Kombination mit der BIP340-Implementierung von Schnorr-Signaturen für Taproot viel einfacher, Adapter privat und kostenlos zu verwenden. Sehen wir uns an, wie sich unser obiges Beispiel ändert, wenn wir Adapter verwenden.

Nach wie vor bereitet der Spender eine 1.000-BTC-Transaktion vor. Sie unterschreiben fast ganz normal, mit dem einzigen Unterschied, dass sie ihre Nonce im Wesentlichen aus zwei Teilen generieren: einer echten zufälligen Nonce, die sie für immer geheim halten werden, und ihrer Lieblingsnummer – die sie zunächst geheim halten, die aber sicher ist für andere zu entdecken. Der Spender generiert eine vollständig gültige Signatur unter Verwendung dieser beiden Werte und addiert sie, als ob sie eine einzelne Nonce wären.

BIP340-Signaturverpflichtungen verwenden die Nonce in zwei Formen: eine numerische Darstellung (genannt a Skalar), die normalerweise nur der Unterzeichner kennt, und als a Punkt auf der elliptischen Kurve (EC), die veröffentlicht wird, um eine Überprüfung zu ermöglichen.

Der Spender nimmt den Verpflichtungsteil seiner gültigen Unterschrift und subtrahiert den versteckten Skalar. Dies macht die Unterschrift unvollständig (und somit ungültig), ermöglicht es dem Spender jedoch, die (ungültige) Unterschriftszusage, den (gültigen) Punkt für die vollständige Nonce und den (gültigen) Punkt für die versteckte Nummer zu teilen. Zusammen sind diese drei Informationen ein Signaturadapter.

Mit einer leichten Variante des BIP340-Signaturüberprüfungsalgorithmus kann jeder überprüfen, ob der Signaturadapter eine gültige Signatur liefert, wenn der versteckte Skalar einfach wieder der (derzeit ungültigen) Signaturzusage hinzugefügt wird. Dies ist möglich, auch ohne zu wissen, was diese versteckte Nummer ist. Kurz gesagt, es ist jetzt für Benutzer möglich, vertrauenslos Vermutungen über den Wert des versteckten Skalars anzustellen, in der Gewissheit, dass eine korrekte Schätzung es ihnen ermöglicht, die Signatur zu erhalten und die Transaktion zu senden.

Wie alle anderen, die den Signaturadapter des Spenders erhalten haben, haben Alice und Bob jetzt eine Kopie des EC-Punkts für die versteckte Nummer. Wie alle anderen kennen sie auch den tatsächlichen Skalar nicht. Aber wenn Sie sich erinnern, hat der Spender nur die versteckte Zahl von seiner Unterschriftsverpflichtung abgezogen, um seine gültige Unterschrift in eine ungültige Unterschrift zu verwandeln, während die Unterschrift weiterhin bis zum Punkt der versteckten Zahl festgeschrieben wurde. Alice kann genauso leicht eine ungültige Signatur erstellen, indem sie sich nicht auf den ihr unbekannten Skalar, aber dennoch auf den ihr bekannten EC-Punkt festlegt. Sie tut dies, indem sie ihr eigenes Nonce-Paar erstellt, das private Formular verwendet, wenn sie ihre (ungültige) Signatur erstellt, sich aber zur Aggregation der öffentlichen Form ihrer Nonce und des EC-Punkts vom Signaturadapter des Spenders verpflichtet. Dies erzeugt einen Signaturadapter für eine Transaktion, die Bob bezahlt. Wenn Bob den Skalar lernt, kann er diesen Adapter in eine gültige Signatur umwandeln und die Transaktion senden, um die Wette zu gewinnen.

Aber wie lernt Bob die Gewinnzahl? Muss er warten, bis jemand anders es errät, um eine Pressemitteilung zu veröffentlichen? Nö. Erinnern Sie sich noch einmal daran, dass der vom Spender veröffentlichte Signaturadapter seine tatsächliche Signatur minus dem Skalar war. Wenn die versteckte Nummer entdeckt wird und jemand die 1.000-BTC-Transaktion sendet, muss er die ursprüngliche (gültige) Unterschriftszusage veröffentlichen. Bob kann dieses (gültige) Signatur-Commitment nehmen und davon das (ungültige) Signatur-Commitment im ursprünglichen Signaturadapter abziehen, um den Skalar zu erhalten. Anschließend verwendet er diesen Skalar, um Alices Adapter in eine gültige Signatur umzuwandeln.

Multisignatur-Adapter

Der vorherige Abschnitt zeigt, wie einzelne Benutzer die Art und Weise ändern, wie sie ihre Signaturen erstellen, um Signaturadapter zu erstellen. Es ist auch möglich, dass die Parteien einer Multisignatur denselben Trick anwenden. Das ist außerordentlich nützlich, da viele Fälle, in denen Signaturadapter verwendet werden, die Zusammenarbeit von zwei Benutzern erfordern.

Wenn Alice und Bob beispielsweise die obige Wette abschließen, könnten sie damit beginnen, Geld in ein Skript einzuzahlen, das nur von einer Mehrfachsignatur zwischen ihnen ausgegeben werden kann. Dann kann Alice ihre Teilsignatur in Form eines Signaturadapters erzeugen; Wenn Bob die versteckte Nummer erfährt, kann er Alices Adapter in ihre gültige Teilsignatur umwandeln und dann seine Teilsignatur bereitstellen, um eine vollständige Signatur zu erstellen, die das Geld ausgibt.

Dies bietet Signaturadaptern die gleichen Vorteile von Mehrfachsignaturen im Allgemeinen: Sie sehen aus wie eine Einzelsignatur und verbrauchen den gleichen Platz, wodurch die Gebühren minimiert und die Privatsphäre und Fungibilität maximiert werden.

In der nächsten Woche Vorbereitung für Pfahlwurzel In der Spalte werden wir eine der Hauptmethoden untersuchen, von denen wir erwarten, dass Signaturadapter verwendet werden: Point Time Locked Contracts (PTLCs), ein Upgrade für die ehrwürdigen Hash Time Lock Contracts (HTLCs), die ausgiebig in LN, CoinsSwaps und einer Reihe von andere Protokolle.

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.

  • 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.
  • Bitcoin Core 0.21.2rc1 ist ein Release Candidate für eine Wartungsversion von Bitcoin Core. Es enthält mehrere Fehlerbehebungen und kleine Verbesserungen.

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 #22642 aktualisiert den Veröffentlichungsprozess von Bitcoin Core für die kommende Version 22.0, um die GPG-Signaturen aller zu verketten, die die Binärdateien reproduzierbar in einer einzigen Datei erstellt haben, die im Batch verifiziert werden kann (Beispiel). Signaturen von deterministischen Buildern sind seit Jahren verfügbar, aber dies sollte sie zugänglicher machen und auch die bestehende Abhängigkeit von dem Hauptbetreuer des Projekts verringern, der die Release-Binärdateien signiert.
  • Bitcoin Core #21800 implementiert Vorfahren- und Nachkommenlimits für die Annahme von Mempool-Paketen. Bitcoin Core begrenzt die Anzahl der zugehörigen Transaktionen in seinem Mempool zum Schutz vor DoS-Angriffen und damit die Blockkonstruktion für Miner nachvollziehbar ist. Standardmäßig stellen diese Limits sicher, dass keine Transaktion im Mempool zusammen mit seinen Mempool-Vorfahren 25 Transaktionen oder 101 KvB Gewicht überschreiten kann. Die gleichen Regeln gelten für die Transaktion in Kombination mit ihren Mempool-Nachkommen.
    Diese Vorfahren- und Nachkommen-Limits werden durchgesetzt, wenn eine Transaktion für die Aufnahme in den Mempool in Betracht gezogen wird. Wenn das Hinzufügen der Transaktion dazu führen würde, dass eines der Limits überschritten wird, wird die Transaktion abgelehnt. Obwohl die Paketsemantik noch nicht abgeschlossen ist, implementiert #21800 Vorfahren- und Nachkommen-Grenzwertprüfungen zur Validierung beliebiger Pakete (d. h. wenn mehrere Transaktionen gleichzeitig für das Hinzufügen zum Mempool in Betracht gezogen werden). Die Annahme von Mempool-Paketen wurde nur zu Testzwecken in #20833 implementiert und wird schließlich über das p2p-Netzwerk als Teil des Paket-Relays verfügbar gemacht.
  • Bitcoin Core #21500 aktualisiert den listdescriptors RPC mit einem privaten Parameter, der, wenn er gesetzt ist, die private Form jedes Deskriptors zurückgibt. Das private Formular enthält alle bekannten privaten Schlüssel oder erweiterten privaten Schlüssel (xprvs), sodass dieser aktualisierte Befehl zum Sichern der Brieftasche verwendet werden kann.
  • Rust-Lightning #1009 fügt eine Kanalkonfigurationsoption max_dust_htlc_exposure_msat hinzu, die den Gesamtsaldo anstehender „staubiger HTLCs“ begrenzt, deren Mengen unter der Staubgrenze liegen.
    Diese Änderung dient der Vorbereitung eines vorgeschlagenen Feature-Bits option_dusty_htlcs_uncounted, das ankündigt, dass der Knoten „staubige HTLCs“ nicht gegen max_accepted_htlcs zählen möchte. Knotenbetreiber würden dieses Feature-Bit wahrscheinlich übernehmen wollen, da max_accepted_htlcs hauptsächlich verwendet wird, um die potenzielle Größe der Onchain-Transaktion zu begrenzen, wenn ein Force-Closing stattfinden sollte und „staubige HTLCs“ Onchain nicht beanspruchbar sind und niemals die endgültige Transaktionsgröße beeinflussen würden.
    Die neu hinzugefügte Kanalkonfigurationsoption max_dust_htlc_exposure_msat stellt sicher, dass Benutzer auch bei eingeschalteter Option_dusty_htlcs_uncounted das Gesamtguthaben von „staubigen HTLCs“ begrenzen können, da dieses Guthaben bei einem erzwungenen Schließen als Gebühren an die Bergleute verloren gehen würde.

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