Ablehnung von Bitcoin-Transaktionen

Ablehnung von Bitcoin-Transaktionen

Du kennst das sicher: Du möchtest eben schnell eine Bitcoin-Transaktion abschicken, vergleichbar mit einem Einschreiben zur Post bringen. Du widmest dich Online-Gebühren, klickst auf "Senden" – und… wartest. Manchmal ploppt am nächsten Tag die ernüchternde Meldung auf: „Transaktion abgelehnt“. Dieser Artikel erklärt dir anhand anschaulicher Beispiele und Metaphern, warum das passieren kann und wie du es in Zukunft vermeidest.

Analyse des Sachverhalts

Bevor wir uns den Ablehnungsgründen widmen, betrachten wir den typischen Ablauf einer Transaktion:

• Broadcast ins P2P-Netzwerk: Deine Wallet sendet die TX wie einen Brief an benachbarte Nodes.
• Mempool jedes Nodes: Die TX wird wie Post im Briefkasten abgelegt, 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 Pakete in einen LKW.
• Blockprüfung und Chain-Update: Andere Nodes prüfen den Block, ergänzen ihre Blockchain, als würden sie die Postzustellung bestätigen.

Denkanstoß: Wie würdest du handeln, wenn dein „Brief“ länger als zwei Wochen in der Postfiliale liegt und nie zugestellt wird?

Historische Entwicklung

In den ersten Bitcoin-Jahren war das Netzwerk wie eine kleine Dorfpost: Jede gültige Transaktion wurde angenommen und weitergeleitet. Mit zunehmender Popularität verwandelte sich das Dorf in eine Großstadt, die Mempools wurden voll, und Nodes führten ab Version 0.10 Policy-Regeln ein (minrelaytxfee und dustRelayFee). Ab Version 0.12 und 0.13 kamen striktere non-standard TX-Filter hinzu. Heute trennt Bitcoin Core klar zwischen Konsensus-Layer (unabdingbare Regeln) und Policy-Layer (konfigurierbare Schwellenwerte).

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: Die kryptographische Prüfung schlägt fehl, vergleichbar mit einem ungültigen Unterschriftsstempel auf einem Dokument.
• Ü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 weitergereicht.
• Dust-Limits: Kleinstbeträ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.

Beispiel/Metapher/Anekdote: Stelle dir vor, dein Paketdienst sortiert alle Pakete nach Größe und Dringlichkeit. Staubfeine Briefe und Kartons 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: Dabei wird die TX mit dem niedrigsten effektiven Gebührensatz (Descendant-Score – inkl. aller abhängigen TX) zuerst entfernt, bis die Speichernutzung wieder unter 95 % des Limits fällt.
• „Priority“ vs. „Anytime“: Gebührenempfehlungen für „nächster Block“ vs. „irgendwann“ → TimeChainCalendar.

Denkanstoß: Wie würdest du den Parkplatz-Manager überzeugen, dein Auto (TX) mit geringer Gebühr länger stehen zu lassen?

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 TX Ressourcen blockieren.

3. Non-Standard-Transaktionen

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

• Exotische Skript-Typen (z. B. große OP_RETURN-Nutzlast).
• Bare Multisig mit mehr als drei Signaturen.
• Unzulässige Push-Operationen in Skripten.
• 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 dir, eine feststeckende TX durch eine mit höherer Gebühr zu ersetzen.

5. Ancestor/Descendant-Grenzen

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

Praktische Konsequenzen für Nutzer

• Solange du marktübliche Gebühren (≥1–2 sats/vB) zahlst, siehst du kaum Ablehnungen.
• Bei extrem niedrigen Gebühren und hoher Netzlast kann deine TX evicted werden.
• Tipps zur Vermeidung:
• Nutze gebührenempfohlene Werte („Priority“ oder „Anytime“) deiner Wallet.
• Aktiviere RBF, um bei Bedarf nachzubessern.
• Erwäge CPFP (Child-Pays-For-Parent), falls eine abhängige TX hängt.

Ausblick und Optimierungen

• Fee-Markt-Modelle wie ein EIP-1559-ähnlicher Mechanismus könnten die Gebührenschwankungen glätten.
• Protokollerweiterungen wie Dandelion oder Cohort-Relay optimieren Mempool-Propagation und reduzieren Spam.
• Verbesserte Mempool-Policies und dynamische Limits könnten künftige Spitzenlasten abmildern.

Wissenswertes

• 1. maxmempool (Standard): 300 MB Speicher für unbestätigte TX.
• 2. mempoolexpiry: 336 Std. = 14 Tage bis zur automatischen Aussonderung.
• 3. minrelaytxfee: 1 sat/vB – unterhalb keine Weiterleitung im P2P-Netz.
• 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 seit Bitcoin Core 0.12 schützt vor Spam.
• 7. Fee Evictions treten nur bei Mempool >285 MB auf (95 % von 300 MB).
• 8. Double-Spend-Konflikte führen unmittelbar zur Ablehnung der älteren TX.
• 9. Erste spürbare Konkurrenz um Blockplatz ab Mempool-Größe von ~50 MB.
• 10. Extrem-Spitzen (>300 MB) und damit Evictions gab es in den letzten Jahren nur wenige Male jährlich.

Wissen - kurz & kompakt

• Ablehnungen sind selten und meist policy-bedingt (niedrige Gebühr, Ablauf, non-standard).
• Konsensus-Fehler (gültigkeitsrelevant) führen zu sofortiger, endgültiger Verwerfung.
• Policy-Fehler (konfigurierbar) lösen Evictions oder 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 vom Netzwerk als Spam betrachtet werden.
• Fee Rate: Gebühr in sats pro virtual Byte (sats/vB).
• Mempool: Speicherbereich für unbestätigte Transaktionen in jedem Node.
• minrelaytxfee: Policy-Schwelle; niedriger gebührenstarke TX werden nicht relayed.
• mempoolexpiry: Zeitgrenze (Std.), nach der TX automatisch verfallen.
• Non-Standard-Transaktion: TX, die nicht den Policy-Regeln für Skripte/Formate entspricht.
• Priority: Gebührenvorschlag für schnellstmögliche Aufnahme (nächster Block).
• P2PKH: Pay-to-Public-Key-Hash, ein Standard-Transaction-Output-Format.
• P2SH: Pay-to-Script-Hash, ein flexibleres Output-Format.
• RBF: Replace-By-Fee – Mechanismus, um eigene TX durch höhere Gebühr zu ersetzen.
• CPFP: Child-Pays-For-Parent – Kind-Transaktion zahlt hohe Gebühr, um Eltern-TX zu bestätigen.
• Dandelion: Protokoll zur anonymen und gesteuerten TX-Verbreitung.
• Cohort-Relay: Verbesserte Mempool-Propagation für schnellere und sicherere Weiterleitung.

Denkanstöße und weiterführende Fragen

• Wie wärest du bereit, zwischen „sofortiger Bestätigung“ und „geringeren Kosten“ abzuwägen?
• Welche Kriterien würdest du für non-standard-Skripte in deinem Node festlegen – genauere Kontrolle oder maximale Flexibilität?
• Inwiefern könnten dynamische Mempool-Limits helfen, starke Spitzen optimal zu bewältigen?
• Glaubst du, dass Protokollerweiterungen wie EIP-1559, Dandelion oder Cohort-Relay das Ablehnungsproblem nachhaltig reduzieren werden?