Stell dir vor, jemand hat dir Bitcoin mit einer niedrigen Gebühr geschickt, und die Zahlung ist noch unbestätigt. Unterstützt deine Wallet dafür CPFP, kannst du eine Folgetransaktion erstellen, etwa an eine weitere eigene Adresse. Die ursprüngliche Transaktion heißt Parent, die neue Child: Das Child gibt einen Output des Parents aus, also einen Betrag mit festgelegten Ausgabebedingungen. Um die Gebühr des Childs einzunehmen, braucht der Miner auch den Parent. Die ursprüngliche Zahlung bleibt unverändert. Das höhere Gebührenangebot kann bei der Bestätigung helfen, garantiert aber keinen Zeitpunkt.
Anna wartet auf 100 000 sat. Die Abkürzung sat steht für Satoshi, die kleinste Einheit von Bitcoin. Sie sieht die Zahlung bereits, doch der Absender hat eine niedrige Gebühr gewählt und die Transaktion steht noch in keinem Block. Ihre Wallet erlaubt, diesen unbestätigten Output auszugeben. Anna erstellt damit eine neue Transaktion an eine eigene Adresse und bietet eine höhere Gebühr. Sie zahlt weder an den Absender noch an einen besonderen Dienst, sondern eine gewöhnliche Bitcoin-Transaktionsgebühr. Ein Miner kann die neue Transaktion nicht ohne die ursprüngliche bestätigen, weil der benötigte Output in der geprüften Blockchain fehlen würde. Der Parent muss zuvor bestätigt worden sein oder im selben Block vor dem Child stehen, zusammen mit weiteren erforderlichen unbestätigten Vorgängertransaktionen. Umgekehrt gilt das nicht: Der Parent kann auch ohne das Child bestätigt werden. [3] [5]
Nehmen wir ein einfaches Beispiel ohne weitere unbestätigte Vorgänger. Der Parent ist 200 vB groß und zahlt 200 sat. Ein virtuelles Byte, vB, ist ein aus dem Transaktionsgewicht abgeleitetes Größenmaß; sat/vB gibt die angebotenen Satoshi je Einheit an. Das Child ist 100 vB groß und Anna zahlt dafür 2 800 sat. Hat es nur einen Output, bleiben ihr von den empfangenen 100 000 sat noch 97 200 sat. Zusammen zahlen beide Transaktionen 3 000 sat für 300 vB, also 10 sat/vB. Das Child allein bietet 28 sat/vB, doch der Miner muss auch den schwach bezahlten Parent aufnehmen. Nur auf die hohe Zahl des Childs zu schauen, lässt diese Abhängigkeit außer Acht. Das ist eine Beispielrechnung, keine Empfehlung für die heutige Gebührenrate; die Wallet prüft die tatsächlichen Größen und die erforderliche Gesamtgebühr. Weitere notwendige Vorgänger ändern die Rechnung. Ein Detail für Fortgeschrittene: Bei der lokalen Paketannahme werden bereits angenommene Transaktionen nicht erneut eingerechnet, und der Knoten — ein Programm zum Prüfen und Weiterleiten von Transaktionen — kann modifizierte Gebühren verwenden. Die dort angezeigte Rate muss deshalb nicht der einfachen gemeinsamen Rechnung für einen Miner entsprechen. Die modifizierte Gebühr ist ein lokaler Wert für Entscheidungen des Knotens. Sie ändert nicht die tatsächlich von der Transaktion gezahlte Gebühr. [3]
CPFP ist kein Knopf, mit dem jeder eine fremde Transaktion beschleunigen kann. Du musst einen Output des Parents ausgeben dürfen und seine Bedingungen einschließlich der Signaturen erfüllen. Anna kann das als Empfängerin; der Absender kann möglicherweise einen eigenen Wechselgeld-Output verwenden, auch change genannt. Einen Betrag im Explorer oder in einer Watch-only Wallet zu sehen, reicht nicht. Eine Watch-only Wallet verfolgt Zahlungen, hält aber selbst keine privaten Schlüssel, mit denen sich die Beträge ausgeben lassen. Außerdem muss die Wallet das Ausgeben des unbestätigten Outputs unterstützen. Prüfe vor dem Unterschreiben, welchen Output du ausgibst, wohin das Geld geht, wie viel übrig bleibt und welche Gesamtgebühr anfällt. Bei einem kleinen Output kann die Gebühr einen erheblichen Teil seines Werts aufbrauchen. [5]
Replace-by-Fee (RBF) erstellt eine neue, konkurrierende Transaktion, die die ursprüngliche ersetzen soll. Sie gibt mindestens einen gleichen Input aus, muss aber nicht genau dieselbe vollständige Input-Menge haben. CPFP lässt dagegen die ursprüngliche Zahlung samt ihrer Kennung bestehen und fügt eine weitere Transaktion hinzu. Für RBF musst du die Bedingungen der Inputs der Ersatztransaktion erfüllen; für gewöhnliches CPFP die eines Outputs der ursprünglichen Zahlung. Deshalb kann ein Empfänger CPFP nutzen, obwohl er die Ersatztransaktion des Absenders nicht unterschreiben kann. Eine unabhängige Zahlung mit hoher Gebühr zu senden hilft nicht: Das Child muss tatsächlich von der wartenden Zahlung abhängen. [3]
Eine höhere gemeinsame Gebührenrate gibt dem Miner einen stärkeren Grund, beide Transaktionen aufzunehmen. Sie reserviert aber keinen Platz im nächsten Block. Besser bezahlte Transaktionen können hinzukommen, oder das Paket erreicht manche Miner nicht. Beobachte deshalb die Bestätigungen der ursprünglichen Zahlung und des Childs. Die Annahmemeldung eines Knotens ist noch keine Bestätigung in einem Block. Ersetzt der Absender die ursprüngliche Zahlung per RBF, kann sich ein Child, das auf deren alten Output verweist, nicht einfach an die andere neue Transaktion anhängen. Die Situation muss neu beurteilt werden. Auch ein erstelltes Child macht aus einem unbestätigten Eingang keine sichere Zahlung. [3]
Die folgenden Abschnitte erläutern Regeln für vertiefendes Lesen und den eigenen Knoten. Ein Mempool ist die Liste wartender Transaktionen eines bestimmten Knotens, keine gemeinsame Warteschlange des gesamten Netzes. Ein Paket ist eine Gruppe zusammen eingereichter Transaktionen. Drei Entscheidungen sind zu trennen: Ist eine Transaktion gültig, nimmt ein Knoten sie an und wählt ein Miner sie aus? Der Konsens bestimmt die Gültigkeit von Transaktionen und Blöcken. Die Mempool-Richtlinie bestimmt die lokale Annahme und Weiterleitung; die Regeln des Miners bestimmen die Auswahl für den Kandidatenblock. CPFP verändert den Konsens nicht. Ein wirtschaftlich attraktives Paket kann lokale Regeln verletzen, und seine Annahme durch einen Knoten verpflichtet weder andere Knoten noch Miner. [3] [5]
Die Möglichkeiten, Parent und Child gemeinsam weiterzuleiten, entwickeln sich weiter. Package CPFP bedeutet, zusammenhängende Transaktionen als Paket zu prüfen. Ein RPC ist ein Befehl zur Bedienung des Knotens; minrelaytxfee bezeichnet dessen Mindestrate für die gewöhnliche Weiterleitung. TRUC ist eine besondere Transaktionsform mit eingeschränkten Beziehungen zwischen Vorgängern und Nachfolgern. Die folgende Entwicklung betrifft die angegebenen Bitcoin-Core-Versionen. Bitcoin Core 26 führte die RPC submitpackage und Paket-CPFP ein: Eine Kindtransaktion konnte einer Elterntransaktion unterhalb des dynamischen Mindestgebührensatzes des Mempools helfen, damals jedoch nicht unterhalb des Mindestgebührensatzes für Relay. Diese Einschränkung ist nicht zeitlos. Core 31 erlaubt beim unterstützten Relay-Paket aus einer Eltern- und einer Kindtransaktion auch eine Elterntransaktion unter minrelaytxfee, einschließlich einer Gebühr von null, auch außerhalb von TRUC. Weitere unbestätigte Elterntransaktionen des Kindes müssen bereits im Mempool sein. Lokale Annahme garantiert weiterhin keine einheitliche Weiterleitung im gesamten Netzwerk. [1] [2]
Ein Knoten kann keine beliebig großen Netze von Abhängigkeiten annehmen. Ein Vorgänger wird vor einer anderen Transaktion benötigt; ein Nachfolger gibt Outputs im weiteren Verlauf dieser Abhängigkeiten aus. WU bezeichnet Gewichtseinheiten einer Transaktion, die Topologie beschreibt ihre Verknüpfungen. Diese technischen Grenzen gehören zur Policy der jeweiligen Knotenversion. Grenzen schützen Speicher, Rechenleistung und Übertragungskapazität. Ältere Core-Versionen begrenzten Anzahl und Größe von Vorfahren und Nachkommen; Core 31 ersetzte diese Mempool-Grenzen durch Grenzen für zusammenhängende Cluster. Gesonderte Paketgrenzen bleiben bestehen: Die Dokumentation von Core 31 nennt höchstens 25 Transaktionen und ein Gesamtgewicht von 404000 WU. Gewicht ist nicht virtuelle Größe. Unzulässige Topologie, ein Konflikt oder ein Verstoß gegen lokale Regeln für akzeptierte Transaktionsformen (Standardness) können CPFP auch bei ausreichender Gebühr verhindern. [2] [3]
Verknüpfte wartende Transaktionen lassen sich wirtschaftlich nicht immer einzeln bewerten. Cluster Mempool ermöglicht dem Knoten, zusammenhängende Gruppen zu betrachten. Ein Cluster ist die gesamte verbundene Gruppe; eine kleinere Gruppe bei der Transaktionsauswahl heißt Chunk. Das sind keine Teile bereits bestätigter Blöcke. Bitcoin Core 31 verwendet Cluster Mempool: Ein Cluster besteht aus Transaktionen, die über Eltern-Kind-Beziehungen in beliebiger Richtung verbunden sind. Die Standardgrenzen betragen 64 Transaktionen und 101 kB virtuelle Größe pro Cluster; sie sind konfigurierbar. Die Reihenfolge berücksichtigt gemeinsam geminte Gruppen, sogenannte chunks, und deren Gebührensätze. Der historische CPFP carveout erlaubte eine begrenzte Ausnahme vom Nachkommenlimit; Core 31 entfernte ihn, sodass sich das Transaktionszahllimit eines Clusters so nicht umgehen lässt. [2] [4]
Die Befehle dieses Abschnitts sind nicht austauschbar. Ein Test beschreibt gegebenenfalls nur ein Ergebnis; das Einreichen eines Pakets kann signierte Transaktionen tatsächlich annehmen und weiterleiten. Das Feld vsize gibt die virtuelle Größe an. Eine gewöhnliche Wallet kann diese Details für ihre Nutzer übernehmen. In Core 31 zeigt die RPC getmempoolentry für eine Transaktion im Mempool dieses Knotens Gebühren, vsize, Abhängigkeiten und Angaben zum chunk; getmempoolcluster zeigt den zugehörigen Cluster. Die RPC testmempoolaccept führt einen lokalen Test ohne Annahme und Übertragung durch. Bei mehreren Transaktionen müssen Vorfahren vor Nachkommen stehen, und die Transaktionen dürfen weder untereinander noch mit dem Mempool in Konflikt stehen. Die RPC submitpackage reicht ein unterstütztes Paket tatsächlich zur Mempool-Annahme und Weiterleitung ein und ist nicht nur ein Test. Prüfe die Ergebnisse der einzelnen Transaktionen, Version und Konfiguration; kein Ergebnis garantiert die Aufnahme in einen geminten Block. [2] [6] [7] [8] [9]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, Transaktion, UTXO. Auf diesen Eintrag verweisen außerdem Change Address, Bestätigung, Double Spend, Fee Rate.