Qu’est-ce que opt-in RBF ?
Opt-in Replace-by-Fee (RBF) permet de signaler qu’une transaction est potentiellement ‘remplaçable’ jusqu’à sa confirmation dans un bloc.
Est-ce une nouvelle fonctionnalité ?
Le remplacement de transaction a été introduit par Satoshi dans la première version du logiciel Bitcoin, mais fut retiré ensuite à cause de risques de déni de service. Opt-in RBF a résolu ce problème en exigeant que le remplacement de transaction nécessite de payer des frais plus élevés.
À quoi cela sert-il ?
Durant la période où les transactions sont en attente de confirmation, certains portefeuilles souhaiteraient pouvoir modifier ces transactions afin d’augmenter le montant des frais (ceci afin d’obtenir une confirmation plus rapide), combiner plusieurs transactions en une seule, créer des ‘coinjoins’ en tâche de fond (pour améliorer la confidentialité), ou bien exécuter un certain nombre d’autres actions utiles.
Comment ça marche ?
Opt-in RBF modifie le code du ‘memory pool’ et du ‘network relay’ afin de permettre aux portefeuilles d’ajouter un indicateur optionnel signalant aux ‘full nodes’ que ces transactions peuvent potentiellement être modifiées (remplacées) tant qu’elles n’ont pas été confirmées dans un nouveau bloc.
L’implémentation de opt-in RBF augmente-t-elle les risques de double-dépense d’une transaction “non-RBF” ?
Non. Une transaction doit être marquée comme “remplaçable” (numéro de séquence inférieur à MAX-1) pour que l’implémentation de opt-in RBF puisse la traiter comme tel.
Opt-in RBF augmente-t-il de manière significative les chances de succès des dépenses frauduleuses ?
Opt-in RBF n’a aucun effet sur les transactions qui ne l’utilisent pas et personne n’est obligé de l’utiliser. Opt-in RBF n’a aucun effet une fois qu’une transaction a été confirmée. Cela signifie que les utilisateurs qui ont besoin de transactions non confirmées peuvent continuer à ne pas utiliser RBF.
Les transactions opt-in ne sont-elles pas un outil bien utile aux fraudeurs sachant qu’elles sont acceptées par certains sans confirmation ?
Nous n’avons aucun raison de penser qu’elles le soient pour le moment, du moins pas de manière significative en face de fraudeurs utilisant les outils et les techniques les plus efficaces du moment. Mais si c’est le cas (ou jusqu’à que l’on soit sûr que ce ne le soit plus) les destinataires des transactions peuvent se protéger en considérant que les transactions avec un numéro de séquence différent du maximum ne sont pas sûres tant qu’elles ne sont pas confirmées.
Les émetteurs qui utilisent opt-in RBF ayant la possibilité d’augmenter leurs frais de transaction et donc potentiellement réduire leur temps de confirmation même lorsqu’il y a beaucoup de transactions en attente de validation, il n’est pas inconsidéré d’exiger que leurs transactions aient été confirmées avant de leur fournir les services demandés.
Pourquoi les transactions non-confirmées sont-elles moins sûres ?
Les transactions Bitcoin sont relayées au travers d’un système distribué asynchrone où la notion de “premier” n’existe pas de manière constante. Ce qu’Alice a vu en premier, Bob le verra peut-être en second. Bitcoin tel qu’il a été conçu ne fournit pas à Alice et Bob de mécanisme leur permettant de se mettre d’accord pour savoir laquelle de ces transactions est effectivement arrivée en premier; tout ce qu’ils peuvent faire c’est d’attendre pour voir laquelle de ces transactions sera confirmée en premier dans un bloc valide de la meilleure blockchain.
Les auteurs d’attaques sophistiquées de type double-dépense utilisent aujourd’hui des outils pour cartographier la connectivité du réseau en effectuant des dépenses conflictuelles paraissant inoffensives, ils regardent ensuite quelles versions apparaissent chez quels marchands et dans quels blocs. Cela leur permet ensuite de préparer deux versions de la même transaction, une qui sera envoyée à la victime et l’autre aux mineurs pour confirmation.
La présence du paiement non-remplaçable à destination marchand empêche son nœud de découvrir la double-dépense jusqu’à ce qu’il apparaisse dans un bloc miné par un mineur qui a simplement miné ce qu’il a vu en premier. Ce scénario simple et basique est parfois encore amplifié par d’autres techniques telles que l’utilisation de chaînes de transactions non confirmées, des frais de transaction très bas, ou des transactions non-standard.
En conséquence, une grande partie de la sécurité des transactions non confirmées ne vient pas de l’intérieur du système Bitcoin, mais de facteurs externes tels qu’un grand nombre d’utilisateurs Bitcoin honnêtes qui ne serait jamais tenté de frauder leurs fournisseurs, une certaine tolérance de la part des vendeurs pour des petits montants de fraude, la capacité (ou la menace) des fournisseurs de recourir au système judiciaire ou d’autres types de recours, et d’autres facteurs qui n’ont rien à voir avec la conception du protocole Bitcoin.
Toutes ces choses sont également vraies pour opt-in RBF (et elles ne sont en rien différentes de ce qui se passe avec les paiements par carte de crédit aux États-Unis, qui sont facilement réversibles pendant des mois suivant la transaction et pourtant qui ont les taux de fraude suffisamment faible pour que la quasi-totalité des commerçants les acceptent). RBF pouvant parfois éliminer de longs retards de confirmation, certains commerçants qui, auparavant, se sentaient obligés d’accepter des transactions non confirmées pour éviter des retards préjudiciables ne seront plus obligés de le faire, ce qui réduira leur exposition à la fraude.
Cependant, aucun utilisateur d’opt-in RBF ne vous forcera à approuver le point du vue décrit ci-dessus concernant la sécurité des transactions non-confirmées. Opt-in RBF est opt-in, et si cela ne vous convient pas, vous n’êtes pas obligé de l’utiliser.
Qui a inventé le remplacement de transaction non-confirmée ? Cela ne va-t-il pas à l’encontre de la “vision originelle” de Bitcoin ?
Le remplacement des transactions non-confirmées était une fonctionnalité de la toute première version de Bitcoin. Les transactions pouvaient se désigner elles-mêmes comme “remplaçable” en définissant un numéro de séquence différent du maximum. Cette fonctionnalité fut désactivée plus tard car il était possible pour un attaquant de consommer toute la bande passante disponible entre les nœuds du réseau pour un coût minime, créant une vulnérabilité de déni-de-service.
En outre, il n’y avait aucune incitation pour les mineurs à respecter la convention et effectuer un remplacement, et il pouvait même y avoir une incitation à enfreindre la convention et à accepter un transaction plus ancienne si celle-ci incluait des frais de transaction plus élevés.
Ces deux raisons ont empêchés la réactivation du remplacement des transactions pendant plusieurs années, mais en 2013 Peter a proposé que les transactions de remplacement paient des frais strictement plus élevés et que l’augmentation soit au minimum ce qui serait requis pour relayer une nouvelle transaction. Ceci éliminait à la fois le déni-de-service et les problèmes de compatibilité des incitations pour les mineurs.
Le travail original de Peter est allé plus loin et a conduit la compatibilité d’incitation à sa conclusion logique, en déduisant que, avec des mineurs anonymes, éphémères, auto-sélectionnant(?) le seul comportement rationnel que vous pouvez réellement escompter est le remplacement par des transactions ayant des frais plus élevés. La préférence pour des frais plus élevés peut également permettre aux nœuds de converger sur un même ensemble de transactions dans le pool de mémoire basé sur le montant des frais, ce qui ne serait pas possible pour les nœuds qui acceptent la première version des transactions qu’ils voient uniquement.
Pour toutes ces raisons, et parce qu’un système se comportant de manière prévisible est plus sûr et plus protecteur qu’un système se comportant de manière “imprévisible mais meilleure on average ways”, il a proposé d’activer le remplacement pour toutes les transactions. Il a également proposé un protocole pour éliminer les gains économiques des double-dépenses d’une manière compatible avec une forte incitation, appelée remplacement de la terre brûlée (scorched earth), où si quelqu’un tente de vous double-dépenser, vous passez tous les fonds en frais de transaction de sorte que l’attaquant ne les reçoit pas. (Mais ceci est le genre de proposition que seul un théoricien des jeux pourrait vraiment aimer.)
Après la proposition de Peter, nous avons été sollicités par des gestionnaires de portefeuilles comme [Greenaddress] (https://blog.greenaddress.it/2015/12/09/why-replace-by-fee-is-good-for-bitcoin/) montrant un fort intérêt pour opt-in RBF. Ils ont en effet un vrai besoin de pouvoir gérer les frais de manière rationnelle. Opt-in RBF leur a semblé être une solution pertinente à leur probléme, c’est la raison pour laquelle la proposition a été modifiée pour correspondre au comportement d’opt-in original de Satoshi.
La pull-request opt-in RBF a-t-elle été controversée ?
Pas du tout. Après de longues discussions informelles remontant à plusieurs mois, la PR a été ouverte le 22 octobre. La PR a ensuite été abordée dans au moins quatre réunions hebdomadaires de développement Bitcoin (2015-11-05,2015-11-12, 2015-11-19, et 2015-11-26).
Dans la discussion de la PR, 19 personnes ont commenté (y compris des personnes travaillant sur au moins trois portefeuilles différents) et 14 personnes ont explicitement accepté (ACK) le changement, y compris au moins une personne qui s’était opposée de manière franche au full RBF. Aucun retour clairement négatif n’a été formulé dans la PR (ou ailleurs à notre connaissance) tant que la PR était ouverte.
Quand et comment cette fonctionnalité sera-t-elle activée ?
Opt-in RBF n’a pas vraiment “d’activation”, car il ne fait pas partie du consensus Bitcoin. C’est un comportement lié à la politique locale de sorte que la bascule s’effectue nœud après nœud, au moment où les gens adoptent un logiciel qui se comporte différemment. Il y a déjà quelques nœuds sur le réseau qui effectuent des RBF de diverses manières et il y en a eu depuis un certain temps déjà, probablement des années.
Bitcoin Core 0.12 devrait sortir aux alentours de Février 2016 et contiendra la fonctionnalité opt-in RBF. Il faudra probablement attendre au moins deux mois supplémentaires pour que le comportement devienne monnaie courante. Cela pourrait être accéléré par le développement d’applications faisant une utilisation intéressante de la fonctionnalité.
Opt-in RBF a-t-il pour seul intérêt la possibilité d’ajuster les frais de transaction ?
Non, une autre chose que peuvent faire les portefeuilles avec opt-in RBF est de combiner deux paiements en un seul si le premier n’a toujours pas été confirmé. Ceci peut économiser un grand nombre d’octets et de frais de transaction même si la transaction de remplacement devra payer des frais un peu plus élevés que l’originale.
Opt-in RBF peut aussi être utilisé pour implémenter des processus avancés de stabilité coopérative comme l’élimination de transaction (transaction cut-through).
Divers cas de [contrat intelligent (smart contract)] (https://bitcointalk.org/index.php?topic=321228.0) ont également besoin de remplacement, mais ils utilisent habituellement le locktime pour créer un ordonnancement plus fort et contourner l’indisponibilité historique du remplacement; ceux-ci étaient sans doute la motivation première du support du remplacement dans la conception originale du protocole Bitcoin.
Bien qu’étant intéressant pour bien d’autres raisons que le simple ajustement des frais, la possibilité d’ajuster les frais ne doit pas être sous-estimée. Cela signifie en effet que les frais initiaux peuvent se baser sur une estimation plus basse “très probable” au lieu d’avoir à payer plus cher “juste au cas où”; cela se traduit par des frais moins élevés même lorsque les remplacements sont plutôt rares.
Un portefeuille doit-il rester connecté afin de pouvoir effectuer des remplacements avec des frais plus élevés ?
Non. Les transactions de remplacement peuvent être pré-calculées, verrouillées dans le temps (time locked), et envoyées à un noeud connecté distant pour être diffusées plus tard avec aucun risque que le serveur puisse voler les fonds des utilisateurs (au pire il pourrait ne pas diffuser les transactions).
Par exemple. Au bloc 100 un portefeuille veut faire un ensemble de transactions qui devront être confirmées dans les 3 blocs. Le portefeuille crée une transaction verrouillé à 101 avec une estimation optimale des frais pour une confirmation dans trois blocs, dans le même temps il crée également des transactions de remplacement ‘locktimed’ pour les hauteurs 104, 105, 106, 107… chacune payant (disons) 1,5x les frais de la dernière. Celles-ci peuvent être remises à un nœud qui accepte les transaction avancées avec ‘locktime’.
Même si les mineurs savent que des frais plus élevés pourront être payés à l’avenir, de façon rationnelle, ils préfèrent encore ceux qu’ils peuvent inclure dès maintenant — puisque, si ils attendent, un autre mineur prendra probablement les frais à leur place. L’augmentation multiplicative suggérée plus haut signifie que, dans le pire des cas, une transaction serait surpayée de 50%, mais elle peut encore atteindre des frais arbitrairement élevées en quelques transactions.
Opt-in RBF augmente-t-il les risques pour les opérateurs de traitement de transactions “peu regardant” de se faire escroquer ?
Il ne semble pas que ce soit le cas, du moins pas de manière significative de par sa conception. Opt-In RBF se signale en utilisant le champ de numéro de séquence, un champ qui est spécifiquement destiné à gérer la ‘remplaçabilité’. De nombreux programmes et plates-formes faisant confiance aux transactions non confirmées considèrent déjà en général comme suspectes les transactions avec des numéros de séquence bas et les ignorent jusqu’à ce qu’elles soient confirmées.
Les transactions ont des dizaines d’autres moyens de modifier la vitesse ou la fiabilité de leur confirmation et d’accroître la probabilité d’un succès d’une double dépense frauduleuse :
– en sous-évaluant les frais de transaction
– en utilisant des ‘flags’ ou des versions non standards
– en dépensant des ‘inputs’ non confirmés
– en ayant un comportement correspondant à un certain nombre de schémas d’attaque par déni de service
– en créant une multitude d’outputs de très faible montant
– etc.
Ces critères changent souvent et dépendent de la politique spécifique de chaque nœud configurable par les utilisateurs. Les parties qui tentent d’estimer le risque d’un paiement non confirmé doivent surveiller tous ces points et même plus, ils doivent être proactifs et anticiper les changements. Opt-in RBF est une nouvelle fonctionnalité annoncée il y a plusieurs mois déjà qui se superpose à des comportements déjà détectés. Si il y a des amélioration à apporter à la vigilance concernant les transactions non-confirmées, c’est probablement noyé dans le bruit (it’s likely in the noise).
Au-delà de ça, il n’est pas certain qu’une transaction opt-in RBF sera plus efficace pour effectuer une double-dépense frauduleuse qu’une transaction non-RBF, du moment que l’attaquant est doté d’outils sophistiqués.
Certains tiers qui effectuent des mesures de confiance pour les transactions non-confirmées ont clairement indiqué qu’ils étaient prêts pour cela, si vous connaissez des logiciels qui aurait besoin d’aide pour s’adapter, faites le nous savoir, nous serons heureux de vous aider.
Et si je trouve que RBF est tout simplement horrible ?
Alors, ne l’utilisez pas : ne l’activez pas sur vos propres transactions et considérez les transactions que vous recevez avec tous les numéros de séquence inférieurs à MAX_INT-1 comme non-existantes (ou déjà double-dépensées) et attendez qu’elles soient confirmées. Opt-in RBF est, comme son nom l’indique, opt-in.
Aucun logiciel couramment utilisé dont nous avons connaissance ne définit ses numéros de séquence en-dessous de MAX_INT-1, et de nombreux programmes (y compris les indicateurs “confiance de transaction”) considèrent déjà les numéros de séquence faibles comme potentiellement double-dépensable. Après tout, la transaction a été marquée explicitement comme remplaçable, et même sans RBF, l’attribut nLocktime pourrait permettre à une transaction conflictuelle d’être confirmée en premier.
Si quelqu’un vous envoie une transaction remplaçable et que vous n’acceptez pas le zéro-conf, son remplacement pourra permettre une confirmation aussi rapide que souhaité. C’est déjà le cas pour les émetteurs qui utilisent des fonctionnalités non-standards des transactions ou qui dépensent des ‘outputs’ non confirmés, ce qui rend le risque de double dépense objectivement plus élevé—mais pour ces cas-là il n’y a pas de solution qui permette de faire passer la transaction plus rapidement.
RBF est une fonctionnalité pour adultes consentants. Si vous ne souhaitez pas y participer, vous n’y êtes pas obligé. Que vous ne l’aimiez pas n’est pas une raison pour empêcher les autres de l’utiliser pour des transactions qui ne vous concernent pas.
Pourquoi mettre en place ‘opt-in’ et ne pas laisser les mineurs remplacer n’importe quelle transaction ?
Rien n’empêche actuellement les mineurs de remplacer n’importe quelle transaction, même non opt-in, et certains mineurs ont déjà expérimenté RBF par eux-mêmes. En fournissant une implémentation standard répondant à la demande des utilisateurs pour cette fonctionnalité, il est possible que cela réduise l’incitation pour les mineurs à remplacer toutes les transactions par des variantes ayant des frais plus élevés.
J’ai entendu dire que Opt-in RBF avait été ajouté sans discussion préalable ou très peu, c’est vrai ?
Discussions récentes concernant RBF depuis mai 2015.
Github :
Ajout de la logique first-seen-safe replace-by-fee logic au mempool #6176
Déploiement planifié de full-RBF #6352
Opt-in full-RBF basé sur nSequence #6871
Réunions sur IRC :
2015-11-05
2015-11-12
2015-11-19
2015-11-26
Il y a beaucoup d’autres logs pour #bitcoin-dev et #bitcoin-core-dev.
Discussions sur la mailing-list sans aucun ordre particulier :
[bitcoin-dev] Opt-in Full Replace-By-Fee (Full-RBF)
[Bitcoin-development] First-Seen-Safe Replace-by-Fee
[Bitcoin-development] Réduction des coûts par l’utilisation de replace-by-fee, 30-90%
[bitcoin-dev] Pertes significatives causées par du double-spend de transactions non-confirmées
[bitcoin-dev] BIP: Planning de déploiement du ‘Full Replace-by-Fee’
[Bitcoin-development] replace-by-fee v0.10.0rc4
[bitcoin-dev] Comment les portefeuilles peuvent gérer les frais réels de transaction
Satoshi a introduit dès l’origine [le remplacement des transactions non confirmées] (https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434) mais la fonctionnalité a été désactivée en raison d’un risque d’attaque DOS (le problème a été réglé par Peter Todd en exigeant des frais plus élevés à chaque remplacement).
Opt-in RBF peut-il être utilisé pour effectuer des double-dépenses sur des anciennes versions de portefeuille ? Tous les portefeuilles devront-ils être mis à jour ?
Les transactions non confirmées peuvent toujours être double-dépénsées, avec ou sans RBF. La fraude est actuellement facile à réaliser, et RBF n’y change rien.
Les portefeuilles n’auront besoin d’être mis à jour que s’ils veulent faire usage de la fonctionnalité d’opt-in RBF. Cette fonctionnalité donne une nouvelle dimension aux portefeuilles qui leur permettra d’innover et d’offrir de nouvelles fonctionnalités utiles aux utilisateurs.
Pourquoi pas First-seen-safe Replace-by-fee (FSS-RBF) ?
SFS-RBF implique que les transactions ne peuvent être modifiées que si tous les ‘outputs’ précédents sont entièrement dépensés dans la nouvelle transaction. SFS-RBF empêche bien les double-dépenses, mais trois problèmes se posent quand il est effectivement utilisé :
Il en résulte une augmentation de la taille de la transaction car vous devez ajouter un nouvel ‘input’ à chaque remplacement. De nombreux portefeuilles peuvent ne pas avoir d’inputs disponibles à dépenser et ne peuvent donc simplement plus proposer FSS-RBF. La confidentialité s’en trouve diminuée car le montant de l’output de change sera augmenté quasiment à chaque fois, indiquant publiquement que cet output est celui du change.
Qu’est ce que “Child pays for parent” (CPFP) ?
L’enfant paie pour le parent est un moyen d’ajouter des frais à une transaction en créant une autre transaction qui dépend de la première.
Pourquoi CPFP n’a-t-il pas été utilisé pour RBF ?
L’enfant paie pour le parent (Child-pays-for-parent/CPFP) ne résout pas le même problème. RBF permet à l’émetteur d’augmenter les frais; CPFP est utile car il permet au destinataire d’augmenter les frais.
RBF a l’avantage par rapport à CPFP de ne pas nécessiter d’espace supplémentaire dans le bloc, de sorte qu’il est plus efficace d’environ [30% à 90%] (http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008232.html).
Il est prévu de supporter à la fois CPFP et opt-in RBF.
