MSG_FILTERED_WITNESS_BLOCK

MSG_FILTERED_WITNESS_BLOCK est le code d'inventaire 0x40000003, réservé lorsque les règles de pair de segwit ont été écrites en 2016 et jamais doté d'une implémentation. Bitcoin Core le porte comme entrée d'énumération avec un commentaire qui consigne exactement cela. La fonctionnalité de portefeuille léger qu'il aurait étendue, le filtrage par bloom du BIP37, a été désactivée par défaut dans Bitcoin Core 0.19.0, ce qui ne vous concerne que si le portefeuille de votre téléphone s'appuie encore dessus.

Comment cela fonctionne

Statut : réservé et jamais construit. Le BIP144 a nommé le type ; Bitcoin Core le porte comme entrée d'énumération dans src/protocol.h avec un commentaire qui consigne qu'aucun gestionnaire n'existe. Le filtrage BIP37 qu'il aurait servi est désactivé par défaut depuis Bitcoin Core 0.19.0 en novembre 2019, et les filtres de blocs compacts des BIP157 et BIP158 le remplacent.

Comprendre cette lacune, c'est comprendre ce qu'était un bloc filtré. Un client léger utilisant le BIP37 envoie un message filterload décrivant, approximativement, les adresses qui l'intéressent. Il demande ensuite le type d'inventaire 3, MSG_FILTERED_BLOCK, et le nœud qui le sert répond par un message merkleblock : l'en-tête de bloc de 80 octets, un nombre de transactions, une branche de merkle partielle et un champ de bits indiquant dans quel sens parcourir l'arbre. Les transactions correspondantes suivent en messages distincts. Le client vérifie que chacune d'elles dépend bien de la racine de merkle de l'en-tête, et il le fait à partir des txid seuls.

Les témoins n'entraient jamais dans ce calcul. Comme la racine de merkle est construite à partir des txid, un client léger peut prouver l'inclusion sans une seule signature, de sorte que les transactions de suivi étaient envoyées dépouillées. Le type réservé 3 auquel on ajoute l'indicateur de témoin, 0x40000003, aurait permis à un client de demander ces transactions en entier. Personne ne l'a construit, parce qu'aucun producteur de portefeuilles légers ne voulait davantage de BIP37.

La raison est la confidentialité, pas l'effort. Le filtre qu'un client téléverse indique au nœud qui le sert à peu près quelles adresses lui appartiennent, et les travaux de recherche menés jusqu'au milieu des années 2010 ont montré que ces filtres fuitaient bien plus que prévu. La réponse de Bitcoin Core a été de cesser de les servir par défaut plutôt que de réparer la conception. Le BIP158 inverse le flux : le nœud construit un petit filtre à codage Golomb par bloc, réglé sur un taux de faux positifs d'un sur 784 931, et le publie. Le client télécharge les filtres, les teste localement et ne récupère un bloc entier qu'en cas de correspondance, de sorte que le serveur n'apprend rien sur les adresses qui l'intéressaient.

Où le voir

Presque nulle part, ce qui est la réponse honnête pour quiconque trouve MSG_FILTERED_WITNESS_BLOCK dans un tableau de référence.

Cherchez la constante dans Bitcoin Core et vous trouvez un seul membre d'énumération. Les implémentations alternatives comme btcd reprennent le nom dans leurs paquets de protocole par souci d'exhaustivité, là encore sans comportement derrière. Aucun portefeuille ne l'a jamais envoyé.

Là où le sujet touche vraiment un acheteur, c'est dans la façon dont un portefeuille mobile obtient ses données. Si un portefeuille se décrit comme SPV et se connecte à des nœuds publics aléatoires avec des filtres bloom, il utilise un mécanisme que l'implémentation de référence a cessé de servir par défaut il y a des années, et il indique à ces nœuds quelque chose sur vos adresses. Les portefeuilles construits sur les filtres de blocs compacts, la conception qui sous-tend Neutrino de lnd, demandent bien moins. Un portefeuille pointé vers le serveur de son éditeur est la troisième option, et la plus courante : rapide, privé vis-à-vis des inconnus, et entièrement visible pour l'éditeur.

MSG_FILTERED_WITNESS_BLOCK vs bloc de merkle

Un bloc de merkle est la réponse ; MSG_FILTERED_WITNESS_BLOCK est une demande qui n'a jamais été reliée à quoi que ce soit pour en produire une. Le message merkleblock est une structure réelle et implémentée qui prouve qu'un ensemble de transactions appartient à un bloc sans envoyer le bloc. La variante témoin réservée n'aurait changé que ce qui venait après cette preuve, à savoir si les transactions correspondantes arrivaient avec leurs signatures. Comme les preuves d'inclusion fonctionnent à partir des txid, la fonctionnalité manquante n'a rien coûté à personne.