Dans cet article
- TL;DR
- La CVE que Luke Dashjr a déposée contre Bitcoin Core
- Ce que le mécanisme fait réellement
- Pourquoi Bitcoin Core a qualifié cela de politique et non de consensus
- Deux clients ont divergé
- Deux ans plus tard Bitcoin Core a multiplié la limite par 1200
- Ce que cet épisode montre sur la gouvernance Bitcoin
TL;DR
Bitcoin CVE-2023-50428 a été déposée par Luke Dashjr le 2023-12-09 contre Bitcoin Core jusqu'à la version 26.0. L'entrée NVD, notée 5.3 MEDIUM et marquée Disputed, indique que la limite de politique -datacarriersize peut être contournée en enveloppant des données dans une enveloppe OP_FALSE OP_IF dans le witness du script-path Taproot. Bitcoin Core a qualifié cela de question de politique, pas de rupture de consensus, et n'a jamais livré de correctif. Bitcoin Core 30.0 sorti le 2025-10-10 a porté la limite -datacarriersize par défaut de 83 octets à 100 000 octets via la PR #32359, une augmentation de 1 200x, soit l'inverse de ce que demandait la CVE. Bitcoin Knots a patché le filtre dans 25.1.knots20231115 et est passé d'environ 69 noeuds en janvier 2024 à environ 4 240 sur 23 842 noeuds accessibles en septembre 2025. Les fonds n'ont jamais été en danger. Le consensus n'a jamais été rompu. Voilà la gouvernance Bitcoin quand le client de référence et un client alternatif appliquent des politiques opposées sur le même réseau.
La CVE que Luke Dashjr a déposée contre Bitcoin Core
Je travaille dans l'espace de l'auto-conservation crypto. Le débat sur les inscriptions divise des salles pleines de développeurs Bitcoin depuis début 2023. Luke Dashjr a déposé CVE-2023-50428 le 2023-12-09 contre Bitcoin Core jusqu'à la version 26.0. L'argument était simple. Les inscriptions intègrent une charge utile arbitraire dans les données witness de transaction via un motif de script que le filtre -datacarriersize existant ignore. Le mainteneur de Knots a qualifié cela de vulnérabilité. Les mainteneurs de Core ont appelé cela un choix de politique.
L'entrée NVD porte un score CVSS v3.1 de 5.3 MEDIUM avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. L'impact sur la confidentialité est Aucun. L'impact sur l'intégrité est Aucun. Seule la disponibilité affiche un impact Faible. Pas de fonds en danger. Pas de clés en danger. Pas de blocs invalides. Une perte de capacité de relais des noeuds, rien de plus.
Le statut NVD indique Disputed. Les mainteneurs de Bitcoin Core ont examiné le patch de filtre sur l'issue bitcoin/bitcoin #29187 et ont refusé de le merger. Bitcoin Knots a livré son propre filtre dans la version 25.1.knots20231115 le même mois.
Ce que le mécanisme fait réellement
Les transactions Bitcoin peuvent transporter de petites quantités de données arbitraires. Le chemin classique est OP_RETURN. La politique de noeud -datacarriersize limitait les charges utiles OP_RETURN à 83 octets par défaut (80 octets de charge utile plus 3 octets d'overhead d'opcode). Ce plafond a toujours été un filtre de politique, pas une règle de consensus.
La CVE décrit un autre chemin. Dans une dépense de script-path Taproot, le witness peut contenir un script arbitraire. Une inscription enveloppe sa charge utile dans OP_FALSE OP_IF <data chunks> OP_ENDIF. Le OP_FALSE garantit que la branche conditionnelle ne s'exécute jamais, donc les données sont traitées comme des pushdata inertes plutôt que comme du code exécutable. Le filtre -datacarriersize n'a jamais regardé ce chemin. Une charge utile de taille arbitraire passait à travers.
Contournement de politique, pas rupture de consensus. Chaque transaction d'inscription reste valide selon les règles de consensus. Les mineurs les incluent. Les noeuds complets les acceptent. Seul un filtre de relais saute, et seulement sur les noeuds qui l'appliquaient.
Pourquoi Bitcoin Core a qualifié cela de politique et non de consensus
La position de Core reposait sur deux points techniques et un point de gouvernance.
Côté technique. Les transactions citées sont valides selon le consensus. Les opérateurs de noeuds peuvent déjà configurer leurs propres politiques de relais. Forcer le client de référence à bloquer des transactions valides globalement serait une intervention bien plus lourde que les inscriptions elles-mêmes.
Côté gouvernance, plus délicat. Bitcoin Core n'a pas de mandat pour gagner des combats sociaux. Il livre l'implémentation de référence. Les opérateurs en désaccord peuvent faire tourner des clients alternatifs sans diviser le consensus. Bitcoin Knots existait précisément pour que ceux qui jugeaient le relais d'inscriptions nuisible aient un chemin opt-in.
Casey Rodarmor a lancé Ordinals sur le mainnet Bitcoin le 2023-01-21. L'inscription #0 a été créée le 2022-12-14. Quand la CVE a été déposée en décembre 2023, la technique tournait sur le mainnet depuis presque un an. Trop tard pour rembobiner.
Deux clients ont divergé
Bitcoin Core a refusé le patch de filtre. Les transactions d'inscription sont restées éligibles au relais sous la politique Core par défaut.
Bitcoin Knots 25.1.knots20231115 a livré le filtre. L'inspecteur Knots lit le witness à la recherche d'une enveloppe OP_FALSE OP_IF et abandonne la transaction au relais si la charge utile dépasse le plafond configuré.
Les deux clients appliquent les mêmes règles de consensus. Les deux valident les mêmes blocs. Ils diffèrent sur ce qu'ils relaient avant le minage.
L'adoption de Knots a servi de baromètre. Les noeuds Knots accessibles sont passés d'environ 69 en janvier 2024 à environ 4 240 sur 23 842 noeuds accessibles début septembre 2025, soit environ 17,78 pourcent du réseau en écoute. Le pic vient du débat v30.0, pas du dépôt initial de la CVE.
Deux ans plus tard Bitcoin Core a multiplié la limite par 1200
Bitcoin Core 30.0 est sorti le 2025-10-10. Une ligne des notes de version a recadré tout l'épisode.
PR #32359 de Peter Todd a porté la limite -datacarriersize par défaut de 83 octets à 100 000 octets. Multiplication par 1 200. La même PR a aussi supprimé le plafond sur le nombre de sorties OP_RETURN par transaction. Les opérateurs qui voulaient l'ancien comportement pouvaient toujours passer -datacarriersize=83 au démarrage.
Deux ans après qu'une CVE a demandé à Core de resserrer le filtre OP_RETURN, Core a sorti une version qui l'a retiré. Le raisonnement du thread de la PR : l'application était devenue ingagnable. Les inscriptions avaient déjà contourné la limite via les enveloppes witness. Le plafond OP_RETURN pénalisait le seul chemin conçu pour de petites quantités de métadonnées arbitraires tout en laissant le chemin non intentionnel grand ouvert. Les mainteneurs ont présenté le changement comme une symétrie, pas une capitulation.
Appelez ça comme vous voulez. Le filtre que la CVE demandait à Core d'étendre est maintenant configuré par défaut pour ignorer plus de cent kilooctets par transaction.
Bitcoin Knots a continué à livrer son propre filtre plus strict en parallèle. La v30.0 a provoqué le pic d'adoption de Knots en septembre 2025.
Ce que cet épisode montre sur la gouvernance Bitcoin
Bitcoin n'a pas de PDG. Pas de conseil d'administration. Pas de moyen de forcer un patch de sécurité sur une implémentation de référence. Pour un regard plus approfondi sur le fonctionnement du protocole, voir Plongée Technique.
CVE-2023-50428 testait une seule chose : le processus social autour de Bitcoin Core cédait-il sous pression d'une CVE déposée. Réponse : non. La CVE est devenue un enregistrement public. Le patch n'est pas devenu une valeur par défaut. Deux ans de débat plus tard, Core a pris la direction opposée.
Le système a fonctionné comme prévu, pas comme cassé. Un développeur en désaccord a livré un autre client. Les opérateurs qui étaient d'accord avec lui ont fait tourner ce client. L'implémentation de référence a fixé des valeurs par défaut qui correspondaient à la réalité on-chain. Le réseau a continué à produire des blocs. Pas de fonds en danger. Pas de consensus rompu.
Cherchiez-vous un incident de sécurité dans cette CVE, il n'y en a pas. Cherchiez-vous un jalon de gouvernance, le voilà : un désaccord déposé, deux clients, un réseau qui n'exige pas l'accord unanime pour continuer à tourner, et une valeur par défaut qui finit par rattraper la réalité.
Pour une hygiène de wallet qui tient quel que soit le débat de politique de relais, voir le guide d'auto-conservation Bitcoin et le guide brute-force BIP-39. Pour l'autre côté de l'histoire des inscriptions, voir Bitcoin Ordinals Expliqué.
Lectures complémentaires :
- CVE-2023-50428 NVD Detail
- CVE-2023-50428 cve.org Record
- bitcoin/bitcoin Issue #29187
- Bitcoin Core 30.0 Release Notes
- release-notes-30.0.md on GitHub
- PR #32359 Remove arbitrary limits on OP_RETURN datacarrier outputs
- Ordinals Protocol Docs
Nouveau dans Bitcoin ? Commencer par le Chapitre 1. Huit minutes suffisent.
Vous voulez l'image complète ? Lire les 19 chapitres gratuitement ou commander le livre physique.
