ristic.png”>
Dies ist ein Meinungsleitartikel von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Moderator.
Große Überraschung, Bitcoiner streiten sich wütend über einen Vorschlag Änderungssatz, der in die nächste Version von Bitcoin Core aufgenommen werden soll. Opt-in replace-by-fee (RBF) ist eine Mempool-Richtlinienfunktion, die 2015 vorgeschlagen wurde, um Benutzern ein Tool zur Verfügung zu stellen, um mit schnellen Gebührenspitzen fertig zu werden, die dazu führen, dass ihre Transaktionen unbestätigt im mempool für längere Zeit.
Natürlich wird dies ein Problem für jede Verwendung von Bitcoin, wenn das Transaktionsvolumen im Durchschnitt konstant höher wird als die Anzahl der Transaktionen, die in der Blockchain verarbeitet werden können, es sei denn, Sie glauben, dass dies niemals passieren wird Dies ist eine erforderliche Funktion im Netzwerk.
Die Transaktionsersetzung war tatsächlich in der ursprünglichen Version der Software enthalten und möglich, bevor Satoshi Nakamoto verschwand. Er deaktivierte die Funktion schließlich, weil die Art und Weise, wie er sie ursprünglich implementierte, einen Vektor für Denial-of-Service-Angriffe gegen Knoten schuf. Seine Implementierung ermöglichte das Ersetzen jeder Transaktion ohne Zahlung einer höheren Gebühr, was es den Benutzern im Wesentlichen ermöglicht hätte, eine Transaktion zu senden und dann mit der Übertragung einer unbegrenzten Anzahl von Ersetzungen an das Netzwerk zu beginnen. Dies würde offensichtlich das Spamming von Knoten mit riesigen Datenmengen ermöglichen, für die kein Proof-of-Work erforderlich wäre, und die Kosten für den Betrieb eines Knotens unerschwinglich erhöhen.
Im Laufe der Jahre wurden einige verschiedene Vorschläge für einen überarbeiteten und sichereren Transaktionsersatz gemacht Schema diskutiert worden. Wir werden all dies schnell durchgehen.
Full RBF
Die einfachste Variante von RBF. Jede Transaktion kann ersetzt werden, solange für die Ersetzung der ursprünglichen Transaktion eine höhere Gebühr gezahlt wird als für die, die sie ersetzt. Auf diese Weise sind alle Transaktionen ersetzbar, aber die Anforderung, jedes Mal eine höhere Gebühr zu zahlen, wenn Sie eine ersetzen, verhindert einen endlosen Spam von neuen Versionen der Transaktionsüberladungsknoten.
First-Seen-Safe RBF
Hier wurde vorgeschlagen, dass alle Transaktionen im Mempool ersetzt werden können, mit einer besonderen Einschränkung; Alle Ausgaben der ursprünglichen Transaktion müssen auch in der Ersatztransaktion enthalten sein, einschließlich der Änderungsausgabe. Es erfordert immer noch eine Erhöhung der Gebühr, um eine Transaktion zu ersetzen, aber die Anforderung, dieselben Ausgaben beizubehalten, bedeutet, dass Sie eine neue Eingabe und eine zweite Änderungsausgabe hinzufügen müssen, da keine der ursprünglichen Ausgaben geändert werden kann. Dies führt zu größeren Transaktionen, die insgesamt mehr Gebühren zahlen müssen, um sicherzustellen, dass der Ersatz einen höheren Gebührensatz zahlt.
Delayed RBF
Hier war ein Vorschlag, um zuzulassen, dass jede Transaktion im Mempool ersetzt wird, aber erst nachdem eine bestimmte Anzahl von Blöcken verstrichen ist, seit der Node die ursprüngliche Transaktion gesehen hat. Die Idee war, dass dies es ermöglichen würde, festgefahrene Transaktionen in Umgebungen mit hohen Gebühren schneller zu ersetzen und zu bestätigen, aber die zeitliche Verzögerung, wie schnell sie ersetzt werden könnten, würde Doppelausgabenversuche ohne Bestätigung verhindern.
Opt-in RBF
Dies wurde 2016 implementiert, wie in BIP 125. Transaktionen können nur ersetzt werden, wenn sie ein bestimmtes Flag in der Transaktion setzen, die sich für den Ersatz entscheidet, oder wenn einer ihrer Vorfahren dies im Fall einer Kette unbestätigter Transaktionen getan hat, damit Personen, die Geld erhalten, wissen, ob es sich um eine unbestätigte Transaktion handelt oder nicht austauschbar im mempool.
Die große Kontroverse heute ist, dass die nächste Version von Core, 0.24, ein vollständiges RBF-Mempool-Richtlinien-Flag einführen wird. Was bedeutet das? Es gibt Benutzern eine konfigurierbare Option, um ihre lokale Mempool-Richtlinie von Opt-in-RBF auf vollständiges RBF zu ändern; Standardmäßig wird die Option deaktiviert (die Knoten verwenden das vollständige RBF). Warum also empören sich die Leute über diese Veränderung? Unternehmen, die Null-Bestätigungs-Transaktionen akzeptieren, hängen von der überwiegenden Mehrheit der Mempools der Knoten ab, die sich weigern, Transaktionen, die sich nicht für RBF entschieden haben, durch ein Transaktions-Flag zu ersetzen. Sie tun dies, indem sie ihren Knoten taktisch mit einer großen Anzahl anderer Knoten verbinden, die über das gesamte Netzwerk verteilt sind. Dies ermöglicht es ihnen, das Vorhandensein einer Doppelausgaben-Transaktion im Netzwerk sehr schnell zu erkennen, da dies fast sofort erfolgen muss, wenn eine Transaktion nicht als RBF gekennzeichnet ist, um eine gute Chance zu haben, zu den Minern zu gelangen. Es sollte auch darauf hingewiesen werden, dass dies nicht jedes Unternehmen im Netzwerk tun kann, ohne das Netzwerk effektiv sybilisieren. Diese Unternehmen behaupten, dass das vollständige RBF ihr Geschäftsmodell der Verwendung von RBF „durchbricht“. Einige haben sogar Core-Entwickler kritisiert, dass sie eine Änderung „erzwingen“, die sich negativ auf diese Unternehmen auswirkt.
Die einfache Realität ist, dass doppelte Ausgaben möglich waren und immer möglich sein werden, Opt-in-RBF oder volles RBF ändert daran nichts. Darüber hinaus schreibt das einfache Erstellen einer Option zum Ändern Ihrer eigenen lokalen Mempool-Richtlinie (die standardmäßig deaktiviert ist) in keiner Weise jemandem Änderungen vor, sondern ist eine Option, die Benutzern gegeben wird, um eine Wahl für sich selbst zu treffen. Am Ende des Tages, wenn es darum geht, welche Transaktionen tatsächlich in den nächsten Block aufgenommen werden, sind die einzigen Mempools, die von Bedeutung sind, die der Miner. Die Mempools einzelner Benutzerknoten sind nichts anderes als eine Daisy-Chain von Speicherspeichern mit dem ultimativen Ziel, all diese unbestätigten Transaktionen an die Miner weiterzugeben, damit sie schließlich in einen Block aufgenommen werden können.
Die Mempool-Richtlinie wird als eine Art weicher Sicherheitsmechanismus verwendet, um Denial-of-Service-Angriffe auf Knoten zu verhindern und Benutzer davor zu schützen, sich mit komplizierten Transaktionen und Skripten selbst ins Knie zu schießen. Viele Arten von Transaktionen sind im Konsens gültig, dürfen in einen Block aufgenommen werden, werden aber nicht von der Standard-Mempool-Richtlinie der Knoten weitergeleitet. Dies hindert einen entschlossenen Benutzer jedoch überhaupt nicht daran, eine Transaktion, die von Knoten im Netzwerk ignoriert würde, direkt an einen Miner weiterzuleiten.
Das ist der springende Punkt. Alles, was es braucht, ist, dass Miner eine API einrichten, um Transaktionen direkt an sie zu übermitteln, was viele bereits haben, und die Einschränkungen der Mempool-Richtlinien im gesamten Netzwerk spielen keine Rolle. Sie können den Minern einfach eine Transaktion direkt geben und jede Regel umgehen, wann etwas im Mempool anderer Knoten ersetzt werden kann. Denken Sie über die Anreize nach – wenn es Geld zu verdienen gibt, indem Sie eine bestimmte Klasse von Transaktionen abbauen, aber Mempools im gesamten Netzwerk sie nicht weiterleiten, was würden Sie als Miner tun? Akzeptiere sie einfach direkt. Je mehr die Subvention sinkt und die Transaktionsgebühren als Prozentsatz der Minereinnahmen steigen, desto unvermeidlicher wird es, dass Miner direkt Ersatz akzeptieren, der höhere Gebühren zahlt, wenn Knoten im Netzwerk sie nicht indirekt weiterleiten. Es ist unausweichlich.
Diese Änderung ändert nicht die standardmäßige Mempool-Richtlinie für Bitcoin Core, sie bietet lediglich eine Option für einen einzelnen Knotenbetreiber, um seine lokale Mempool-Richtlinie zu ändern, wenn er dies wünscht.
Und ich möchte hinzufügen, dass dies eine Option war, die immer verfügbar war, wenn Benutzer ihren Client ändern wollten. Alles, was es tut, ist, eine Wahl zu treffen, die den Benutzern schon immer zur Verfügung stand. Die Anreize führen zwangsläufig dazu, dass alle Transaktionen ersetzbar sind, wenn die Miner wirtschaftlich rational handeln – es ist unvermeidlich. Die einzige Frage ist, ob die Software diese Anreize widerspiegeln sollte, sodass einzelne Benutzer selbst entscheiden können, welche Richtlinie für ihren Mempool verwendet werden soll, oder ob die Leute einfach herumsitzen und die Verbreitung von Transaktionen um die direkte Übermittlung an Miner herum zentralisieren lassen sollten sich?
Das Endergebnis ist das gleiche, aber das Warten darauf, dass Miner zur direkten Transaktionsübermittlung tendieren, wird sehr negative Folgen haben. Dies hätte Auswirkungen auf den Datenschutz für Personen, die Transaktionen an das Netzwerk senden, und es könnte sehr negative Folgen für die Fähigkeit der Benutzer haben, zu entscheiden, welche Gebühr für eine Transaktion zu zahlen ist. Wenn große Teile der ausstehenden Transaktionen nicht mehr öffentlich über das Netzwerk übertragen werden, haben die Benutzer eine unvollständige Übersicht darüber, gegen wen sie für die Aufnahme in einen Block bieten. Die Bergleute könnten sogar über die Gebührenverteilung lügen, um die Benutzer dazu anzuregen, mehr zu zahlen, als sie müssen.
Der einzige wirkliche Nachteil bei der Bereitstellung dieser Option ist, dass das vollständige RBF möglicherweise nicht konsistent funktioniert, wenn nur ein kleiner Teil des Netzwerks, einschließlich der Miner, sich dafür entscheidet, das vollständige RBF zu aktivieren. Dies unterscheidet sich im Hinblick auf den Übergang jedoch grundsätzlich nicht von dem Upgrade auf SegWit. Während dieser Übergangszeit leiteten nicht aktualisierte Knoten SegWit-Transaktionen nicht weiter, da sie nicht in der Lage waren, sie zu validieren, sodass während dieser Zeit dieselbe Dynamik der Ausbreitung inkonsistent war, bis genügend Benutzer ein Upgrade durchgeführt hatten. Aber letztlich änderte das nichts an der Tatsache, dass ein Upgrade eine Entscheidung der einzelnen Benutzer war.
Letztendlich leugnet der Kampf gegen volles RBF nur die Realität der Anreize im Netzwerk. Nichts wird irgendjemandem vorgeschrieben, eine Konfigurationsoption bietet einzelnen Benutzern einfach eine Wahl, die sie für sich selbst treffen können. Ich finde es seltsam, dass gleichzeitig so viele Menschen die Realität von Anreizen ignorieren, um zu argumentieren, dass ein unsicheres Zahlungsmittel trotz Anreizen sicher gehalten werden kann, genauso wie die Leute argumentieren, dass Softwarebenutzer keine Wahl haben sollten, wie ihre eigene Software zu konfigurieren.
Mein Knoten, meine Regeln, richtig?
Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.
