Zwischen "Transaktion abgeschickt" und "Transaktion bestätigt" liegt ein Ort, den die wenigsten Bitcoin-Nutzer je bewusst wahrnehmen, obwohl praktisch jede Zahlung ihn durchläuft: der Mempool, kurz für "Memory Pool", der Wartebereich jedes einzelnen Nodes für Transaktionen, die zwar gültig sind, aber noch auf ihre Aufnahme in einen Block warten. Dieser Beitrag erklärt, nach welchen Regeln dieser Wartesaal funktioniert, warum manche Zahlungen länger warten als andere, und was du tun kannst, wenn deine eigene Transaktion feststeckt.
Warum jeder Node einen eigenen Wartesaal führt, statt sich einen zu teilen
Ein Detail, das auf den ersten Blick ineffizient wirkt, ergibt bei genauerem Hinsehen Sinn: Es gibt nicht "den einen" globalen Mempool, sondern jeder einzelne Node führt seinen eigenen, lokalen Wartebereich, mit im Detail durchaus leicht unterschiedlichem Inhalt, je nachdem, wann und über welche Nachbarn er von welchen Transaktionen erfahren hat. Ein zentraler, gemeinsamer Wartesaal würde bedeuten: eine zentrale Stelle, an der jemand entscheidet, wer wartet und wer nicht, genau die Art von Kontrollpunkt, die Bitcoin ja gerade vermeiden will. Stattdessen gleichen sich die vielen lokalen Mempools im Netzwerk laufend von selbst an, einfach dadurch, dass Nodes sich Transaktionen fortlaufend gegenseitig weiterreichen (siehe Teil 5 zur Netzwerkschicht), ohne dass irgendwo eine "Wahrheit" über den Mempool-Zustand zentral festgehalten werden müsste.
Nicht jeder gültige Wunsch wird sofort erfüllt
Ein wichtiger Perspektivwechsel gegenüber Teil 2 dieser Serie: Alles, was in diesem Beitrag beschrieben wird, sind ausdrücklich KEINE Konsensregeln. Es handelt sich um sogenannte "Policy"-Regeln: Regeln, die jeder einzelne Node für sich selbst festlegt, um zu entscheiden, welche Transaktionen er in seinen eigenen Mempool aufnimmt und an seine Nachbarn weiterleitet. Eine Transaktion, die gegen eine reine Policy-Regel verstößt, aber sonst vollkommen gültig ist, könnte theoretisch trotzdem direkt von einem Miner aufgenommen und Teil eines gültigen Blocks werden, nur würde sie eben nicht auf dem üblichen Weg über den Mempool jedes Nodes dorthin gelangen.
Ab wann ein Betrag als "Staub" gilt
Eine besonders anschauliche Policy-Regel ist die Dust-Grenze ("Staub"-Grenze). Die Idee dahinter: Ein Bitcoin-Betrag, der so winzig ist, dass die künftige Gebühr, ihn überhaupt jemals wieder auszugeben, höher wäre als sein eigener Wert, ist wirtschaftlich sinnlos und wird von den meisten Nodes gar nicht erst weitergeleitet.
Der Quellcode (GetDustThreshold in src/policy/policy.cpp) berechnet das ziemlich genau: Er schätzt, wie groß der künftige Input wäre, der nötig ist, um genau diesen Betrag auszugeben, und vergleicht das mit der aktuellen Standard-Gebührenrate. Bei den üblichen Standard-Einstellungen (3.000 Satoshi pro Kilobyte) ergibt das für eine klassische Bitcoin-Adresse eine Dust-Grenze von etwa 546 Satoshi, für eine modernere SegWit-Adresse dank kleinerer, günstigerer Signaturdaten nur rund 294 Satoshi. Ein interessantes Detail: Für Taproot-Adressen wäre die Grenze rechnerisch sogar noch niedriger möglich (da eine einzelne Schnorr-Signatur zum Ausgeben genügt), diese zusätzliche Absenkung wurde im Code aber bewusst nicht vorgenommen, um die allgemeine Dust-Schwelle im Netzwerk nicht noch weiter zu senken.
Ein Blick in den Wartesaal: wie Gebühren tatsächlich zustande kommen
Stell dir den Mempool wie einen Warteraum mit begrenzten Plätzen im nächsten "Bus" (dem nächsten Block, der durchschnittlich alle zehn Minuten abfährt und ungefähr 4 Millionen Gewichtseinheiten Platz bietet, siehe Teil 2 dieser Serie) vor. Ist gerade wenig los, kommt praktisch jede Transaktion problemlos mit, egal wie niedrig ihre Gebühr ist. Wollen zu einem bestimmten Zeitpunkt aber mehr Menschen mitfahren, als Plätze vorhanden sind (etwa weil gerade viele Menschen gleichzeitig Bitcoin bewegen wollen), entscheidet ein einfaches, aber wirkungsvolles Prinzip: Miner sortieren wartende Transaktionen nach Gebühr pro Byte (genauer: pro Gewichtseinheit) und nehmen zuerst diejenigen mit, die am meisten zahlen. Das ist letztlich ein klassischer Marktmechanismus: Kein Beamter legt eine Gebühr fest, sie ergibt sich aus Angebot (verfügbarer Blockplatz) und Nachfrage (wie viele Menschen gerade zahlen wollen) ganz von selbst.
Woher deine Wallet weiß, welche Gebühr gerade angemessen ist
Die meisten Wallet-Apps schlagen dir automatisch eine passende Gebühr vor, ohne dass du selbst rechnen musst. Bitcoin Core löst das über einen eingebauten Schätzmechanismus (die Klasse CBlockPolicyEstimator in src/policy/fees/). Die Grundidee dahinter: Der Node beobachtet fortlaufend, in welchem "Gebühren-Fach" (Bucket) eine Transaktion beim Eintreffen in den Mempool landet, und merkt sich anschließend, nach wie vielen Blöcken Transaktionen aus welchem Gebühren-Fach tatsächlich bestätigt wurden. Über die Zeit ergibt sich daraus ein ziemlich verlässliches Bild: "Transaktionen mit dieser Gebührenrate wurden in den letzten Wochen zu 90 % innerhalb von drei Blöcken bestätigt." Möchtest du eine Zahlung besonders eilig oder kannst du es dir leisten, in Ruhe zu warten, greift deine Wallet auf genau diese historisch gesammelten Werte zurück, um dir eine passende Empfehlung zu machen, ganz ohne dass irgendjemand händisch einen Preis festlegen müsste.
Gebühren nachträglich erhöhen: Replace-by-Fee
Was, wenn du eine Transaktion mit einer zu niedrigen Gebühr abgeschickt hast und sie einfach nicht bestätigt wird? Genau dafür gibt es Replace-by-Fee (RBF, offiziell BIP125): die Möglichkeit, eine noch unbestätigte Transaktion durch eine neue Version mit höherer Gebühr zu ersetzen.
Technisch ist die Umsetzung erstaunlich simpel: Eine Transaktion signalisiert ihre eigene Ersetzbarkeit allein dadurch, dass mindestens einer ihrer Inputs eine bestimmte interne Zahl (nSequence) unterhalb eines festgelegten Schwellenwerts trägt (MAX_BIP125_RBF_SEQUENCE, konkret die Hexadezimalzahl 0xfffffffd). Die zugehörige Prüf-Funktion im Code (SignalsOptInRBF in src/util/rbf.cpp) besteht im Kern aus nichts weiter als einem einzigen Zahlenvergleich pro Input. Ein schönes Beispiel dafür, dass technisch mächtige Funktionen im Bitcoin-Code oft überraschend kompakt umgesetzt sind.
Damit diese Möglichkeit nicht missbraucht werden kann, um gezielt sehr viele fremde, unabhängige Transaktionen im Mempool auf einen Schlag zu verdrängen, gibt es eine eingebaute Obergrenze: Eine einzelne Ersetzung darf höchstens 100 unterschiedliche zusammenhängende Transaktionsgruppen gleichzeitig betreffen (MAX_REPLACEMENT_CANDIDATES in src/policy/rbf.h), ein bewusster Schutz gegen eine Art Überlastungsangriff auf den Mempool anderer Nodes.
Wenn eine Zahlung auf eine andere aufbaut: Ketten-Limits
Bitcoin-Transaktionen können aufeinander aufbauen, bevor überhaupt eine von ihnen bestätigt ist, zum Beispiel, wenn du unbestätigtes Guthaben direkt weiterschickst. Damit solche Ketten aus lauter unbestätigten Transaktionen nicht unkontrolliert wachsen und den Mempool überlasten, begrenzt Bitcoin Core standardmäßig sowohl die Zahl unbestätigter "Vorfahren" als auch unbestätigter "Nachkommen" pro Transaktion auf jeweils 25 (DEFAULT_ANCESTOR_LIMIT, DEFAULT_DESCENDANT_LIMIT in src/policy/policy.h).
Das ist auch der Grund, warum eine beliebte Technik namens "Child Pays For Parent" (CPFP), bei der eine neue, gut bezahlte Transaktion genutzt wird, um indirekt einer feststeckenden Vor-Transaktion zu einer schnelleren Bestätigung zu verhelfen, nicht unbegrenzt funktioniert: Irgendwann greift diese Ketten-Obergrenze.
Ein konkretes Beispiel: Kind hilft Vater
Angenommen, du hast vor einigen Stunden 0,01 BTC an eine Freundin geschickt, aber mit einer inzwischen zu niedrigen Gebühr, und deine Wallet unterstützt kein Replace-by-Fee. Deine Freundin selbst kann trotzdem aktiv werden: Sie erstellt einfach eine neue, eigene Transaktion, die genau diese, noch unbestätigte, Zahlung als Eingang verwendet, und stattet diese neue Transaktion mit einer besonders hohen Gebühr aus. Ein Miner, der diese zweite Transaktion aufnehmen möchte, muss zwangsläufig auch die ursprüngliche, erste Transaktion mit in denselben Block aufnehmen, sie gehören schließlich zusammen. Die hohe Gebühr der zweiten "zieht" die erste quasi mit sich. Genau das ist Child Pays For Parent (CPFP): Das "Kind" bezahlt für die niedrige Gebühr seines "Elternteils", solange die weiter oben beschriebene Ketten-Obergrenze von 25 nicht überschritten wird.
Wenn viele gleichzeitig zahlen wollen: reale Beispiele für volle Wartesäle
Dieses Prinzip ist keine graue Theorie. Bitcoin hat in seiner Geschichte mehrfach Phasen erlebt, in denen die Nachfrage nach Blockplatz das Angebot deutlich überstieg und die üblichen Gebühren dadurch spürbar anstiegen, etwa im Dezember 2017, als ein rasant gestiegenes öffentliches Interesse an Bitcoin zu deutlich mehr gleichzeitigen Transaktionswünschen führte als üblich, oder im Frühjahr 2023, als eine neue, experimentelle Nutzung des Blockplatzes für sogenannte "Ordinals"-Inschriften kurzzeitig für ungewöhnlich volle Mempools sorgte. In beiden Fällen griff exakt derselbe, hier beschriebene Mechanismus: Wer eine schnelle Bestätigung wollte, musste eine höhere Gebühr zahlen, wer Zeit hatte, konnte abwarten, bis sich der Wartesaal wieder leerte. Kein Ausnahmezustand, kein Systemversagen, einfach der beschriebene Mechanismus unter realer Belastung.
Was das für dich als Nutzer praktisch bedeutet
Für den Alltag lassen sich aus diesem Beitrag ein paar handfeste Erkenntnisse mitnehmen: Erstens, eine "unbestätigte" Transaktion ist nicht automatisch verloren, sie wartet lediglich, und moderne Wallets bieten dir meist Werkzeuge (RBF oder CPFP), um selbst nachzuhelfen, statt hilflos zuzusehen. Zweitens, die vorgeschlagene Gebühr deiner Wallet ist keine Schätzung ins Blaue hinein, sondern basiert auf echten, laufend aktualisierten Beobachtungsdaten darüber, was in der jüngeren Vergangenheit tatsächlich funktioniert hat. Und drittens: Wenn eine Zahlung während einer stark ausgelasteten Phase des Netzwerks länger dauert als gewohnt, liegt das nicht an einem technischen Defekt, sondern schlicht an einem ganz gewöhnlichen Angebot-Nachfrage-Mechanismus, demselben, der Preise für so ziemlich jede knappe Ressource bestimmt.
Fazit: Der Mempool ist kein Konsens, aber trotzdem kein Wilder Westen
Der Mempool zeigt gut, dass "dezentral" nicht "regellos" bedeutet: Jeder Node entscheidet zwar formal selbst, welche Transaktionen er akzeptiert, aber die allermeisten folgen in der Praxis denselben, sorgfältig durchdachten Standardregeln, aus gutem Grund, denn diese Regeln schützen jeden einzelnen Node gleichermaßen vor Überlastung und Missbrauch, ohne dass dafür eine zentrale Instanz nötig wäre, die das durchsetzt.
Weiter geht's mit Teil 5: Ohne Zentrale, wie sich Bitcoin-Nodes im Netzwerk überhaupt finden.
