CPFP ne modifie ni ne remplace la transaction parente non confirmée. Il ajoute un enfant dont les frais peuvent soutenir économiquement l’inclusion du parent dans un bloc. L’enfant exige que le parent soit confirmé auparavant ou placé avant lui dans le même bloc. Le résultat dépend du taux de frais combiné, de la possibilité de dépenser la sortie du parent, des règles du nœud et du choix du mineur.
CPFP conserve la transaction parente aux frais faibles et dépense sa sortie dans un enfant au taux de frais supérieur. Tant que le parent n’est pas confirmé, inclure l’enfant exige également le parent et les autres ancêtres non confirmés nécessaires. Le mineur peut ainsi percevoir leurs frais combinés ; il peut toutefois confirmer le parent seul, sans l’enfant. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
Pour une paire simple sans autres ancêtres non confirmés, additionnez les frais du parent et de l’enfant en satoshis, puis divisez par la somme de leurs tailles virtuelles en vB. Le résultat est un taux en sat/vB, pas un montant total de frais. Des frais plus élevés pour l’enfant ne sont utiles que si le taux combiné est compétitif ; les autres ancêtres nécessaires modifient le calcul. L’acceptation locale de paquets ne recompte pas les transactions déjà présentes dans le mempool et peut utiliser des frais modifiés ; sa valeur ne correspond donc pas toujours à ce calcul simplifié du point de vue du mineur. [Bitcoin Core v31.0 — Package mempool acceptance]
Un CPFP ordinaire exige de pouvoir dépenser au moins une sortie du parent. L’expéditeur peut utiliser la sortie de monnaie rendue, appelée change ; le destinataire peut utiliser sa sortie de paiement. Il faut satisfaire les conditions de dépense, y compris les signatures requises. Le simple fait d’afficher ou d’examiner une sortie ne donne pas cette autorisation. [Bitcoin Developer Guide — Transactions]
RBF crée un remplacement conflictuel partageant au moins une entrée dépensée avec la transaction initiale ; l’ensemble complet des entrées ne doit pas nécessairement être identique. CPFP conserve le parent et ajoute un enfant. RBF exige de satisfaire les conditions des entrées du remplacement ; un CPFP ordinaire exige celles de dépense de la sortie du parent. Ce sont des modifications différentes du graphe des transactions. [Bitcoin Core v31.0 — Package mempool acceptance]
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. [Bitcoin Core v31.0 — Package mempool acceptance] [Bitcoin Developer Guide — Transactions]
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. [Bitcoin Core 26.0 release notes] [Bitcoin Core 31.0 release notes]
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 une violation des règles de standardité peut bloquer CPFP même avec des frais suffisants. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Package mempool acceptance]
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. [Bitcoin Core 31.0 release notes] [Bitcoin Core v31.0 — Mempool terminology]
Un taux combiné compétitif peut augmenter la probabilité de confirmation, mais ne réserve pas une place dans le prochain bloc. La demande d’espace de bloc, la propagation des transactions et les choix du mineur concerné peuvent évoluer. CPFP est un outil pour renforcer l’incitation par les frais, pas une garantie du délai de confirmation. [Bitcoin Core v31.0 — Package mempool acceptance]
Dans Core 31, la RPC getmempoolentry indique 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érifiez les résultats de chaque transaction, la version et la configuration ; aucun résultat ne garantit l’inclusion dans un bloc miné. [Bitcoin Core 31.0 release notes] [Bitcoin Core 31.0 — getmempoolentry RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core 31.0 — submitpackage RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]
Pour une vision complète, lisez aussi Replace-by-Fee (RBF), Frais de transaction, Fee Rate, Mempool, Transaction, UTXO. Cette entrée est également citée par Sortie de monnaie, Confirmation, Double dépense, Fee Rate.