Ich habe selbst einige Nachforschungen angestellt, aber ich finde, dass ich entweder selbst voreingenommen bin oder meine Quellen selbst voreingenommen sind. Hat jemand eine objektive Analyse der verschiedenen Vorschläge und ihrer Vor-/Nachteile? First-seen-safe, child-pays-for-parent, full-RBF sind die, die ich kenne, aber ich würde gerne weitere Vorschläge lesen, wenn sie da draußen sind.
Alle drei Vorschläge versuchen, dasselbe Problem zu lösen, nämlich das Problem festgefahrener Transaktionen.
Aufgrund des Verhaltens von Bitcoin Core in Bezug auf doppelte Ausgaben (sie werden stillschweigend gelöscht und nicht weitergeleitet), ist es unmöglich, Ausgaben auszugeben, die Sie in einer bestehenden Transaktion verwendet haben. Normalerweise ist dies eine gute Sache, aber es gibt einige Fälle, in denen ein Benutzer möglicherweise eine fehlerhafte Transaktion erstellt hat (z. B. versehentlich 0 Gebühren festgelegt hat), die aus verschiedenen Gründen nicht akzeptabel oder abbaubar ist, und es für ihn wünschenswert ist in der Lage sein, eine feste Transaktion erneut auszugeben.
Dies wird durch das undefinierte Speicherpoolverhalten von Knoten in Bezug auf das Auslaufen alter Transaktionen und das Fehlen einer klaren Regel, wann es sicher ist, eine weitere Ausgabe zu versuchen, verschlimmert.
Der Child-Pays-For-Parent-Ansatz ermöglicht es, dass die Gebühren des Child einer Transaktion (der Transaktion, die die Ausgaben der hängengebliebenen Transaktion ausgibt) auch für die Parent-Transaktion bezahlt werden. Dies ermöglicht es einem Händler, die erhaltene "kaputte" Transaktion wie jede andere Transaktion auszugeben, und das System sollte in einen konsistenten Zustand zurückkehren.
Der Vorteil von Child-Pays-For-Parent besteht darin, dass es das Problem auf eine Weise löst, die die Mechanik für die Auswahl und Aufbewahrung einer Transaktion nicht grundlegend ändert (insbesondere das zuerst gesehene Verhalten des Speicherpools). Das macht diese Lösung meiner Meinung nach zur intuitivsten.
Die Schwierigkeit bei Child-Pays-For-Parent liegt jedoch in der Umsetzung. Es gibt einige erforderliche Änderungen an der Weitergabe von Transaktionen, die erforderlich sind, damit dies ordnungsgemäß funktioniert (da das bloße Senden eines gültigen untergeordneten Knotens dazu führt, dass andere Knoten die Transaktion ohne den Kontext des übergeordneten Knotens als verwaist betrachten).
Replace-by-Fee versucht, das Problem anzugehen, indem die Grundregel für das Akzeptieren und Halten von Transaktionen, die „first-seen“-Regel, geändert wird.
In diesem System kann eine Transaktion mit höheren Gebühren bereits ausgegebene Eingaben (die noch nicht in einem Block bestätigt wurden) ausgeben und wird diese Transaktion im Speicherpool ersetzen.
Der Vorteil dieses Systems besteht darin, dass es die grundlegende Transaktionsauswahlregel ändert, aber keine Änderungen an der Art und Weise erfordert, wie Gebühren berechnet werden.
Der Nachteil ist, dass dies eine signifikante Verschiebung im Hinblick auf das erwartete Verhalten des Speicherpools darstellt. Meiner Meinung nach macht dies Transaktionen weniger vorhersehbar; Die first-seen-Regel ist unkompliziert, vorhersehbar und leicht zu verstehen und umzusetzen. Darüber hinaus unterbricht es jede Funktionalität, die auf der Vorhersagbarkeit unbestätigter Transaktionen beruht, indem es es trivial macht, doppelte Ausgaben zu tätigen. (Das doppelte Ausgeben einer ersten Transaktion erfordert eine Kombination aus moderaten Netzwerk- und Rechenressourcen, etwas anständigem Know-how und etwas Glück. Das doppelte Ausgeben in einer Welt des Ersetzens durch Gebühr erfordert keines der oben genannten.)
FSS-RBF versucht, RBF mit First-Sehen-Memory-Pool-Implementierungen kompatibel zu machen, indem es verlangt, dass die Ausgaben von der ursprünglichen Transaktion durch nachfolgende Neuausgaben beibehalten werden.
Die Vorteile liegen darin, dass man sich in manchen Situationen auf First-seen-Verhalten verlassen kann. Eine Transaktion, die x BTC an einen Händler sendet, kann dies nicht widerrufen.
In der Praxis ist dieser Schutz jedoch ziemlich schwach. Es bricht Transaktionen, die andere unbestätigte Transaktionen ausgeben, trivial, indem es zulässt, dass die erste Transaktion in der Kette ersetzt wird, wodurch zukünftige Ausgaben ungültig werden. Dies bedeutet, dass die Belastung für das doppelte Ausgeben einer unbestätigten Transaktion nur geringfügig höher ist als beim Standard-Replace-by-Fee.
Es erlaubt einem theoretisch, eine unbestätigte Transaktion zu akzeptieren, die eine bestätigte Ausgabe mit ähnlichem Schutz ausgibt wie das typische First-Sehen-Verhalten.
Es ist jedoch unmöglich, darüber zu sprechen, ohne die Politik zu berühren. Der Grund, warum dies so umstritten ist, ist, dass es eine politische Änderung beinhaltet, die viele Systeme kaputt macht, die auf dem Verhalten des zuerst gesehenen Speicherpools beruhen. Die Befürworter der Änderung glauben, dass, da unbestätigte Transaktionen nicht denselben kryptografischen Schutzmaßnahmen wie bestätigte Transaktionen unterliegen, sie aus dem Ökosystem verdrängt werden sollten und Tools, die dies erleichtern, eingeführt werden sollten. Die Leute, die sich dieser Änderung widersetzen, glauben, dass unbestätigte Transaktionen ein akzeptables Risiko darstellen, wie bei allem bei Bitcoin (denken Sie daran, dass Bitcoin zum Beispiel eine Mehrheit ehrlicher Miner erfordert ), und dass das Brechen von etwas, auf das sich viele Menschen unnötig verlassen, ein Netto-Negativ ist.
Antwort reposted von: Wie funktioniert First Seed Replace by Fee?
Im Moment folgen Bitcoin-Miner größtenteils einer First-Seen-Safe-Regel: Wenn 2 widersprüchliche Transaktionen im Mempool auftauchen, bleibt der Miner bei derjenigen, die er zuerst gesehen hat.
Replace-By-Fee würde es Minern ermöglichen, Transaktionen aus dem Mempool zu entfernen, je nachdem, welche Transaktion die höhere Gebühr zahlt. Dies ist problematisch, da es Betrug ermöglicht. Wenn ich einen Händler bezahle und das Geschäft verlasse, kann ich problemlos eine widersprüchliche Transaktion übermitteln, die das Geld mit nur einer geringfügig höheren Gebühr an mich zurücksendet. Der Händler wird nicht bezahlt, aber ich bekomme die Ware für eine etwas höhere Transaktionsgebühr.
Mit Child-Pays-For-Parent kann eine unbestätigte Transaktion (Eltern) in der Mining-Priorität erhöht werden, indem ihre Ausgabe (Kinder) ausgegeben wird. Die zusätzlichen Gebühren, die von Kindern kommen würden, bieten dem Miner einen Anreiz, die übergeordnete Transaktion einzubeziehen. CPFP bezieht sich auf RBF als eine Möglichkeit für einen Händler, Betrug zu bekämpfen. Wenn ein Händler feststellt, dass eine erwartete Zahlung umgeleitet wurde, kann er die Priorität seiner bevorzugten Transaktion mit CPFP erhöhen. Dies ist eine umstrittene Lösung, um RBF akzeptabel zu machen.
First-Seen-Safe Replace-By-Fee folgt den RBF-Regeln, stellt jedoch einige Anforderungen an das Ersetzen von Transaktionen im Mempool. Beim Ersetzen einer Transaktion auf der Grundlage einer höheren Gebühr müssen alle Beträge aller Ausgaben der ursprünglichen Transaktion erfüllt werden. Sie können Eingaben hinzufügen und entfernen, frühere Ausgabemengen erhöhen und neue Ausgaben hinzufügen. Sie dürfen Transaktionen ändern, solange Sie die vergangenen Ausgaben erfüllen oder übertreffen.
Mit FSSRBF können Sie sicher Transaktionen akzeptieren, die bestätigte Ausgaben ausgeben, aber keine unbestätigten Transaktionen, die Ausgaben anderer unbestätigter Transaktionen ausgeben. CPFP ist über RBF hinaus nützlich, aber für die Verwendbarkeit von FSSRBF nicht erforderlich.
Nick Odell