Mempool-Policy: Gebühren, RBF & CPFP

Warum deine Transaktion wartet, und wie du sie bumpst.

Bevor eine Transaktion in einen Block kommt, sitzt sie in den Mempools der Nodes. Konsensregeln sagen, was in einen Block darf. Policy-Regeln, von jedem Node gewählt, entscheiden, was ein Node speichert und weiterleitet. Die Defaults von Bitcoin Core prägen den Großteil des Netzes.

Wichtige Policy-Regeln in Bitcoin Core

  • Größe: Der Mempool ist standardmäßig auf 300 MB begrenzt. Wenn er voll ist, werden die Transaktionen mit der niedrigsten Feerate verdrängt und die Mindestgebühr steigt.
  • Ablauf: Transaktionen werden standardmäßig nach 336 Stunden (zwei Wochen) verworfen.
  • Standardness: Nur bekannte Script-Typen, begrenzte Transaktionsgröße und Outputs über der „Dust“-Schwelle werden weitergeleitet.
  • Minimale Relay-Gebühr: Transaktionen mit sehr niedriger Gebühr werden ignoriert.
  • Paketlimits: Ketten verbundener unbestätigter Transaktionen sind begrenzt.

Feerate ist König

Miner wollen die höchste Gebühr pro Gewichtseinheit, daher werden Gebühren in sat/vB angegeben. Eine 140-vB-Transaktion, die 1.400 Sats zahlt, zahlt 10 sat/vB. Die Größe hängt von Inputs und Script-Typ ab, nicht vom gesendeten Betrag.

Eine hängende Transaktion bumpen

RBF (Replace-By-Fee): eine neue Version broadcasten, die dieselben Inputs mit höherer Gebühr ausgibt. Der Ersatz muss eine höhere absolute Gebühr und Feerate zahlen und den eigenen Relay decken. BIP125 definierte Opt-in-Signalisierung über nSequence, und seit Bitcoin Core 28.0 ist Full-RBF der Default, sodass jede unbestätigte Transaktion ersetzt werden kann.

CPFP (Child Pays For Parent): einen Output der hängenden Transaktion mit hoher Gebühr ausgeben. Miner bewerten das Paket, sodass das Kind den Eltern-Teil hereinzieht.

Pinning und Package Relay

In geteilten Verträgen wie Lightning kann eine Gegenpartei eine Transaktion „pinnen“, etwa indem sie ein großes Kind mit niedriger Gebühr anhängt, was den Ersatz teuer macht. Bitcoin Core 28.0 fügte One-Parent-One-Child-Package-Relay und v3-„TRUC“-Transaktionen mit engeren Limits hinzu, sodass ein Elternteil mit niedriger Gebühr trotzdem mit einem Kind mit hoher Gebühr weitergeleitet werden kann.

Fazit

Transaktionen mit null Bestätigungen sind nicht endgültig. Policy kann zwischen Versionen wechseln, aber Konsens-Regeln können sich ohne Fork nicht ändern.