Imagine que quelqu’un t’a envoyé du bitcoin avec peu de frais et que le paiement n’est toujours pas confirmé. Si ton portefeuille permet d’utiliser CPFP pour ce paiement, tu peux créer une transaction qui en dépend, par exemple vers une autre de tes adresses. L’originale est appelée parent et la nouvelle, enfant : l’enfant dépense une sortie, c’est-à-dire un montant assorti de conditions de dépense, créé par le parent. Pour percevoir les frais de l’enfant, le mineur a aussi besoin du parent. Le paiement original reste inchangé ; proposer davantage de frais peut aider sa confirmation, sans en garantir le délai.
Anna attend 100 000 sat. L’abréviation sat désigne le satoshi, la plus petite unité de bitcoin. Elle voit déjà le paiement, mais l’expéditeur a choisi de faibles frais et il ne figure pas encore dans un bloc. Son portefeuille permet de dépenser cette sortie non confirmée. Anna s’en sert pour créer une transaction vers sa propre adresse, avec des frais plus élevés. Elle ne paie ni l’expéditeur ni un service particulier : ce sont des frais de transaction Bitcoin ordinaires. Un mineur ne peut pas confirmer cette nouvelle transaction sans l’originale, car la sortie qu’elle dépense manquerait dans la chaîne en cours de validation. Le parent doit avoir été confirmé auparavant ou figurer avant l’enfant dans le même bloc, avec les autres ancêtres non confirmés nécessaires. La réciproque est fausse : le parent peut être confirmé sans l’enfant. [3] [5]
Prenons un exemple simple, sans autre ancêtre non confirmé. Le parent mesure 200 vB et paie 200 sat. L’octet virtuel, vB, mesure une taille dérivée du poids de la transaction ; sat/vB indique les satoshis proposés par unité. L’enfant mesure 100 vB et Anna paie 2 800 sat pour lui. S’il ne comporte qu’une sortie, il lui reste 97 200 sat sur les 100 000 sat reçus. Ensemble, les transactions paient 3 000 sat pour 300 vB, soit 10 sat/vB. L’enfant seul propose 28 sat/vB, mais le mineur doit aussi inclure le parent peu rémunérateur. Regarder uniquement le chiffre élevé de l’enfant fait oublier cette dépendance. Ce calcul illustre le principe, ce n’est pas un tarif conseillé pour aujourd’hui ; le portefeuille vérifie les tailles réelles et les frais totaux nécessaires. D’autres ancêtres nécessaires changeraient le calcul. Un détail avancé : lors de l’acceptation locale d’un paquet, les transactions déjà acceptées ne sont pas comptées une seconde fois, et le nœud — un programme qui vérifie et relaie les transactions — peut utiliser des frais modifiés. Le taux affiché dans ce contexte ne correspond donc pas forcément au simple calcul commun pour un mineur. Ces frais modifiés sont une valeur locale utilisée pour les décisions du nœud ; ils ne changent pas les frais réellement payés par la transaction. [3]
CPFP n’est pas un bouton permettant à n’importe qui d’accélérer une transaction d’autrui. Il faut pouvoir dépenser une sortie du parent et remplir ses conditions, signatures comprises. Anna le peut en tant que destinataire ; l’expéditeur peut parfois utiliser une sortie qui lui rend le montant restant, appelée change. Voir une somme dans un explorateur ou un Watch-only Wallet ne suffit pas. Un Watch-only Wallet permet de suivre les paiements, mais ne contient pas lui-même les clés privées nécessaires pour dépenser les fonds. Le portefeuille doit aussi permettre de dépenser la sortie non confirmée. Avant de signer, vérifie quelle sortie tu dépenses, où ira l’argent, combien il restera et quels seront les frais totaux. Pour une petite sortie, les frais peuvent absorber une part importante de sa valeur. [5]
Replace-by-Fee (RBF) crée une nouvelle transaction concurrente destinée à remplacer l’originale. Elle dépense au moins une même entrée, sans devoir reprendre exactement toutes les entrées. CPFP conserve au contraire le paiement original et son identifiant, puis ajoute une transaction. Pour RBF, il faut remplir les conditions des entrées de la transaction de remplacement ; pour un CPFP ordinaire, celles d’une sortie du paiement original. Le destinataire peut donc parfois utiliser CPFP sans pouvoir signer le remplacement de l’expéditeur. Envoyer un autre paiement indépendant avec beaucoup de frais ne sert à rien : l’enfant doit réellement dépendre du paiement en attente. [3]
Un taux de frais commun plus élevé donne au mineur une meilleure raison de prendre les deux transactions, mais ne réserve aucune place dans le prochain bloc. Des transactions plus rémunératrices peuvent arriver, ou certains mineurs peuvent ne pas recevoir le paquet. Suis donc les confirmations du paiement original et de l’enfant. L’acceptation annoncée par un nœud n’est pas encore une confirmation dans un bloc. Si l’expéditeur remplace le paiement original par RBF, l’enfant qui référence son ancienne sortie ne peut pas se rattacher tout seul à la nouvelle transaction, différente : il faudra réexaminer la situation. Créer un enfant ne transforme pas non plus une réception non confirmée en paiement acquis. [3]
Les sections suivantes approfondissent les règles et le fonctionnement d’un nœud personnel. Le Mempool est la liste des transactions en attente d’un nœud donné, pas une file unique pour tout le réseau. Un paquet est un groupe de transactions présenté ensemble. Il faut distinguer trois décisions : la transaction est-elle valide, le nœud l’accepte-t-il et un mineur la sélectionne-t-il ? Le consensus détermine la validité des transactions et des blocs. La politique du mempool détermine l’acceptation locale et la propagation ; les règles du mineur déterminent la sélection pour le bloc candidat. CPFP ne modifie pas le consensus. Un paquet économiquement intéressant peut ne pas respecter les règles locales, et son acceptation par un nœud n’engage ni les autres nœuds ni les mineurs. [3] [5]
Les moyens de transmettre ensemble parent et enfant évoluent. Package CPFP désigne l’évaluation de transactions liées en tant que paquet. Un RPC est une commande pour interagir avec le nœud ; minrelaytxfee désigne son taux minimal pour la propagation ordinaire. TRUC est un régime particulier de transactions limitant les relations entre ancêtres et descendants. L’historique ci-dessous concerne les versions indiquées de Bitcoin Core. Bitcoin Core 26 a ajouté la RPC submitpackage et le CPFP par paquet : l’enfant pouvait aider un parent situé sous le taux minimal dynamique du mempool, mais pas, à l’époque, sous le taux minimal de relais. Cette restriction n’est pas intemporelle. Core 31 autorise, pour le paquet de relais pris en charge composé d’un parent et d’un enfant, un parent sous minrelaytxfee, y compris sans frais, également hors TRUC ; les autres parents non confirmés de l’enfant doivent déjà être dans le mempool. L’acceptation locale ne garantit toujours pas une propagation identique dans tout le réseau. [1] [2]
Un nœud ne peut pas accepter des réseaux de dépendances de taille illimitée. Un ancêtre est nécessaire avant une autre transaction ; un descendant dépense des sorties plus loin dans cette chaîne de dépendances. WU désigne les unités de poids d’une transaction, et la topologie décrit leurs liens. Ces limites techniques relèvent de la politique de la version du nœud concernée. Les limites protègent la mémoire, le processeur et la capacité de transmission. Les anciennes versions de Core limitaient le nombre et la taille des ancêtres et descendants ; Core 31 a remplacé ces limites du mempool par celles des clusters connectés. Les limites propres aux paquets subsistent : la documentation de Core 31 indique au plus 25 transactions et un poids total de 404000 WU. Le poids n’est pas la taille virtuelle. Une topologie incorrecte, un conflit ou le non-respect des règles locales sur les formes de transactions acceptées (standardness) peut bloquer CPFP même avec des frais suffisants. [2] [3]
Des transactions en attente liées entre elles ne peuvent pas toujours être évaluées économiquement séparément. Cluster Mempool permet au nœud d’examiner des groupes connectés. Un cluster est le groupe connecté complet ; un chunk est un groupe plus petit traité lors de la sélection des transactions. Il ne s’agit pas de morceaux de blocs déjà confirmés. Bitcoin Core 31 utilise Cluster Mempool : un cluster regroupe les transactions connectées par des relations parent-enfant dans n’importe quel sens. Les limites par défaut sont de 64 transactions et de 101 kB de taille virtuelle par cluster ; elles sont configurables. L’ordre tient compte de groupes minés ensemble, appelés chunks, et de leurs taux de frais. L’ancien CPFP carveout autorisait une exception limitée au plafond de descendants ; Core 31 l’a supprimé, et cette méthode ne permet donc pas de contourner la limite du nombre de transactions d’un cluster. [2] [4]
Les commandes de cette section ne sont pas interchangeables. Un test peut se limiter à décrire un résultat ; soumettre un paquet peut réellement faire accepter et propager des transactions signées. Le champ vsize donne la taille virtuelle. Un portefeuille courant peut gérer ces détails pour son utilisateur. Dans Core 31, la RPC getmempoolentry indique, pour une transaction présente dans le mempool de ce nœud, les frais, vsize, les dépendances et les informations sur le chunk ; getmempoolcluster affiche le cluster associé. La RPC testmempoolaccept effectue un test local sans acceptation ni diffusion ; pour plusieurs transactions, les ancêtres doivent précéder les descendants, et les transactions ne doivent entrer en conflit ni entre elles ni avec le mempool. La RPC submitpackage soumet réellement un paquet pris en charge à l’acceptation dans le mempool et à la propagation ; ce n’est pas seulement un test. Vérifie les résultats de chaque transaction, la version et la configuration ; aucun résultat ne garantit l’inclusion dans un bloc miné. [2] [6] [7] [8] [9]
Pour une vision complète, lisez aussi Replace-by-Fee (RBF), Transaction Fees, Fee Rate, Mempool, Transaction, UTXO. Cette entrée est également citée par Change Address, Confirmation, Double dépense, Fee Rate.