Filtre de Bloom

La conception échangeait de la bande passante contre ce que ses auteurs espéraient être de la confidentialité, et cette confidentialité n'est jamais venue. Bitcoin Core a cessé de servir ces filtres par défaut dans la version 0.19.0, publiée en novembre 2019, après des années de recherche montrant à quel point ils divulguent d'informations. Un portefeuille qui s'appuie encore sur un tel filtre remet à la machine d'un inconnu une liste exploitable des bitcoins que vous détenez.

Comment cela fonctionne

Statut : le filtrage par filtre de Bloom BIP37 a été désactivé par défaut dans Bitcoin Core 0.19.0 en novembre 2019, et les filtres de blocs compacts BIP157 et BIP158 ont repris la tâche des portefeuilles légers.

Un filtre de Bloom est un tableau de bits accompagné d'une poignée de fonctions de hachage. Pour insérer un élément, vous le hachez de plusieurs façons, prenez chaque résultat modulo la longueur du tableau, et mettez ces bits à un. Pour tester un élément, vous le hachez de la même façon et vous regardez. Si l'un de ces bits est à zéro, l'élément n'a certainement jamais été inséré ; s'ils sont tous à un, l'élément a probablement été inséré, ou d'autres insertions ont mis les mêmes bits à un. Les faux négatifs sont impossibles. Les faux positifs sont possibles, et leur taux est le paramètre de réglage.

Le BIP37 a fixé l'arithmétique. Un filtre est limité à 36 000 octets et 50 fonctions de hachage, et le hachage est la version 3 de la fonction Murmur de 32 bits initialisée avec le numéro de hachage multiplié par 0xFBA4C795 plus un ajustement choisi par le client. Trois messages le pilotent : filterload installe un filtre sur la connexion, filteradd l'étend, filterclear le supprime. Une fois un filtre défini, le pair répond à une demande de bloc par un merkleblock contenant l'en-tête de 80 octets, les transactions correspondantes et les branches de Merkle prouvant qu'elles appartiennent à ce bloc. Le BIP111 a ensuite ajouté un bit de service NODE_BLOOM pour qu'un nœud puisse annoncer s'il acceptait de jouer le jeu.

L'argument de confidentialité reposait entièrement sur ce taux de faux positifs. Élargissez le filtre, captez les transactions d'inconnus en même temps que les vôtres, et un observateur est censé ne pas pouvoir distinguer les unes des autres. Cela ne tient pas. Des travaux universitaires publiés en 2014 ont montré qu'un filtre portant un nombre réaliste d'adresses en livre la plupart, et que deux filtres chargés par le même portefeuille peuvent être croisés pour ôter complètement le camouflage. Se reconnecter à un nouveau pair avec un nouveau filtre aggrave le problème au lieu de le résoudre.

L'autre défaillance était plus simple à expliquer. Servir un filtre signifie parcourir des blocs sur le disque à la demande d'un inconnu, si bien que n'importe quel pair pouvait faire accomplir à un nœud doté d'un disque mécanique une quantité énorme de travail non rémunéré. C'est cet argument de déni de service, et non la recherche sur la confidentialité, que les notes de version 0.19.0 mettent en avant.

Où le rencontre-t-on

Les filtres de Bloom subsistent surtout dans des logiciels écrits avant 2019 et dans des fichiers de configuration qui contournent leur absence.

Les portefeuilles Android construits sur la bibliothèque bitcoinj utilisaient le BIP37 comme unique interface de chaîne, et certains sont encore installés. Bisq en avait besoin aussi, c'est pourquoi sa documentation indiquait autrefois qu'il fallait ajouter peerbloomfilters=1 à la configuration de votre propre nœud. Cette ligne est révélatrice : quand un logiciel vous demande de réactiver le filtrage par filtre de Bloom sur un nœud que vous exploitez, il demande une technique que le client de référence a désactivée pour de bonnes raisons.

Le remplacement moderne fonctionne en sens inverse. Avec le BIP157 et le BIP158, le nœud construit un filtre par bloc et le publie à tout le monde, et le portefeuille fait la correspondance sur son propre matériel, de sorte que rien sur vos adresses ne quitte l'appareil.

Filtre de Bloom vs SPV

Un filtre de Bloom était un mécanisme de livraison ; la vérification de paiement simplifiée est un modèle de confiance, et confondre les deux fait croire que le modèle est mort avec le mécanisme. SPV signifie vérifier qu'une transaction se trouve sous la racine de Merkle d'un en-tête dans la chaîne au travail cumulé le plus élevé, sans valider le reste du contenu de cette chaîne. Ce raisonnement n'a pas changé. Ce qui a changé, c'est la façon dont un portefeuille léger trouve les transactions qui valent la peine d'être vérifiées : il diffusait autrefois un aperçu approximatif de ses propres adresses en espérant que cela suffise, et il télécharge désormais un filtre par bloc et le teste chez lui.