zéro confirmation : Quelles sont les restrictions à l'application de l'opt-in RBF ?
BIP-125 : Signalisation de remplacement complet par frais (RBF) opt-in spécifie comment déclarer les transactions remplaçables jusqu’à ce qu’elles soient confirmées dans un bloc. La remplaçabilité est indiquée par le champ du numéro de séquence qui apparaît dans chaque entrée de transaction. Une transaction est remplaçable si au moins un numéro de séquence dans la transaction est inférieur à MAX-1.
La signification des valeurs de numéro de séquence :
- MAX : la transaction est définitive
- MAX-1 : la transaction utilise le temps de verrouillage
- MAX-2 ou inférieur : la transaction est remplaçable
Un dépensier peut écraser une transaction remplaçable par un transaction à taux plus élevé avant qu’il ne soit confirmé. Le tarif doit augmenter d’au moins minRelayTxFeeRate (actuellement 1 sat/vB). Si la transaction remplacée a des transactions descendantes, le remplacement doit payer plus de frais que toutes les transactions remplacées. Lorsqu’une transaction est remplacée, la mise à jour de la transaction peut exclure les futurs remplacements en réglant tous les numéros de séquence sur une valeur finale, c’est-à-dire MAX-1 ou MAX.
Bitcoin Core v0.12.0 et les versions ultérieures permettront le remplacement selon la description ci-dessus, mais ne créeront pas de transactions RBF opt-in par défaut. Depuis la v0.16.0, les transactions seront étiquetées comme remplaçables par défaut.
Comment l’opt-in RBF interagit-il avec les transactions non confirmées ?
- Les transactions finales (régulières) avec un numéro de séquence MAX-1 ou MAX ne sont pas affectées. Les nœuds qui implémentent le RBF opt-in les traitent exactement comme avant. Les transactions conflictuelles des transactions finales sont toujours traitées selon le paradigme de la première vue et ne sont pas ajoutées au mempool ou relayées même lorsqu’elles paient des frais plus élevés
- Les transactions non finales (RBF) signalent explicitement qu’elles ne doivent pas être acceptées avant confirmation. Bitcoin Core créera la transaction finale par défaut
Quelle influence cela a-t-il sur le traitement des paiements sans confirmation ?
Les utilisateurs obtiennent un nouveau type de transaction supplémentaire qui signale explicitement qu’elle ne doit pas être acceptée sans confirmation.
Les développeurs de portefeuilles doivent :
- Masquer les transactions RBF avant la confirmation
- Indiquer le statut remplaçable des transactions RBF et avertir l’utilisateur qu’elles ne sont fiables qu’après confirmation
L’acceptation de transactions finales (qui ne signalent pas la remplaçabilité) sans confirmation présente exactement les mêmes considérations de risque qu’avant l’introduction du RBF opt-in.
Notez que depuis Bitcoin Core v24.0.1, les opérateurs de nœuds peuvent choisir d’exécuter mempoolfullrbf=1 qui traitera toutes les transactions de leur mempool comme remplaçables, qu’elles aient signalé ou non une remplaçabilité.
vous pourriez être intéressé par cette étude sur l’adoption RBF de divers portefeuilles par le groupe Bitcoin Optech.
