Une nouvelle proposition d’amélioration pour Bitcoin (BIP), appelée « soft fork temporaire pour réduire les données », suggère de modifier temporairement les règles de consensus du réseau pour restreindre l’inclusion de métadonnées (texte, images, etc.) intégrées dans les transactions.
Un soft fork est un type de mise à jour qui introduit de nouvelles règles compatible avec les précédents et cela ne nécessite que le consensus d’une partie des participants.
Dans ce cas, l’objectif est d’atténuer la propagation des transactions avec des données non monétaires, que de nombreux utilisateurs considèrent comme une forme de “spam” ou même un canal possible pour stocker contenu illégal dans Bitcoin.
Le référentiel de l’initiative a été publié le 24 octobre par un développeur anonyme sous le pseudonyme de Dathon Ohm.
Ce collaborateur anonyme est également attribué via la Bitcoin Dev List (liste de diffusion des développeurs Bitcoin, où sont discutées les propositions techniques et les mises à jour du protocole) la paternité du BIP à Luke Dashrmainteneur bien connu du client Bitcoin Knots et l’un des principaux critiques de Bitcoin Core.
La motivation derrière le changement proposé
Le texte de la proposition met en garde contre les implications de la récente version de Bitcoin Core v30, qui augmenté la taille du champ autorisé OP_RETOUR dans des transactions allant jusqu’à 100 000 kilo-octets (ko).
Cet espace peut désormais intégrer de grands volumes d’informations non financières, notamment du texte ou des images.
La principale préoccupation est que si une transaction contient des fichiers contenant du matériel illégal, les opérateurs de nœuds Bitcoin (qui doivent valider et stocker toutes les transactions) pourrait être confronté à des risques juridiques ou éthiques en préservant ce contenu.
Comment ce BIP fonctionnerait-il dans Bitcoin ?
Le PIF proposé introduit des limites temporaires à la taille de certaines données au sein des transactions.
Plus précisément, le BIP établit que les nouvelles règles s’appliqueraient du bloc 934 864 (estimé pour le 1er février 2026) au bloc 987 424, prévu pour le 1er février 2027.
Pendant cette période, les transactions et les blocages devront se conformer à certaines restrictions supplémentaires. Parmi eux :
- Remplacer les nouveaux scripts sortir (scriptPubKeys ou script de clé publique) qui dépassent 34 octets, sauf ceux qui commencent par OP_RETURN, auquel cas Jusqu’à 83 octets sont autorisés.
- Rejeter toute instruction de données avec des charges utiles supérieures à 256 octets, sauf dans les cas définis par BIP-16.
Par ailleurs, le fourchette souple Il envisage deux méthodes d’activation. La première, proactive, s’appuierait sur une activation prévue début 2026, afin de mettre en œuvre les règles sans conflits si aucune donnée problématique n’apparaît sur la chaîne.
La seconde, réactive, permettrait une réorganisation rétroactive de la chaîne pour invalider les éventuels blocs contenant des contenus illégaux et activer immédiatement les nouvelles règles.
Enfin, l’auteur admet que contrairement à la plupart des soft forks, celui-ci pourrait provoquer une rupture temporaire de la chaînecar cela impliquerait de rejeter les blocs déjà extraits.
Cependant, il fait valoir que cette conséquence serait nécessaire pour empêcher que du matériel illicite soit enregistré de manière permanente.
