Ablehnung von Bitcoin-Transaktionen

Ablehnung von Bitcoin-Transaktionen

Du kennst das sicher: Du möchtest eben schnell eine Bitcoin-Transaktion abschicken, vergleichbar mit einem Brief, den du zur Post bringst. Du wählst die richtige Gebühr, klickst auf „Senden“ – und wartest. Manchmal ploppt Tage später die ernüchternde Meldung auf: „Transaktion abgelehnt“. Dieser Artikel erklärt dir anhand zahlreicher Beispiele und Metaphern, warum das passieren kann und wie du es in Zukunft vermeidest.

Bevor wir die Ablehnungsgründe betrachten, schauen wir uns den Weg deiner Transaktion an:

• Broadcast ins P2P-Netzwerk: Deine Wallet übermittelt die TX wie einen Brief an benachbarte Nodes.
• Mempool jedes Nodes: Die TX landet wie ein Paket im Lager (Mempool), solange sie valide und policy-konform ist.
• Mining und Bestätigung: Miner wählen die TX mit der höchsten Gebühr, packen sie in einen Block wie Fracht in einen LKW.
• Blockprüfung und Chain-Update: Andere Nodes prüfen den Block, fügen ihn ihrer Blockchain hinzu und bestätigen so die Zustellung.

Metapher: Stell dir vor, du stehst an einer Supermarkt-Kasse. Die „Express–Lane“ (Höhere Gebühr) ist kürzer, die normale Kasse (niedrige Gebühr) deutlich länger. Bezahlt dein Einkauf weniger, musst du in der langen Schlange warten – oder wirst gar nicht erst eingelassen, wenn der Laden kurz vor Ladenschluss ist.

Historische Entwicklung

In den ersten Bitcoin-Jahren war das Netzwerk wie eine kleine Dorfbäckerei: Jede gültige Transaktion wurde angenommen und weitergeleitet. Mit steigender Nachfrage wandelte sich das Dorf in eine Großstadt, die Mempools füllten sich. Ab Version 0.10 kamen deshalb Policy-Regeln wie minrelaytxfee und dustRelayFee hinzu; in 0.12/0.13 folgten striktere non-standard TX-Filter. Heute trennt Bitcoin Core strikt zwischen Konsensus-Layer (unabdingbare Regeln) und Policy-Layer (konfigurierbare Schwellen).

Konsensus- vs. Policy-Schicht

Konsensus-Fehler (unwiderruflich)

Transaktionen werden endgültig verworfen, wenn sie gegen feste Blockchain-Regeln verstoßen:

• Ungültige Signatur oder Skript-Fehler – wie ein ungültiger Poststempel auf einem Brief.
• Überschreitung des Block- oder TX-Gewichts (max. 4 000 000 Weight Units).
• Doppeltes Ausgeben desselben Coins (Double-Spend).

Policy-Fehler (konfigurierbar)

Jeder Node kann eigene Regeln setzen, um Spam und Ressourcenverschwendung zu vermeiden:

• minrelaytxfee (Standard: 1 sats/vB) – Gebühren unter diesem Wert werden nicht weitergeleitet.
• Dust-Limits: Winzigste Beträge, die das Netzwerk als „Staub“ einstuft und nicht relayed.
• Non-Standard-Filter: Exotische Skript-Typen (z. B. große OP_RETURN-Daten).
• Ancestor/Descendant-Limits: Maximal 25 unbestätigte Vorfahren bzw. Nachkommen pro TX.

Denkanstoß: Stell dir vor, dein Paketdienst sortiert alle Pakete nach Größe und Dringlichkeit. Kleinste Päckchen ohne Priorität bleiben liegen, wenn das Lager voll ist.

Technische Ursachen im Detail

1. Zu niedrige Gebühr und Mempool-Eviction

• Jede Transaktion zahlt eine Gebühr in sats/vB (Fee Rate).
• Nodes speichern unbestätigte TX bis zum -maxmempool-Limit (Standard: 300 MB).
• Wird dieses Limit überschritten, erfolgt eine Eviction:
  • Zuerst jene mit dem niedrigsten effektiven Gebührensatz (Descendant-Score: inkl. abhängiger TX).
  • Bis die Speichernutzung wieder unter 95 % des Limits fällt.
• Gebührenempfehlungen „Priority“ (schnellster Block) vs. „Anytime“ (irgendwann bestätigt) → TimeChainCalendar.

Metapher: Denk an einen Flughafen mit zwei Sicherheitskontrollen: Die VIP-Lane (hohe Gebühr) ist leer, die Economy-Lane (niedrige Gebühr) ist überfüllt. Steht deine „Economy“-Transaktion zu lange an, wird sie womöglich gar nicht erst hereingelassen.

2. Ablaufdatum nach 14 Tagen

• Standard: mempoolexpiry=336 Stunden (14 Tage).
• Unbestätigte TX, die so lange warten, werden gelöscht – unabhängig von Gebühr oder Größe.
• Verhindert, dass veraltete Transaktionen Ressourcen blockieren.

Denkanstoß: Wie würdest du reagieren, wenn dein ungelieferter Koffer nach zwei Wochen aus dem Flughafen-Lager entsorgt wird?

3. Non-Standard-Transaktionen

Nodes lehnen TX ab, deren Skripte/Formate nicht den Policy-Regeln entsprechen:

• Exotische Skript-Typen (z. B. große OP_RETURN-Daten).
• Bare Multisig mit >3 Signaturen.
• Unzulässige Push-Operationen im Skript.
• Dust-Outputs unter dem Staublimit.

4. Konflikte und Double-Spend

• Kommt eine zweite TX mit denselben Inputs ins Mempool oder einen Block, wird deine alte TX verworfen.
• Replace-By-Fee (RBF) erlaubt, eine feststeckende TX durch eine höhere Gebühr zu ersetzen.

5. Ancestor/Descendant-Grenzen

• Max. 25 unbestätigte Vorfahren (Ancestor Limit) bzw. 25 Nachkommen (Descendant Limit) pro TX.
• Überschreitung führt zur Ablehnung oder späteren Eviction.

Praktische Konsequenzen für Nutzer

• Marktübliche Gebühren (≥1–2 sats/vB) verhindern Ablehnungen praktisch vollständig.
• Bei extrem niedrigen Gebühren und hoher Netzlast kann deine TX evicted werden.
• Tipps zur Vermeidung:
• Zahle die empfohlene „Priority“- oder „Anytime“-Gebühr.
• Aktiviere RBF, um bei Bedarf nachzubessern.
• Nutze CPFP (Child-Pays-For-Parent), falls eine abhängige TX hängt.

Ausblick und Optimierungen

• Protokollvorschläge wie Dandelion oder Cohort-Relay zielen auf bessere Weiterleitung ab.
• Weitergehende Mempool-Optimierungen sind in Diskussion, aber noch nicht fest implementiert.
• Modelle à la EIP-1559 für Bitcoin sind derzeit spekulativ.

Wissenswertes

• 1. maxmempool (Standard): 300 MB Speicher für unbestätigte TX.
• 2. mempoolexpiry: 336 Std. (14 Tage) bis zum automatischen Verfall.
• 3. minrelaytxfee: 1 sat/vB – unterhalb keine Weiterleitung.
• 4. Dust-Limit für P2PKH: ~546 sats; P2SH: ~294 sats.
• 5. Ancestor/Descendant-Limit: Max. 25 unbestätigte Vorfahren/Nachkommen.
• 6. Non-Standard Policy schützt seit Bitcoin Core 0.12 vor Spam.
• 7. Fee Evictions erfolgen ab ca. 285 MB Mempool-Auslastung.
• 8. Double-Spend-Konflikte führen zur sofortigen Ablehnung der älteren TX.
• 9. Konkurrenz um Blockplatz spürbar, sobald der Mempool mehrere Dutzend MB groß ist.

Wissen - kurz & kompakt

• Ablehnungen sind selten und meist policy-bedingt (niedrige Gebühr, Ablauf, non-standard).
• Konsensus-Fehler (gültigkeitsrelevant) führen zu sofortiger Verwerfung.
• Policy-Fehler (konfigurierbar) lösen Evictions/Rejections auf Node-Ebene aus.
• RBF und CPFP helfen, feststeckende TX freizubekommen.
• Gute Fee-Schätzung vermeidet Ablehnungen praktisch komplett.

Glossar

• Anytime: Mindestgebühr, bei der deine TX irgendwann bestätigt wird.
• Ancestor Limit: Max. 25 unbestätigte Vorgänger pro Transaktion.
• Descendant Limit: Max. 25 unbestätigte Nachfolger pro Transaktion.
• Dust: Sehr kleine Outputs, die als Spam gelten.
• Fee Rate: Gebühr in sats pro virtual Byte (sats/vB).
• Mempool: Speicherbereich für unbestätigte Transaktionen in jedem Node.
• minrelaytxfee: Policy-Schwelle; TX unterhalb wird nicht relayed.
• mempoolexpiry: Zeitlimit (Std.), nach dem TX verfallen.
• Non-Standard-Transaktion: TX, die nicht den Policy-Regeln entsprechen.
• Priority: Gebührenvorschlag für die schnellstmögliche Aufnahme.
• P2PKH: Pay-to-Public-Key-Hash, Standard-Output-Format.
• P2SH: Pay-to-Script-Hash, flexibleres Output-Format.
• RBF: Replace-By-Fee – ersetzt eine TX durch eine mit höherer Gebühr.
• CPFP: Child-Pays-For-Parent – Kind-TX zahlt höhere Gebühr, um die Eltern-TX zu bestätigen.
• Dandelion: Protokoll zur anonymen TX-Verbreitung.
• Cohort-Relay: Verbesserte Mempool-Propagation.

Denkanstöße und weiterführende Fragen

• Wie würdest du zwischen „sofortiger Bestätigung“ und „geringeren Kosten“ abwägen?
• Welche Kriterien würdest du für non-standard-Skripte in deinem Node festlegen?
• Wie könnten dynamische Mempool-Limits starke Spitzen optimal abfedern?
• Glaubst du, dass Dandelion oder Cohort-Relay das Ablehnungsproblem nachhaltig reduzieren?