RBF et CPFP Bitcoin : augmenter les frais bloqués

Une transaction Bitcoin non confirmée ne devient pas prioritaire parce que l’on envoie un second paiement ou que l’on ajoute des frais au hasard. Il faut d’abord savoir qui contrôle les entrées ou les sorties concernées, quelle politique de mempool appliquent les nœuds et quel feerate intéresse actuellement les mineurs. RBF et CPFP Bitcoin sont les deux méthodes usuelles : Replace-by-Fee remplace la transaction, tandis que Child Pays for Parent crée un enfant fortement rémunéré afin de rendre l’ensemble attractif.

Cette méthode suppose que la transaction est valide, toujours non confirmée et retardée par des frais trop faibles. Commencez par vérifier son txid, ses frais absolus, sa taille virtuelle, son feerate, ses entrées et ses sorties avec le wallet, votre nœud ou un explorateur indépendant. Notre guide des frais Bitcoin explique pourquoi les sat/vB et l’espace de bloc comptent, non le montant transféré.

RBF et CPFP Bitcoin : la différence essentielle

RBF construit une nouvelle transaction qui dépense au moins une entrée identique à l’originale et verse des frais suffisamment supérieurs. Les deux transactions sont en conflit. Un nœud qui accepte le remplacement retire l’ancienne de son mempool puis relaie la nouvelle. Le remplacement possède un autre txid ; ses sorties et la monnaie rendue peuvent également changer. Il ne modifie pas les octets de la transaction initiale.

CPFP laisse le parent intact. Le détenteur d’une sortie non confirmée la dépense dans un enfant assorti de frais élevés. Un mineur ne peut confirmer l’enfant sans inclure le parent avant lui : il peut donc juger leur rémunération combinée. CPFP est souvent accessible au destinataire, ou à l’expéditeur lorsque le parent a créé une sortie de change qu’il contrôle.

Opt-in RBF, full RBF et champ nSequence

RBF relève de la politique de mempool et de relais, pas des règles de consensus de Bitcoin. Dans l’opt-in RBF décrit par le BIP125, une transaction signale explicitement qu’elle est remplaçable lorsqu’au moins une entrée porte un nSequence inférieur à 0xfffffffe. Une valeur inférieure à 0xffffffff permet aussi l’usage de nLockTime ; certaines valeurs encodent des verrouillages relatifs BIP68. Il ne faut donc pas les modifier manuellement sans en comprendre les effets.

Opt-in ne protège pas une transaction sans signal contre la double dépense. Il annonce seulement qu’un remplacement conforme peut être examiné. Avec full RBF, un nœud peut le faire sans signal. Prise en charge et relais varient selon logiciel, version et configuration ; deux pairs peuvent donc avoir des mempools différents.

Les règles de frais d’un remplacement

Afficher davantage de sat/vB ne suffit pas. Les politiques issues du BIP125 appliquent des protections contre le spam et le déni de service. En pratique, la candidate doit entrer en conflit avec une transaction présente dans le mempool du nœud ; payer au moins la somme des frais absolus des transactions qu’elle fait évincer ; puis ajouter assez de frais pour financer le relais de ses propres octets au taux incremental relay fee. Une hausse minime du feerate peut donc échouer si le remplacement est plus grand ou évince des descendants.

Les règles classiques limitent les nouvelles entrées non confirmées et plafonnent les évictions, souvent à 100 transactions avec descendants. Les implémentations peuvent appliquer des variantes suivies par le dossier RBF de Bitcoin Optech. L’acceptation par un explorateur ne contraint personne d’autre.

CPFP et calcul du feerate du package

CPFP exploite la dépendance entre transactions. L’enfant dépense une sortie non confirmée du parent ; le mineur doit donc inclure les deux dans l’ordre. Pour un couple simple, le feerate économique vaut (frais parent + frais enfant) / (vsize parent + vsize enfant). Ce n’est pas la moyenne arithmétique de leurs deux feerates.

Imaginons un parent de 200 vB qui paie 1 000 sat, soit 5 sat/vB. Vous visez un package à 30 sat/vB avec un enfant de 110 vB. Les frais totaux requis sont 30 × 310 = 9 300 sat. Le parent fournissant déjà 1 000 sat, l’enfant doit payer environ 8 300 sat, donc plus de 75 sat/vB. Fixer simplement l’enfant à 30 sat/vB ne compenserait pas le déficit du parent.

Avec d’autres ancêtres, incluez tout ce que le mineur devra confirmer. L’enfant doit franchir le minimum de relais et respecter la politique de chaîne. Des limites Bitcoin Core historiquement courantes sont 25 transactions et 101 000 virtual bytes, mais les réglages diffèrent. Voir CPFP de Bitcoin Optech.

Contrôle de l’expéditeur, du destinataire et du change

L’expéditeur peut employer RBF uniquement si son wallet contrôle les entrées d’origine, reconnaît la transaction en attente et sait construire un remplacement valide. Lors d’un retrait depuis un exchange custodial, le client ne possède pas ce contrôle : seul l’exchange peut remplacer sa transaction. Ajouter un txid dans un wallet en lecture seule n’importe aucune clé privée.

Le destinataire peut faire un CPFP si son wallet autorise la dépense de la sortie reçue avant confirmation. Certains logiciels masquent ces pièces, bloquent leur dépense ou n’offrent pas de coin control. L’expéditeur peut utiliser son change si le parent en a créé un, si le wallet le reconnaît et si sa valeur finance les frais sans produire une sortie dust ou économiquement absurde.

Le destinataire ne peut pas faire un RBF sur le paiement d’autrui au seul motif qu’il possède une sortie ; l’expéditeur ne peut pas faire un CPFP sans change. Notre explication des UTXO Bitcoin détaille cette structure.

Tableau de décision : RBF, CPFP ou attendre

Quand les deux méthodes fonctionnent, RBF coûte souvent moins cher puisqu’il n’ajoute pas d’enfant. CPFP sert lorsque le destinataire contrôle la sortie utile ou que le remplacement est impossible. Attendre reste rationnel, mais une transaction sous le minimum de relais peut disparaître.

Scénario pratique avec chiffres et contraintes

Alice envoie 0,01 BTC à Bob. La transaction mesure 180 vB, paie 1 800 sat (10 sat/vB) et signale opt-in RBF. La demande augmente ensuite et les mineurs sélectionnent autour de 35 sat/vB. Pressée, Alice reçoit de son wallet une proposition de remplacement : 185 vB à 40 sat/vB, soit 7 400 sat. Elle vérifie la sortie de Bob, le montant, le change et les frais avant de signer. La nouvelle transaction dépense une entrée conflictuelle et obtient un nouveau txid.

Si Alice n’agit pas, Bob peut dépenser sa sortie avec un enfant de 120 vB. Parent et enfant totalisent 300 vB. Pour atteindre 40 sat/vB, le package doit payer 12 000 sat ; les 1 800 sat du parent laissent environ 10 200 sat à la charge de l’enfant. Bob doit disposer d’une sortie assez grande et d’un wallet autorisant la dépense non confirmée.

Le calcul change si le parent possède d’autres ancêtres sous-rémunérés. Il change aussi si Alice a déjà dépensé son change : ces descendants peuvent être évincés par RBF et relever le seuil exigé. Les deux parties doivent contrôler la propagation auprès de sources indépendantes. La présence dans l’explorateur du wallet ne prouve que la connaissance de ce service.

Workflow du wallet sans double paiement

1. Confirmez que la transaction est toujours non confirmée et relevez le bon txid. RBF et CPFP ne modifient jamais une transaction déjà minée.
2. Examinez frais, vsize, feerate, entrées, sorties, ancêtres et descendants. Ne confondez pas montant envoyé et frais de minage.
3. Choisissez un feerate adapté à l’urgence à partir de plusieurs estimateurs ou de votre nœud. La cible « prochain bloc » est volontairement coûteuse.
4. Pour RBF, utilisez la fonction native d’augmentation ou un RPC pris en charge comme bumpfee de Bitcoin Core. Ne créez pas un paiement indépendant.
5. Sur l’appareil de signature, vérifiez destination, montant, change, frais absolus et feerate. Le supplément provient souvent d’une réduction du change.
6. Pour CPFP, sélectionnez explicitement la sortie du parent avec coin control. Calculez le package complet et laissez une sortie finale non dust.
7. Après diffusion, vérifiez le remplacement ou le couple parent-enfant via plusieurs sources. Conservez les deux txid.

Un hardware wallet peut n’afficher que la nouvelle transaction, sans expliquer son lien avec l’ancienne. Comparez chaque sortie au lieu de croire l’étiquette « fee bump ». La checklist d’envoi crypto complète le contrôle de l’adresse et du réseau.

Risques et limites masqués par l’interface

Une estimation agressive peut provoquer un fort surpaiement. Changer sorties ou txid peut aussi perturber comptabilité et services qui ne suivent que l’identifiant initial. Une attente zéro confirmation reste provisoire.

Des remplacements concurrents peuvent se propager dans des zones différentes du réseau. L’originale peut encore être minée en premier par un acteur qui n’a jamais reçu ou accepté sa concurrente. CPFP peut échouer si le mineur n’évalue pas le package prévu, si un ancêtre manque, si la chaîne dépasse les limites ou si l’enfant ne se relaie pas.

Pinning et griefing peuvent permettre à une contrepartie de rendre le remplacement coûteux ou incompatible avec les politiques. Les évolutions du relais réduisent certains vecteurs sans garantir le résultat. Les sommes élevées justifient un wallet avancé et, idéalement, un nœud propre.

Erreurs fréquentes à éviter

• Renvoyer le paiement : deux transactions indépendantes peuvent être confirmées. Un vrai RBF entre en conflit sur les entrées.
• Observer seulement les sat/vB de l’enfant : CPFP dépend du feerate agrégé de tous les ancêtres requis.
• Prendre non-RBF pour final : full RBF et d’autres doubles dépenses restent possibles avant confirmation.
• Ajouter le minimum : frais absolus, incremental relay fee, conflits et évictions comptent simultanément.
• Dépenser le change sans le savoir : les descendants compliquent le remplacement et peuvent disparaître du mempool.
• Donner sa seed à un accélérateur : aucun service légitime de relais ou de minage n’a besoin des clés privées.
• Confondre rebroadcast et bump : rediffuser les mêmes octets ne change ni frais ni priorité économique.

Checklist finale et conclusion

• La transaction est-elle réellement non confirmée ?
• Contrôlez-vous les entrées pour RBF ou une sortie pour CPFP ?
• Signale-t-elle opt-in RBF et avez-vous envisagé full RBF ?
• Avez-vous calculé frais absolus, vsize et feerate ?
• Pour CPFP, tous les ancêtres nécessaires sont-ils inclus ?
• Le remplacement franchit-il les seuils et limites du mempool ?
• Avez-vous vérifié destination, montant, change et nouveau txid ?
• L’urgence justifie-t-elle ce prix, ou vaut-il mieux attendre ?

RBF et CPFP Bitcoin abordent le même retard depuis deux positions. RBF est généralement l’outil de l’expéditeur et remplace la transaction. CPFP appartient à celui qui contrôle une sortie et rémunère le package. La bonne décision dépend des clés, de la structure UTXO, de la politique des nœuds et d’un calcul complet. Si une donnée manque, diagnostiquer et patienter est plus sûr que signer à l’aveugle.

Sources techniques officielles

• BIP125 — Opt-in Full Replace-by-Fee Signaling
• Bitcoin Core — RPC bumpfee
• Bitcoin Optech — Replace-by-Fee
• Bitcoin Optech — Child Pays for Parent