Was ist Policy?
Policy bezeichnet die lokalen Annahme- und Weiterleitungsregeln einer Bitcoin-Node für den Umgang mit unbestätigten Transaktionen.
Sie bestimmen, welche konsensgültigen Transaktionen eine Node in ihren Mempool aufnimmt und an andere Peers weiterleitet.
Policy entscheidet jedoch nicht darüber, ob eine Transaktion nach den Bitcoin-Konsensregeln gültig ist.
Eine Transaktion kann deshalb konsensgültig sein und trotzdem die Policy einer bestimmten Node nicht erfüllen.
Die Policy gilt immer nur für die jeweilige Node.
Andere Nodes können teilweise andere Policy-Regeln verwenden und trotzdem dieselben Konsensregeln durchsetzen und dieselbe gültige Blockchain akzeptieren.
Wie Konsens- und Policy-Prüfungen innerhalb der Transaktionsvalidierung zusammenspielen, wird unter Validierung im Detail beschrieben.
Für was braucht Bitcoin Policy-Regeln?
In den frühen Versionen von Bitcoin war die Trennung zwischen Konsens und Policy noch nicht so klar strukturiert wie heute.
Mit der Weiterentwicklung von Bitcoin wurde zunehmend deutlich, dass nicht jede Regel für den Betrieb einer Node Teil des Konsens sein sollte.
Konsensregeln bestimmen, welche Transaktionen und Blöcke für Bitcoin gültig sind.
Policy-Regeln bestimmen dagegen, welche konsensgültigen Transaktionen eine Node in ihren Mempool aufnimmt und über das P2P-Netzwerk weiterleitet.
Eine Transaktion kann deshalb vollständig konsensgültig sein und trotzdem von einer Node aufgrund ihrer Policy abgelehnt werden.
Diese Trennung ist wichtig, weil Konsensregeln von allen Nodes einheitlich angewendet werden müssen. Unterschiedliche Policy-Regeln führen dagegen nicht zu unterschiedlichen gültigen Blockchains.
Policy kann deshalb beispielsweise den Mempool und die Relay-Ressourcen einer Node schützen oder festlegen, welche Transaktionsformen als Standard-Transaktionen weitergeleitet werden.
Ein Miner kann eine konsensgültige Transaktion trotzdem in einen Block aufnehmen, auch wenn sie zuvor aufgrund der Policy anderer Nodes nicht weitergeleitet wurde.
Sobald die Transaktion Bestandteil eines Blocks ist, zählt für dessen Gültigkeit ausschließlich der Konsens.
Was prüft eine Node vor der Aufnahme in den Mempool?
Bevor eine Transaktion in den Mempool aufgenommen wird, durchläuft sie mehrere Prüfungen.
Die vollständige Validierungspipeline behandeln wir auf der Seite Validierung. Für Policy ist vor allem wichtig, dass Bitcoin Core dabei zwei Ebenen unterscheidet: Konsensregeln und zusätzliche Mempool-Policy.
Zuerst muss die Transaktion grundsätzlich gültig aufgebaut sein. Dazu gehören unter anderem korrekte Inputs und Outputs, gültige Beträge, vorhandene UTXOs und erfolgreiche Script-Prüfungen.
Danach prüft die Node zusätzliche Policy-Regeln.
Vereinfacht sieht die Aufnahme so aus:
Zu den Policy-Prüfungen gehören beispielsweise die erlaubte Standardgröße einer Transaktion, Standard-Scriptformen und die erforderliche Mindestgebühr.
Auch Konflikte mit bereits im Mempool vorhandenen Transaktionen sowie Regeln für RBF oder Transaktionspakete können bei der Aufnahme eine Rolle spielen.
Wichtig ist: Eine Ablehnung an dieser Stelle bedeutet nicht automatisch, dass die Transaktion konsensungültig ist.
Eine Transaktion kann alle Konsensregeln erfüllen und trotzdem aufgrund der lokalen Policy einer Node nicht in deren Mempool gelangen.
Die einzelnen Konsensprüfungen betrachten wir ausführlich unter Transaktionsvalidierung. Auf dieser Seite konzentrieren wir uns anschließend auf die zusätzlichen Policy-Regeln, die über die reine Konsensgültigkeit hinausgehen.
Was bedeutet Standardness?
Standardness beschreibt, ob eine konsensgültige Transaktion zusätzlich den üblichen Policy-Regeln von Bitcoin Core entspricht.
Erfüllt sie diese Anforderungen, gilt sie als standard und kann unter diesem Gesichtspunkt in den Mempool aufgenommen und weitergeleitet werden.
Verletzt sie eine dieser Regeln, gilt sie als non-standard. Das bedeutet jedoch nicht, dass die Transaktion gegen die Konsensregeln verstößt.
Eine non-standard Transaktion kann deshalb trotzdem Bestandteil eines gültigen Blocks sein.
Was ist Dust?
Als Dust werden sehr kleine Transaktionsoutputs bezeichnet, deren Wert im Verhältnis zu den späteren Kosten ihrer Ausgabe zu gering ist.
Dabei gibt es keinen festen Bitcoin-Betrag, unterhalb dessen ein Output grundsätzlich Dust ist. Die Grenze hängt unter anderem vom Script-Typ und der von der Node verwendeten Dust Relay Fee ab.
Bitcoin Core berechnet dafür eine sogenannte Dust Threshold.
Vereinfacht wird abgeschätzt, wie groß der Output selbst und die spätere Transaktion zum Ausgeben dieses Outputs sein werden. Daraus ergibt sich ein Mindestwert, unterhalb dessen der Output als Dust behandelt wird.
Dust ist eine Policy-Regel und keine Konsensregel.
Ein Output kann also unterhalb der Dust-Grenze liegen und trotzdem konsensgültig sein. Bitcoin Core nimmt Transaktionen mit solchen Outputs jedoch normalerweise nicht in seinen Mempool auf und leitet sie nicht weiter.
Die Dust-Regel verhindert damit vor allem, dass sehr kleine und wirtschaftlich kaum sinnvoll auszugebende Outputs unnötig das UTXO-Set und andere Netzwerkressourcen belasten.
Wann ist eine Gebühr zu niedrig?
Für die Konsensgültigkeit einer normalen Transaktion gibt es keine vorgeschriebene Mindestgebühr.
Eine Transaktion kann deshalb auch mit einer sehr niedrigen oder sogar ohne Gebühr konsensgültig sein.
Für die Aufnahme in den Mempool gelten jedoch zusätzliche Policy-Regeln. Eine Node kann verlangen, dass eine Transaktion eine bestimmte minimale Fee-Rate erreicht.
Dabei wird nicht nur die absolute Gebühr betrachtet, sondern die Gebühr im Verhältnis zur virtuellen Größe der Transaktion:
Fee-Rate = Transaktionsgebühr / vSizeEine Transaktion mit:
Gebühr: 300 sats
vSize: 200 vB
300 / 200 = 1,5 sat/vBbesitzt also eine Fee-Rate von 1,5 sat/vB.
Bitcoin Core kennt dabei verschiedene Schwellen. Die konfigurierte Minimum Relay Fee legt eine grundlegende Untergrenze für Mempool und Relay fest.
Zusätzlich kann bei einem vollen Mempool die tatsächlich erforderliche Mindestgebühr steigen. Bitcoin Core entfernt dann Transaktionen mit niedrigen Fee-Rates und erhöht vorübergehend seine Mempool Minimum Fee.
Damit gibt es keine netzwerkweit feste Grenze, ab der eine Gebühr grundsätzlich „zu niedrig“ ist.
Jede Node entscheidet anhand ihrer eigenen Policy und ihres aktuellen Mempool-Zustands, welche Fee-Rate sie akzeptiert.
Wie Gebühren entstehen und wie Miner Transaktionen anhand ihrer Fee-Rate auswählen, betrachten wir unter Transaktionsgebühren.
Welche Mempool-Limits gelten?
Der Mempool ist kein unbegrenzter Speicher. Jede Node verwaltet ihren eigenen Mempool und kann dafür eigene Grenzen festlegen.
Bitcoin Core begrenzt beispielsweise die maximale Speicherbelegung des Mempools. Wird diese Grenze erreicht, werden Transaktionen mit niedrigen Fee-Rates entfernt, um Platz für wirtschaftlich attraktivere Transaktionen zu schaffen.
Dadurch steigt gleichzeitig die Mempool Minimum Fee. Neue Transaktionen müssen dann eine entsprechend höhere Fee-Rate besitzen, um überhaupt aufgenommen zu werden. Mehr dazu unter Was passiert, wenn der Mempool voll wird?.
Daneben begrenzt Bitcoin Core auch, wie komplex voneinander abhängige Transaktionen im Mempool werden dürfen.
Eine unbestätigte Transaktion kann beispielsweise weitere unbestätigte Transaktionen als Vorfahren (Ancestors) besitzen oder selbst Nachfolger (Descendants) haben. Für solche Abhängigkeitsketten gelten eigene Limits.
Diese Regeln verhindern, dass einzelne Transaktionen oder große Transaktionsketten unverhältnismäßig viel Speicher und Rechenzeit einer Node beanspruchen.
Die Mempool-Limits sind Policy und kein Konsens. Sie können sich zwischen Node-Implementierungen, Versionen und Konfigurationen unterscheiden.
Eine Transaktion, die wegen eines Mempool-Limits abgelehnt oder entfernt wird, ist deshalb nicht automatisch konsensungültig.
Wo wird Policy in Bitcoin Core festgelegt?
Policy ist in Bitcoin Core nicht an einer einzigen Stelle definiert.
Die Regeln verteilen sich auf mehrere Bereiche des Quellcodes. Ein zentraler Teil befindet sich im Verzeichnis
src/policy.
Dort werden unter anderem Regeln und Grenzwerte für Standardness, Dust und Gebühren definiert.
Bei der eigentlichen Aufnahme einer Transaktion in den Mempool werden diese Regeln zusammen mit weiteren Mempool-Prüfungen angewendet.
Vereinfacht:
Ein wichtiger Unterschied zeigt sich damit auch direkt im Quellcode: Policy ist nicht dasselbe wie Konsens.
Policy-Regeln können zwischen Bitcoin-Core-Versionen verändert werden, ohne dass dadurch automatisch die Konsensregeln von Bitcoin verändert werden.
Auch andere Implementierungen wie Bitcoin Knots können eine andere Policy verwenden und trotzdem mit Bitcoin Core auf derselben gültigen Blockchain bleiben.
Aktuelles Beispiel: OP_RETURN und unterschiedliche Policy
Wie unterschiedlich Policy-Regeln ausfallen können, zeigt die aktuelle Diskussion um
OP_RETURN.
Bitcoin Core 30 änderte seine Standard-Policy für
Data-Carrier-Outputs. Das bisherige Standardlimit wurde praktisch aufgehoben und
mehrere OP_RETURN-Outputs innerhalb einer Transaktion können nun standardmäßig über Relay
weitergeleitet werden.
Diese Änderung betrifft zunächst Policy, nicht die Konsensregeln.
Andere Node-Implementierungen oder individuell konfigurierte Nodes können eine strengere Policy verwenden und solche Transaktionen nicht oder nur unter engeren Grenzen in ihren Mempool aufnehmen und weiterleiten.
Dadurch können Nodes unterschiedliche Ansichten darüber haben, welche unbestätigten Transaktionen sie akzeptieren, obwohl sie weiterhin dieselben Konsensregeln für gültige Blöcke anwenden.
Das zeigt einen wichtigen Zweck von Policy: Node-Betreiber können beeinflussen, welche Transaktionen sie lokal speichern und weiterleiten, ohne dafür unmittelbar die Konsensregeln von Bitcoin verändern zu müssen.