CPFP (Child-Pays-For-Parent)

Le problème à résoudre

Vous envoyez une transaction Bitcoin avec un fee rate trop bas. Elle reste bloquée dans le mempool des heures, parfois des jours. Si vous n'avez pas activé RBF, impossible de la remplacer. Mais vous pouvez encore l'accélérer en jouant sur sa descendance : c'est tout l'intérêt de CPFP, pour Child-Pays-For-Parent (« l'enfant paie pour le parent »).

Comment CPFP fonctionne

Le principe repose sur la façon dont les mineurs sélectionnent les transactions. Lorsqu'un mineur évalue une transaction, il ne regarde pas seulement son fee rate individuel, mais celui de tout le paquet (parent + enfant non confirmés). Si l'enfant paie des frais très élevés, le fee rate moyen du paquet remonte, et le mineur sera incité à miner les deux ensemble. Concrètement :

1. La transaction parente est coincée à 1 sat/vB.
2. Vous créez une nouvelle transaction qui dépense un output de cette parente, avec un fee rate très élevé (par exemple 50 sats/vB).
3. Le mineur, voyant le paquet, calcule un fee rate combiné attractif et inclut les deux dans le même bloc.

Différences avec RBF

| | RBF | CPFP | |---|---|---| | Modifie la transaction d'origine ? | Oui | Non | | Nécessite signal opt-in ? | Oui (sauf full-RBF) | Non | | Qui peut l'activer ? | L'émetteur uniquement | L'émetteur ou le destinataire | | Coût en taille | Réécriture de la tx | Une tx supplémentaire |

CPFP est donc particulièrement utile au destinataire d'un paiement bloqué : il peut décider d'accélérer une transaction qu'il n'a pas émise lui-même, simplement en dépensant le change ou l'output qui lui était destiné.

Limites et pièges

CPFP ne fonctionne que si l'output est dépensable (pas verrouillé par un timelock) et si la politique de votre nœud accepte le « package relay », pleinement supporté depuis Bitcoin Core 28 (2024). Avant cela, les ancêtres non confirmés posaient parfois problème. Autre limite : le coût total peut s'avérer plus élevé qu'un RBF bien conçu, puisqu'on paie deux transactions.

À retenir

CPFP et RBF ne s'opposent pas, ils se complètent. Lightning Network s'appuie même fortement sur CPFP (via anchor outputs) pour les transactions de force-close. À connaître absolument pour gérer une transaction bloquée en période de congestion.