Der Fehler max-fee-exceeded in Bitcoin Core bedeutet, dass eine Transaktion die angewendete Obergrenze für den Gebührensatz überschreitet. Er bedeutet nicht automatisch, dass die Gebühr zu niedrig ist oder dass ein weiterer Block das Problem löst. Vor einer Parameteränderung sind Einheiten, Eingabebeträge, Ausgaben und Wechselgeld zu prüfen.
Die kurze Antwort lautet: maxfeerate ist eine Schutzgrenze, nicht die Gebühr, die der Transaktion zugewiesen wird. Eine höhere Grenze repariert keine fehlerhafte Zahlung. Sie kann nur eine zuvor abgewiesene Transaktion zulassen. Dieser Leitfaden behandelt ein konkretes RPC-Problem und ersetzt nicht die Prüfung der Zahlungsdetails im Wallet.
Was max-fee-exceeded tatsächlich aussagt
Die Dokumentation zu testmempoolaccept beschreibt einen Test der Mempool-Annahme, der einen Ablehnungsgrund liefern kann. Die vom Aufrufer gesetzte Obergrenze ist von Konsensgültigkeit und wirtschaftlicher Gebührenentscheidung zu unterscheiden. Nicht jede technisch gültige Zahlung entspricht auch dem beabsichtigten Budget.
Als Referenz dienen hier die RPC-Seiten für Bitcoin Core 30.0.0. Daraus folgt nicht, dass jeder Anbieter dieselbe Umgebung betreibt. Bei einer anderen Version, Bibliothek oder einem gehosteten Knoten ist die tatsächliche Hilfe mit der vollständigen Antwort zu lesen. Eine Oberfläche kann den Fehler verkürzt darstellen.
Halte Methodenname, nicht vertrauliche Parameter und Fehlermeldung fest. Veröffentliche keine RPC-Zugangsdaten, Seeds, Schlüssel oder noch nicht gesendeten signierten Transaktionen. Für eine technische Anfrage genügen oft Versionsangaben und mit Testdaten nachgebildete Werte, ohne echte Wallet-Unterlagen offenzulegen.
maxfeerate verändert die gezahlte Gebühr nicht
Die Referenz zu sendrawtransaction trennt die Grenze von der eingereichten Transaktion. Eine erstellte und signierte Transaktion legt Eingaben und Ausgaben bereits fest. Ein anderer Höchstwert beim Senden baut deren wirtschaftliche Differenz nicht neu auf.
Das entspricht dem Unterschied zwischen Alarm und gemeldetem Fehler. Eine veränderte Alarmschwelle lässt einen Konstruktionsfehler bestehen. Eine andere tatsächliche Gebühr kann den Rückweg zur Erstellung und die Signatur einer korrigierten Fassung erfordern. Ein RPC-Parameter repariert nicht automatisch alle vorherigen Arbeitsschritte.
Die Schutzprüfung abzuschalten sollte keine Standardlösung sein. Dass ein Programm eine Grenze umgehen kann, beweist nicht die Absicht hinter einem Betrag. Kannst du die Gebühr nicht selbst nachvollziehen, stoppe lieber, statt nach einer ausreichend großen Zahl gegen die Warnmeldung zu suchen.
BTC/kvB und sat/vB richtig umrechnen
Die genannte RPC-Grenze wird in BTC pro Kilovirtualbyte angegeben. Viele Wallets zeigen dagegen Satoshis pro Virtualbyte. Teile sat/vB durch 100.000, um BTC/kvB zu erhalten. In der Gegenrichtung wird mit 100.000 multipliziert. Unterschiedliche Zahlen können damit denselben Satz in unterschiedlichen Einheiten beschreiben.
| Gebührensatz in sat/vB | Entsprechung in BTC/kvB |
|---|---|
| 1 | 0.00001000 |
| 5 | 0.00005000 |
| 10 | 0.00010000 |
| 25 | 0.00025000 |
Die Tabelle ist reine Umrechnung, keine Empfehlung für heutige Gebühren oder eine Bestätigungsgarantie. Der Leitfaden zu Bitcoin-Gebühren erklärt den allgemeinen Mechanismus. Hier geht es um einen engeren Fehler: Zahlen mit verschiedenen Einheiten dürfen nicht ungeprüft verglichen werden.
Eine „10“ aus einer Wallet-Anzeige mit 10 sat/vB in ein BTC/kvB-Feld zu kopieren, wäre ein Einheitenfehler. Schreibe vor einer Anfrage jede Einheit neben den Wert. Ein kurzer Variablenname in einer Anwendung ist kein belastbarer Nachweis dafür, welche Einheit der empfangende Dienst erwartet.
Rechenbeispiel mit Gebühr und Wechselgeld
Wir verwenden erfundene Beträge: insgesamt 100.000 Satoshis aus Eingaben, eine Zahlungsausgabe von 70.000 und Wechselgeld von 28.000. Die Gebühr beträgt 2.000 Satoshis, denn 100.000 minus 70.000 minus 28.000 ergibt 2.000. Bei einer endgültigen virtuellen Größe von 200 vB sind das 10 sat/vB.
Fehlt die Wechselgeldausgabe und bleibt nur die Ausgabe von 70.000, beträgt die Differenz 30.000 Satoshis. Bei zur Illustration beibehaltenen hypothetischen 200 vB wären es 150 sat/vB. In einer echten Transaktion verändert eine entfernte Ausgabe auch die Größe. Diese muss deshalb erneut berechnet werden.
Das Beispiel behauptet nicht, 150 sat/vB überschreite die Core-Standardgrenze. Es zeigt einen veränderten Preis durch fehlendes Wechselgeld, unabhängig davon, ob eine automatische Prüfung anschlägt. Die tatsächlich angewendete Grenze ist separat zu ermitteln. Die Erklärung der Bitcoin-UTXOs erläutert, warum vorherige Ausgaben vollständig verbraucht und neue Wechselgeldausgaben erzeugt werden.
Prüfungen vor dem Senden
- Netz, Knoten oder Anbieter und tatsächliche Version feststellen.
- Ablehnende Methode und angewendete Grenze identifizieren.
- Beträge der verbrauchten vorherigen Ausgaben nachvollziehen.
- Empfänger, Zahlungsbeträge und neue Wechselgeldausgabe prüfen.
- Gesamtgebühr und Satz mit der passenden virtuellen Größe berechnen.
- Ergebnis mit beabsichtigtem Budget und Schutzgrenze in derselben Einheit vergleichen.
Das Dekodieren einer Transaktion zeigt Struktur und Größe, beschafft aber nicht automatisch sämtliche Beträge vorheriger Ausgaben. Ein Verweis auf eine Eingabe ist nicht dasselbe wie die Kenntnis ihres Werts. Fehlen diese Beträge, bleibt die Gebührenrechnung unvollständig.
Bei PSBT-Abläufen kann analyzepsbt Informationen und Schätzungen liefern, wenn die nötigen Daten vorliegen. Eine geschätzte Größe ist keine bereits gemessene endgültige Größe. Die relevanten Prüfungen müssen für das tatsächlich zum Senden vorgesehene Ergebnis wiederholt werden.
Mit Hilfebefehlen beginnen, die keine Zahlung senden
Die lokale Hilfe ist ein sinnvoller Anfang in einer eingerichteten Umgebung. Die folgenden Befehle lesen Informationen. Sie erstellen, signieren oder übertragen keine Zahlung und setzen eine installierte, erreichbare Konfiguration voraus. Passwörter und private Schlüssel gehören nicht in ein öffentliches Beispiel.
bitcoin-cli help testmempoolaccept
bitcoin-cli help decoderawtransaction
bitcoin-cli help analyzepsbtEchte Transaktionsdaten benötigen weiterhin Datenschutz. Eine gültige signierte Transaktion enthält eine nutzbare Ausgabenautorisierung. Lade sie nicht auf beliebige Webseiten, um ihre Gebühr berechnen zu lassen. Zum Üben dient eine getrennte Testumgebung mit wertlosen Daten, nicht eine Kopie der produktiven Zugangsdaten.
Ein erfolgreicher Test garantiert keine Bestätigung
Ein lokaler Test beschreibt Zustand und Regeln dieses Knotens zu diesem Zeitpunkt. Er bestätigt weder Annahme durch alle Teilnehmer noch tatsächliche Übertragung oder Aufnahme durch einen Miner innerhalb einer Frist. Test, Versand und Bestätigung sind verschiedene Ereignisse mit unterschiedlichen Nachweisen.
Einzelne Antwortfelder können bei einer abgewiesenen oder nicht vollständig geprüften Transaktion fehlen. Eine Anwendung sollte deshalb nicht erwarten, dass jede Antwort dieselben Werte enthält. Zuerst wird das Ergebnis eingeordnet, danach werden vorhandene Felder gelesen. Eine fehlende Zahl ist nicht automatisch null.
Eine bereits verbreitete Transaktion mit zu niedriger Gebühr ist ein anderer Fall. RBF und CPFP haben eigene Voraussetzungen und lösen nicht jeden RPC-Fehler. Vor einer Ersatz- oder Kindtransaktion ist zu klären, welche Fassung tatsächlich übermittelt wurde und welches Problem noch besteht.
Ähnliche Fehlermeldungen nicht gleich behandeln
Eine Mindestgebührenablehnung betrifft zu wenig im Verhältnis zur Prüfung; max-fee-exceeded betrifft ein überschrittenes Maximum. Fehlende Eingaben verlangen eine Prüfung der vorherigen Ausgaben. Ein Dekodierungsfehler betrifft das Format. Eine höhere maxfeerate löst diese verschiedenen Ursachen nicht automatisch.
Auch maxburnamount ist ein eigener Parameter. Er betrifft bestimmte als nicht ausgebbar erkannte Ausgaben und nicht das Gebührenbudget. Erhöhe ihn nicht, um eine Gebührenfrage zu beheben. Eine Prüfung bestimmter Ausgabeformen beweist umgekehrt nicht, dass jedes andere Skript vom vorgesehenen Empfänger genutzt werden kann.
Ein brauchbares Diagnoseprotokoll führen
Bei einem externen Dienst ist außerdem die Herkunft der Antwort zu klären: Bitcoin Core selbst, ein Gateway oder der Anwendungscode. Ein Anbieter kann eine eigene Regel anwenden oder eine Meldung vor der Anzeige verändern. Wer diese Ebene identifiziert, vermeidet Änderungen an einer lokalen Konfiguration, die an der Anfrage gar nicht beteiligt ist. Ein Wert aus einem fremden Tutorial beschreibt nicht automatisch den eigenen Dienst.
Bei einer Integration sollten Umrechnung und Eingabe-Ausgabe-Rechnung getrennte Tests erhalten. Verwende dafür bekannte Beträge und eine Zahlendarstellung ohne unbeabsichtigte Rundungsfehler. Der Test muss auch den absichtlich falschen Einheitenvergleich erkennen. Nur das richtige Beispiel einmal erfolgreich zu berechnen, prüft den Fehlerpfad noch nicht. Das ist eine Empfehlung zur Softwareprüfung und kein Aufruf zu Versuchen mit echten Zahlungen.
Nach einer Korrektur muss außerdem klar bleiben, welche Fassung geprüft wurde. Ein anderer Empfänger, eine geänderte Wechselgeldausgabe oder eine erneute Erstellung kann die vorherige Rechnung ungültig machen. Halte deshalb die Ergebnisse beim jeweiligen Datensatz und bestätige nicht eine neue Transaktion nur deshalb, weil eine ältere Version den Test bestanden hat. Dadurch wird aus einem allgemeinen Prüfvermerk ein nachvollziehbarer Nachweis für die tatsächlich betrachtete Zahlung.
Notiere Transaktionsidentität, Knotenversion, relevante Grenze und berechnete Werte mit Einheiten in einer privaten Arbeitsunterlage. Vergleiche geplante Zahlung und Wechselgeld mit den endgültigen Ausgaben. Ein Prüfer erhält dann eine nachvollziehbare Erklärung statt eines Screenshots mit nur einem kurzen Fehlerwort.
Gesamtgebühr und Gebührensatz sollten nebeneinanderstehen. Ein passender Satz beweist bei einer sehr großen Transaktion keinen angemessenen Gesamtpreis. Ein geringer Gesamtbetrag belegt wiederum nicht den richtigen Empfänger. Buchhaltung und Ziel müssen getrennt geprüft werden, bevor aus einem technisch lesbaren Datensatz eine bewusste Zahlung wird.
Für ein Entwicklungsteam lohnt sich außerdem ein kleines Prüfmuster mit bekannten Beträgen. Es sollte eine richtige Umrechnung und einen absichtlich falschen Einheitenvergleich enthalten. Das ist ein Vorschlag für lokale Qualitätssicherung, kein Bericht über einen von CryptoRoad ausgeführten Mainnet-Versuch. Es müssen dafür keine echten Mittel bewegt werden.
Häufige Fragen
Hilft es, einfach zu warten?
Nicht, wenn dieselben Bytes weiterhin dieselbe Obergrenze überschreiten. Zeit erzeugt weder Wechselgeld noch eine korrekte Umrechnung. Netzbedingungen können sich ändern. Vor einer solchen Erklärung muss aber die konkrete Prüfung identifiziert werden, statt jede Ablehnung mit einer überfüllten Mempool zu begründen.
Soll ich die Transaktionsgebühr erhöhen?
Nicht als unmittelbare Antwort auf diese Meldung. Rekonstruiere zuerst den bereits eingebauten Preis. Wer eine überschrittene Obergrenze mit einem unzureichenden Minimum verwechselt, kann die Zahlung in die falsche Richtung verändern und das wirtschaftliche Problem vergrößern.
Gibt es einen für alle sicheren Höchstwert?
Kein einzelner Wert sollte als Lösung für jede Transaktion kopiert werden. Die Grenze ist eine Schutzentscheidung im Vergleich mit geprüften Beträgen, keine Marktprognose. Dokumentation der eigenen Version und Bedingungen des Anbieters bleiben die betrieblichen Referenzen. Ein fremdes Beispiel beschreibt nicht automatisch die eigene Konfiguration.
Beweist die Ablehnung, dass nichts gesendet wurde?
Sie rekonstruiert nicht die vollständige Vorgeschichte. Hat ein anderer Aufruf oder Dienst dieselbe Transaktion bereits übertragen, macht eine spätere Ablehnung dies nicht rückgängig. Prüfe Transaktionsidentität und Ablaufstatus, bevor du annimmst, es habe nirgendwo einen Versand gegeben.
Die richtige Reaktion auf max-fee-exceeded beginnt damit bei Daten statt Umgehungen: abgestimmte Beträge, ausdrückliche Einheiten und eine bewusst gewählte Grenze. Bleibt etwas ungeklärt, wird der Versand unterbrochen und die Frage geklärt. Eine verschwundene Fehlermeldung beweist noch keine korrekte Zahlung.
