Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07205.jsonl.gz/14

Dans cet article technique, nous allons examiner comment nous pouvons accélérer une transaction qui a déjà été envoyée mais qui est restée en attente dans le mempool depuis longtemps. Dans ce cas, en fait, cela signifie qu’aucun mineur n’a encore saisi la transaction dans son bloc miné. Cela se produit généralement parce que vous définissez des frais trop bas pour la transaction ou parce que les frais augmentent soudainement immédiatement après l’arrivée de votre transaction dans le mempool (il est conseillé d’utiliser un explorateur pour voir le statut des frais et du mempool, par exemple avec le bot telegram @btcnode_bot).
Voyons maintenant comment nous pouvons résoudre efficacement la situation. Il est important de noter que tant que la transaction n’est pas écrite sur la blockchain, elle ne peut être considérée comme efficace et valable. Vous devez attendre la première confirmation, puis les suivantes.
Double spend & RBF
Que signifie “double spend” ? Cela signifie produire deux transactions qui dépensent les mêmes UXTOs. Formellement rien ne vous empêche de faire cela. La question est la suivante: “Que fait un nœud s’il voit deux tx de double dépense ?
Vous ne savez pas, parce que vous ne contrôlez pas les nœuds des autres. Par défaut, ils doivent accepter le premier et rejeter les autres, mais ils n’ont aucun moyen de faire respecter ces règles. Avec RBF (replace by fee), vous pouvez aller remplacer une TX qui est déjà dans mempool. Comme les nœuds rejettent par défaut les doubles dépenses, le RBF a été inventé pour “dire” aux nœuds que vous envoyez une TX et que vous pourriez devoir augmenter les frais. En gros, les nœuds acceptent que vous augmentiez les frais.
Mais comme vous n’avez aucun contrôle sur les nœuds, vous ne savez pas quel TX entrera. Ce sont les nœuds des mineurs qui décident du TX à laisser entrer dans le bloc. Les nœuds qui acceptent le RBF admettent qu’une tx ultérieure avec des frais plus élevés remplacera celle qu’ils ont déjà reçue dans le mempool. RBF doit etre défi par l’expéditeur et ce dernier peut augmenter les frais avant que la transaction ne soit confirmée, par exemple via electrum (wallet)[¹] qui prend en charge cette fonction.
Utiliser la méthode CPFP
C’est un acronyme pour “child pays for parents“. Ce n’est pas une caractéristique, mais cela fait partie du système économique de bitcoin. Fondamentalement, lorsque les mineurs décident de la TX à inclure, ils agissent comme un tout. Ils incluront donc volontiers une transaction à frais élevés même si elle est le résultat d’une transaction à frais faibles[²]. Si la moyenne des frais est supérieure à la valeur actuelle des frais, ils accepteront d’inclure les deux transactions. Voyons comment les appliquer dans les deux situations où vous êtes soit l’expéditeur de la transaction, soit le destinataire de la transaction.
CPFP si vous êtes le bénéficiaire
Pour ce faire, si vous êtes le destinataire, vous pouvez créer une nouvelle transaction, en utilisant l’UTXO reçu (ou l’un de ceux reçus) pour construire une nouvelle transaction pour vous-même (à votre adresse) avec des frais tels que la moyenne avec les frais précédents est plus élevée que les frais actuels par transaction. De cette manière, les deux seront rapidement vérifiés.
CPFP Si vous êtes l’expéditeur de la transaction
Si vous êtes l’expéditeur, vous pouvez toujours utiliser cette méthode, voici comment. Dans la transaction que vous avez envoyée, il y a presque certainement un reste. Prenez alors l’UXTO lié au reste et utilisez-le pour vous constituer une nouvelle transaction à des frais très élevés.
Comme vous avez pu le voir dans cet article, il est donc possible et aussi très simple d’accélérer une transaction qui se trouve dans le mempool depuis longtemps. Nous avons vu comment il est possible de le faire avec les deux techniques les plus utilisées. J’espère vous avoir été utile et avoir apporté une valeur ajoutée. Je reste à votre disposition.
Notes:
[¹] electrum est un portefeuille bitcoin très efficace et utilisé
[²] une transaction ne peut être confirmée sans que le parent ne soit confirmé, car une transaction de fille n’existe pas si le parent n’existe pas.