Bitcoin Core max-fee-exceeded : causes et vérifications

L’erreur max-fee-exceeded dans Bitcoin Core indique qu’une transaction dépasse le plafond de taux de frais appliqué au contrôle. Elle ne signifie pas automatiquement que les frais sont trop faibles ou qu’attendre un bloc suffit. Avant de modifier un paramètre, vérifiez unités, montants des entrées, sorties et monnaie rendue.

La réponse courte : maxfeerate est une limite de protection, pas le montant des frais attribués à la transaction. Relever cette limite ne corrige pas un paiement mal construit ; cela peut seulement autoriser une transaction précédemment refusée. Ce guide traite un problème RPC précis, sans remplacer la vérification des détails dans le portefeuille.

Ce que signifie réellement max-fee-exceeded

La documentation de testmempoolaccept décrit un test d’admission à la mempool pouvant fournir une raison de rejet. Le plafond choisi par le client est distinct de la validité au regard du consensus et du choix économique des frais que vous acceptez de payer.

Les références utilisées ici sont celles de Bitcoin Core 30.0.0. Elles ne supposent pas que chaque fournisseur utilise cet environnement. Pour une autre version, un nœud hébergé ou une bibliothèque, consultez l’aide effective et la réponse complète. Une interface peut résumer l’erreur et masquer le composant qui applique la limite.

Conservez le nom de la méthode, les paramètres non sensibles et le message reçu. Ne publiez pas identifiants RPC, seed, clés ou transactions signées non diffusées. Un rapport technique peut souvent employer des valeurs fictives et la version logicielle, sans exposer les données d’un portefeuille réel.

maxfeerate ne réécrit pas les frais payés

La référence sendrawtransaction distingue la limite et la transaction soumise. Une transaction construite et signée fixe déjà ses entrées et sorties. Passer un plafond différent à l’envoi ne reconstruit pas leur différence économique.

C’est la différence entre une alarme et le défaut signalé. Modifier le seuil laisse intacte une erreur de construction. Changer les frais peut demander de revenir à la préparation de la transaction, puis de signer une version corrigée après les vérifications appropriées. Un paramètre RPC ne répare pas toutes les étapes précédentes.

Désactiver le plafond ne doit pas devenir la réponse habituelle. La possibilité de contourner un contrôle ne prouve pas que le montant soit voulu. Si vous ne pouvez pas reconstituer les frais, arrêtez-vous plutôt que de chercher un nombre assez grand pour faire disparaître l’avertissement.

Convertir BTC/kvB et sat/vB correctement

Le maximum des méthodes citées s’exprime en BTC par kilooctet virtuel. Beaucoup de portefeuilles affichent plutôt des satoshis par octet virtuel. Divisez les sat/vB par 100 000 pour obtenir des BTC/kvB ; multipliez par 100 000 dans l’autre sens. Deux nombres différents peuvent ainsi représenter exactement le même taux.

Ce tableau est une conversion arithmétique, pas une recommandation sur les frais actuels ni une garantie de confirmation. Le guide des frais Bitcoin explique le mécanisme général. Ici, le problème est de ne pas comparer des valeurs exprimées dans des unités différentes.

Par exemple, copier « 10 » depuis un affichage de 10 sat/vB vers un champ BTC/kvB est une erreur d’unité. Notez l’unité à côté de chaque valeur avant de soumettre une requête. Le nom abrégé d’une variable dans une application ne démontre pas ce qu’attend la méthode destinataire.

Exemple complet de frais et de monnaie rendue

Prenons des montants fictifs : 100 000 satoshis en entrée, une sortie de paiement de 70 000 et un reste de 28 000. Les frais valent 2 000 satoshis, puisque 100 000 moins 70 000 moins 28 000 donne 2 000. Pour une taille finale de 200 vB, le taux est de 10 sat/vB.

Si la sortie de reste est omise et que seule celle de 70 000 subsiste, la différence devient 30 000 satoshis. En conservant une taille hypothétique de 200 vB pour l’illustration, on obtient 150 sat/vB. Dans une transaction réelle, supprimer une sortie modifie aussi la taille : il faut la recalculer.

Cela ne prétend pas que 150 sat/vB dépasse le plafond par défaut de Core. L’exemple montre qu’un reste manquant change le coût, avec ou sans rejet automatique. Identifiez séparément le plafond de votre cas. Notre explication des UTXO Bitcoin montre pourquoi les sorties antérieures sont consommées en entier et pourquoi une nouvelle sortie rend la monnaie.

Les vérifications avant la diffusion

1. Identifiez réseau, nœud ou fournisseur et version effective.
2. Relevez la méthode qui rejette la transaction et le plafond appliqué.
3. Retrouvez les montants des sorties antérieures consommées.
4. Vérifiez destinataires, montants et nouvelle sortie de reste.
5. Calculez frais totaux et taux avec la taille virtuelle appropriée.
6. Comparez résultat, budget voulu et plafond dans la même unité.

Le décodage d’une transaction révèle structure et taille, mais ne récupère pas magiquement tous les montants des sorties précédentes. Référencer une entrée ne signifie pas connaître sa valeur. Si ces montants sont absents, le calcul des frais reste incomplet.

Dans un flux PSBT, analyzepsbt fournit des informations et estimations lorsque les données nécessaires sont présentes. Une taille estimée n’est pas une mesure finale déjà vérifiée. Reprenez les contrôles pertinents sur le résultat réellement destiné à l’envoi.

Commencer par une aide qui n’envoie rien

L’aide locale constitue un point de départ dans un environnement configuré. Les commandes suivantes consultent des informations : elles ne construisent, ne signent et ne diffusent aucun paiement. Elles supposent un nœud installé et accessible. Aucun mot de passe ou clé privée n’a besoin d’apparaître dans un exemple public.

bitcoin-cli help testmempoolaccept
bitcoin-cli help decoderawtransaction
bitcoin-cli help analyzepsbt

Les données réelles nécessitent toujours des précautions. Une transaction signée valide contient une autorisation de dépense utilisable : ne la chargez pas sur un site quelconque pour calculer ses frais. Pour apprendre, utilisez un environnement séparé et des données sans valeur, pas les identifiants d’un système de production.

Un test positif ne garantit pas la confirmation

Un contrôle local reflète l’état et les règles du nœud à cet instant. Il ne démontre ni l’acceptation par tous les pairs, ni la diffusion, ni l’inclusion par un mineur dans un délai. Tester, transmettre et confirmer sont des événements distincts demandant des preuves différentes.

Certains champs de réponse peuvent manquer après un rejet ou une évaluation incomplète. Ne programmez pas une application comme si toute réponse possédait toutes les valeurs. Interprétez d’abord le résultat, puis les données disponibles. Un nombre absent ne signifie pas un zéro.

Une transaction déjà diffusée avec des frais insuffisants présente un autre problème. RBF et CPFP ont leurs conditions et ne réparent pas chaque erreur RPC. Établissez quelle version a réellement été transmise avant de passer à une procédure de remplacement ou de transaction enfant.

Ne pas confondre les erreurs voisines

Un rejet pour minimum insuffisant concerne trop peu de frais ; max-fee-exceeded concerne un maximum dépassé. Des entrées manquantes demandent de vérifier la disponibilité des sorties consommées. Un échec de décodage concerne le format. Relever maxfeerate ne corrige pas automatiquement ces problèmes différents.

maxburnamount est encore un autre paramètre : il concerne certaines sorties reconnues comme non dépensables, pas le budget des frais. Ne l’augmentez pas pour réparer une commission. Un contrôle portant sur certaines formes de sorties ne prouve pas non plus que toute autre adresse soit utilisable par le destinataire voulu.

Conserver une trace de diagnostic utile

Avec un fournisseur externe, cherchez aussi l’origine de la réponse : Core, passerelle ou application. Une politique supplémentaire peut s’appliquer avant l’affichage du message. Identifier ce niveau évite de modifier une configuration locale sans rapport avec la requête. Une valeur trouvée dans un autre tutoriel ne décrit pas nécessairement votre service.

Notez en privé l’identité de la transaction, la version du nœud, la limite et les calculs avec leurs unités. Comparez paiement et reste prévus aux sorties finales. Un examinateur dispose alors d’une explication du problème, plutôt que d’une capture montrant seulement une courte étiquette d’erreur.

Gardez frais totaux et taux côte à côte. Un taux correct ne démontre pas que le coût total soit acceptable si la transaction est grande. Un montant total faible ne prouve pas non plus que chaque sortie soit destinée à la bonne personne. Comptabilité et destination doivent être contrôlées séparément.

Questions fréquentes

Attendre peut-il résoudre l’erreur ?

Pas si les mêmes octets dépassent toujours le même plafond. Le temps ne recrée pas le reste et ne corrige pas une conversion. Les conditions du réseau peuvent évoluer, mais il faut identifier le contrôle réel avant d’attribuer tout rejet à la congestion.

Faut-il augmenter les frais ?

Pas en réponse à ce message précis. Reconstituez d’abord le coût déjà inclus dans la transaction. Confondre un maximum dépassé avec un minimum insuffisant peut vous conduire à modifier le paiement dans la mauvaise direction.

Existe-t-il un maximum universellement sûr ?

Aucune valeur unique ne doit être copiée pour tous les cas. Le plafond est une protection à comparer à des montants vérifiés, pas une recommandation de marché. L’aide de votre version et les conditions du fournisseur restent les références opérationnelles.

Un rejet prouve-t-il qu’aucune diffusion n’a eu lieu ?

Il ne reconstitue pas tout l’historique. Si un autre appel ou service a déjà diffusé la transaction, un rejet ultérieur ne l’annule pas. Vérifiez son identité et l’état du processus avant de conclure qu’aucun envoi n’a eu lieu.

Résoudre max-fee-exceeded commence donc par des données correctes : montants rapprochés, unités explicites et plafond choisi consciemment. Si un élément reste inconnu, interrompez l’envoi pour l’éclaircir. Faire disparaître le message ne démontre pas que le paiement sous-jacent est correct.