Envoyer un paiement ne signifie pas qu’il est confirmé. Avant qu’un mineur l’inclue dans un bloc, les nœuds — des programmes qui vérifient et relaient les transactions Bitcoin — peuvent le conserver dans leur Mempool, leur liste locale de transactions en attente. Sous certaines conditions, RBF leur permet d’accepter à sa place une nouvelle transaction dépensant au moins l’un des mêmes UTXO, c’est-à-dire une sortie encore non dépensée. Le remplacement doit porter des signatures valides et être transmis au réseau ; des frais plus élevés ne garantissent pas à eux seuls une confirmation rapide.
Anna a envoyé 20 000 sat, mais son paiement attend toujours. L’abréviation sat désigne le satoshi, la plus petite unité de bitcoin. Son portefeuille propose d’augmenter les frais avec RBF. Prenons un exemple simple : la transaction initiale dépense 50 000 sat, dont 20 000 sat pour le destinataire, 200 sat de frais et 29 800 sat rendus à Anna comme monnaie. Le remplacement peut toujours verser 20 000 sat au destinataire, porter les frais à 2 000 sat et rendre 28 000 sat à Anna. Ces chiffres illustrent le principe, sans recommander un montant de frais actuel. Avant de signer, Anna vérifie l’adresse, le montant reçu et les nouveaux frais totaux. Le portefeuille doit pouvoir signer les entrées nécessaires ; il peut falloir reconnecter le portefeuille matériel. Le remplacement possède un nouveau txid, son identifiant de transaction : le destinataire peut donc avoir besoin d’un nouveau lien de suivi. Augmenter les frais n’est pas créer un deuxième paiement indépendant avec d’autres UTXO. Les deux paiements indépendants pourraient être confirmés et vous paieriez deux fois. [1] [2] [12]
Un portefeuille peut afficher un paiement entrant avant sa première confirmation. On parle de zero-conf : le paiement a été vu, mais ne figure pas encore dans un bloc. Une autre version peut être confirmée d’abord et le paiement affiché peut disparaître. La mention ‘RBF désactivé’ ne prouve donc pas que le paiement est acquis. Livrer un bien contre un paiement non confirmé revient à accepter un risque commercial. Une fois la transaction incluse dans un bloc, RBF ne peut plus la réécrire. Une éventuelle réorganisation de la chaîne constitue un autre risque, qui justifie d’attendre davantage de confirmations pour les paiements importants. [1]
RBF n’impose pas de conserver le destinataire initial. Le remplacement peut augmenter les frais tout en payant la même personne, ou envoyer les fonds ailleurs. Les deux versions cherchent à dépenser le même UTXO : ce sont des tentatives concurrentes, techniquement un Double Spend. Ce terme ne suffit pas à dire s’il s’agit d’une fraude. Un attaquant ne peut toutefois pas signer arbitrairement le paiement d’autrui : le remplacement doit satisfaire les conditions de dépense, dont les signatures requises. Si un portefeuille propose une ‘annulation’ en remplaçant le paiement par un versement à vous-même, il tente de devancer la transaction initiale ; il ne garantit pas son annulation. [1]
RBF modifie la transaction en attente elle-même. Child Pays for Parent (CPFP) conserve l’originale et crée une nouvelle transaction qui dépense l’une de ses sorties. Pour toucher les frais de la nouvelle, un mineur doit aussi inclure l’originale et peut donc examiner leur taux de frais combiné. La nouvelle transaction est appelée enfant, l’originale parent. Toute personne capable de dépenser la sortie concernée peut créer l’enfant, par exemple le destinataire ou l’expéditeur utilisant sa monnaie rendue. Les possibilités dépendent du portefeuille, des signatures requises et des liens entre transactions. CPFP ne remplace pas le paiement original et ne garantit pas non plus de délai de confirmation. [2]
Le Mempool n’est pas une file d’attente unique pour tout Bitcoin. Chaque nœud tient sa liste et applique ses règles d’acceptation et de transmission des transactions en attente. RBF relève de cette politique locale, pas du consensus qui détermine la validité des blocs. Un mineur peut donc choisir une transaction conflictuelle valide qu’un autre nœud ne conservait pas. Un Full Node vérifie ensuite le bloc entier selon les règles de Bitcoin ; la préférence antérieure de son mempool ne détermine pas le résultat. L’acceptation d’un remplacement par un nœud ne promet pas son acceptation partout. [1] [6]
Deux chiffres distincts comptent pour l’utilisateur : le coût total et le taux proposé pour la taille de la transaction. Pour une taille théorique de 200 vB, 200 sat donnent 1 sat/vB ; à taille égale, 2 000 sat donnent 10 sat/vB. L’octet virtuel, vB, est une unité de taille dérivée du poids de la transaction. La reconstruction peut changer sa taille : le portefeuille doit alors recalculer le taux. Les frais totaux sont un montant en satoshis ; le taux de frais est un montant par octet virtuel en sat/vB. Pour un remplacement unique dans Core 30, les frais doivent couvrir la somme des frais de toutes les transactions évincées, plus le coût calculé selon incrementalrelayfee pour la taille du remplacement. Son taux doit dépasser ceux des transactions directement conflictuelles. Un taux supérieur à lui seul ou le simple ajout de satoshis ne suffit pas ; Core 30 utilise par défaut incrementalrelayfee de 0,1 sat/vB, mais le réglage du nœud peut différer. [2] [9]
Un autre paiement en attente peut déjà dépendre du premier : quelqu’un dépense une sortie de la première transaction, encore non confirmée. Ces transactions suivantes sont ses descendants. Si leur parent disparaît, elles ne sont plus utilisables dans le mempool ; le nœud doit donc considérer tout le groupe concerné. Remplacer une transaction parente peut également évincer du mempool les descendants qui dépensent ses sorties. Il ne s’agit donc pas toujours de comparer seulement deux transactions. Pour un remplacement unique, Core 30 limite à 100 la somme des nombres de descendants des transactions directement conflictuelles, en incluant ces transactions elles-mêmes ; ce calcul peut compter plusieurs fois les descendants communs. Les frais et les relations dans le paquet peuvent donc influencer la réussite du remplacement. [2]
Le nœud doit aussi empêcher qu’on le submerge de remplacements à recalculer sans cesse. C’est une protection contre le DoS, une attaque visant la disponibilité du service. Un UTXO est une sortie non dépensée d’une transaction antérieure ; une entrée de la nouvelle transaction y fait référence. Les règles suivantes décrivent précisément Bitcoin Core 30, pas une loi immuable de Bitcoin. La politique de Bitcoin Core 30 pour une transaction de remplacement unique limite aussi les nouvelles entrées non confirmées et le nombre de transactions évincées. Le remplacement doit respecter les règles locales sur les formes de transactions acceptées (standardness), ainsi que les règles de propagation et de validité, et pas seulement dépenser le même UTXO. Ces limites protègent le processeur, la mémoire et la capacité de transmission ; les règles de remplacement de paquets doivent être examinées séparément selon la version du nœud. Core 31 a modifié cette politique avec Cluster Mempool, qui examine en groupes les transactions en attente liées entre elles. Un remplacement doit améliorer le feerate diagram, un graphique comparant les frais cumulés à l’espace progressivement occupé. D’autres conditions restent applicables, notamment des frais totaux suffisants et un supplément pour relayer le remplacement. N’applique donc pas automatiquement les limites de Core 30 décrites plus haut aux versions suivantes : vérifie les règles de ton nœud. [2] [13]
Pourquoi certains portefeuilles affichent-ils encore un interrupteur RBF ? Les nœuds appliquant la politique initiale opt-in RBF exigeaient un signal préalable autorisant le remplacement. Bitcoin Core 24 a rendu full-RBF configurable sans cette condition, Core 28 l’a activé par défaut et Core 29 a supprimé l’option mempoolfullrbf. Les détails de BIP125 ci-dessous expliquent la signalisation initiale, pas une règle universelle de tous les nœuds actuels. BIP125 décrit un signal opt-in explicite lorsqu’au moins une entrée possède une valeur nSequence inférieure à 0xfffffffe, ainsi que l’héritage du signal d’un ancêtre non confirmé. Il s’agit d’une politique historique, pas d’une condition de consensus. Full-RBF permet d’évaluer un remplacement même sans ce signal ; son absence ne garantit pas qu’un paiement ne puisse être remplacé. [1] [3] [4] [5] [6]
Cette partie s’adresse aux personnes qui exploitent leur propre nœud. Les RPC sont des commandes permettant d’interroger ou de piloter le logiciel ; inutile de les connaître pour utiliser le bouton d’augmentation des frais. La RPC getmempoolentry indique l’état d’une transaction présente dans le mempool de ce nœud ; testmempoolaccept teste une seule transaction candidate de remplacement signée contre le mempool actuel et les règles de son propre nœud, sans la diffuser. Le résultat ne promet ni l’acceptation par les autres nœuds ni l’inclusion dans un bloc miné. Core 28 a activé full-RBF par défaut via mempoolfullrbf ; Core 29 a supprimé cette option. La RPC getmempoolinfo indique les paramètres de frais, mais le champ fullrbf est déclaré obsolète dans Core 30 ; vérifiez toujours la version et la configuration précises. [5] [6] [7] [8] [10] [11]
Pour une vision complète, lisez aussi Transaction Fees, Mempool, CPFP (Child Pays for Parent), Double dépense, Confirmation, Fee Rate. Cette entrée est également citée par Change Address, Confirmation, Double dépense, Fee Rate.