La proposition BIP-110 de Bitcoin a atteint 2,64% de signalement des mineurs au 27 juillet 2026 à 8 h 40 (EDT), le bloc 961632 étant attendu autour du 9 août 2026. La proposition cible les inscriptions de type Ordinals et les charges utiles OP_RETURN surdimensionnées via des limites temporaires de données de transaction. Le pool Ocean mining et des opérateurs indépendants plus petits mènent l’activité de signalement, tandis que de grands pools, dont Antpool, ViaBTC et F2pool, n’ont pas évolué pour soutenir la mesure. Le BIP-110 utilise un processus d’activation modifié de type BIP-9 qui inclut une fenêtre de signalement obligatoire à partir du bloc 961632 ; durant cette période, les nœuds appliquant la proposition refuseront les blocs ne comportant pas le bit de version 4, quel que soit le proof-of-work, créant un risque de chaînes concurrentes si un soutien large des mineurs ne se matérialise pas avant la date limite.
Le signalement du BIP-110 atteint 2,64% à l’approche de la date limite
À 8 h 40, heure de l’Est, le 27 juillet, le sommet de la chaîne se situait au bloc 959842. Environ 1 790 blocs restent avant le bloc 961632, le point à partir duquel les nœuds exécutant le logiciel BIP-110 commenceront à refuser les blocs qui ne signalent pas le bit de version 4. À l’allure moyenne de Bitcoin (en dix minutes par bloc), cette hauteur devrait être atteinte le 9 août 2026, ou autour de cette date.
Le BIP-110, officiellement appelé Reduced Data Temporary Softfork, propose de limiter la taille de certains champs de données utilisés dans les transactions Bitcoin. Les règles ciblent principalement les inscriptions de type Ordinals, les charges utiles OP_RETURN surdimensionnées et des usages similaires très gourmands en données, tout en laissant inchangés les transferts Bitcoin ordinaires axés finance, les dépenses Taproot de chemin clé et les opérations standard de canaux Lightning. S’il est activé, les restrictions débuteront au bloc 965664 et expireront automatiquement après 52 416 blocs.
![Block signaling screenshot]()
Le signalement est passé d’un niveau inférieur à 1% il y a quelques semaines à une fourchette autour de 3%. Ocean continue de représenter la majeure partie de l’activité de signalement. Le reste du hashrate provient de mineurs indépendants et d’opérateurs plus petits, notamment Roughnecks, SoV, BIP110 Generic, Barefoot Mining, 234 Alberta, 888, Peer to Peer Money, Black Jade Advisors, Sazmining, Crestmont Fabrics, Datum Miner, SpammersGFY, Moonwalk, PyBLOCK-Datum, Just For Krypto et JAMIN.
Foundry, Antpool, ViaBTC et F2pool, les quatre pools responsables de la majeure partie du hashrate du réseau, ont montré peu d’évolution. La seule implémentation appliquant la proposition est un fork de Bitcoin Knots. Les nœuds joignables exécutant ce logiciel se situent aujourd’hui autour de 22%.
![Coin Dance node count screenshot]()
Foundry met en place un système de vote du hashrate côté client
Vers le 17 juillet 2026, Foundry a demandé à ses clients de voter pour savoir si le pool devait commencer à signaler pour le BIP-110. L’entreprise a lié le résultat directement au hashrate de ses clients, d’après un email envoyé aux participants du pool.
« La fenêtre de vote du pool Foundry USA Pool™ restera ouverte jusqu’à la date de clôture de la fenêtre de signalement, en amont du bloc 961 632 », a écrit le pool Foundry USA sur sa page de ressources dédiée au BIP-110.
La puissance de vote dépend du hashrate moyen de chaque client. Les clients qui ne répondent pas sont automatiquement comptés comme « Non », et la position par défaut de Foundry reste de signaler contre la proposition. Le pool ne basculera que si les votes « Oui » dépassent 51% du hashrate pondéré des participants : dans ce cas, il passera alors tous ses blocs en support de signalement.
Foundry représente entre environ 23% et 33% du hashrate global de Bitcoin, selon la période de mesure. Au 27 juillet 2026, aucun signe n’indique qu’un basculement se soit produit.
La page de ressources côté client de Foundry renvoie à la spécification du BIP, à la discussion initiale sur bitcoin-dev, aux critiques de Jameson Lopp, ainsi qu’à des commentaires d’Adam Back, Michael Saylor, Luke Dashjr et d’autres.
Une fenêtre de signalement obligatoire crée un mécanisme de rejet au bloc 961632
Une fois le bloc 961632 arrivé, les nœuds appliquant le BIP-110 refuseront les blocs minés par la majorité du réseau, car ils n’incluent pas le bit de version requis. Ces nœuds suivront à la place le nombre relativement faible de blocs qui signalent.
Les nœuds historiques continueront d’accepter à la fois les blocs signalants et non signalants tout en suivant la chaîne qui présente le plus grand proof-of-work accumulé. Plusieurs observateurs indépendants ont mis en place des sites de monitoring dédiés qui suivent les paramètres d’activation, certains simulant la manière dont le processus pourrait se dérouler selon différents scénarios.
![BIP110 Situation Monitor screenshot]()
Le site de monitoring BIP110 Situation Monitor modélise une gamme d’issues possibles durant la fenêtre de signalement obligatoire. Sa page de simulation permet aux utilisateurs d’ajuster des variables, y compris le pourcentage de hashrate du réseau attendu pour soutenir le BIP-110. Une simulation avec 25% de hashrate dédié au BIP-110 aboutit à une scission de chaîne.
La chaîne reconnue par Bitcoin Core et minée par la très grande majorité du hashrate continuerait de produire des blocs à son rythme normal. Une chaîne minoritaire constituée uniquement de mineurs signalants progresserait beaucoup plus lentement, jusqu’à atteindre son prochain ajustement de difficulté au terme de 2 016 blocs.
La trajectoire d’activation du BIP-110 diffère de Segwit et Taproot
Le BIP-110 suit une trajectoire de déploiement différente de celle des deux dernières grandes soft forks de Bitcoin. La proposition a été lancée le 1er décembre 2025, en utilisant un processus modifié de BIP-9. Elle exigeait 1 109 blocs sur 2 016, soit 55%, qui signalent pendant une seule période de difficulté afin de verrouiller l’activation tôt. Si ce seuil n’était jamais atteint, la proposition avançait vers un verrouillage forcé au bloc 963 648 avant d’activer une période de difficulté plus tard au bloc 965 664.
Du bloc 961 632 au 963 647, les nœuds appliquant le BIP-110 rejettent chaque bloc qui ne signale pas le bit de version 4, quelle que soit la quantité de proof-of-work qui le soutient. Cette approche diffère à la fois de Segwit et de Taproot, où les nœuds non mis à niveau continuent d’accepter la chaîne avec le proof-of-work le plus fort durant l’activation.
La comparaison historique la plus proche concerne la soft fork UASF (user-activated soft fork) de BIP-148 en 2017, qui tentait elle aussi de faire pression sur les mineurs via des exigences de signalement obligatoires. Cette confrontation s’est finalement terminée sans scission persistante de chaîne après que suffisamment de hashrate a basculé avant la date limite.
La proposition cible les inscriptions et les charges utiles OP_RETURN
Le BIP-110 a été rédigé sous le nom de Dathon Ohm. Des versions antérieures circulaient sous la désignation BIP-444 avant d’être acceptées dans le dépôt des BIPs.
Les partisans soutiennent que les inscriptions, les jetons de type BRC-20, et des charges utiles OP_RETURN de plus en plus larges augmentent le coût d’exploitation d’un nœud complet, faussent le marché des frais de Bitcoin et détournent des ressources du réseau de l’objectif prévu de Bitcoin en tant que système de paiement et de règlement.
« Supprimer des règles, c’est une hard fork », a expliqué Luke Dashjr, partisan du BIP-110 et développeur de Bitcoin Knots, sur X au début du mois de juillet. « Cela inclut des règles programmées comme les réductions de subventions, et oui, même BIP110. Rejeter BIP110 est une tentative de hard fork controversée. » Dashjr a ajouté : « Et contrairement aux soft forks, les hard forks ont besoin d’un consensus pour réussir. Il n’y a pas de consensus pour rejeter BIP110. »
Les opposants s’accordent généralement sur le fait que du spam existe, mais divergent sur la question de savoir si le mécanisme d’activation du BIP-110 constitue la bonne solution. « L’utilisation d’espace de bloc OP_RETURN n’a pas beaucoup augmenté depuis la publication de Bitcoin Core v30. Les OP_RETURN surdimensionnés peuvent être un peu plus élevés, mais ils consomment encore moins de 0,1% de l’espace de bloc », a écrit Alex Thorn, responsable de la recherche chez Galaxy Digital, sur X. Thorn a poursuivi : « BIP-110 est une réponse extrêmement perturbatrice et dangereuse compte tenu de l’impact minime de ces éléments prunables [transactions]. »
FAQ
Qu’est-ce que le BIP-110 et quand sa fenêtre de signalement obligatoire commence-t-elle ?
Le BIP-110, officiellement appelé Reduced Data Temporary Softfork, propose de limiter la taille de certains champs de données utilisés dans les transactions Bitcoin, en ciblant principalement les inscriptions de type Ordinals et les charges utiles OP_RETURN surdimensionnées. La fenêtre de signalement obligatoire commence au bloc 961632, attendue autour du 9 août 2026, durant laquelle les nœuds appliquant le BIP-110 refuseront les blocs qui ne signalent pas le bit de version 4.
Quelle quantité de soutien des mineurs le BIP-110 a-t-il au 27 juillet 2026 ?
Au 27 juillet 2026 à 8 h 40 (EDT), le signalement du BIP-110 se situe à environ 2,64%. Le pool Ocean mining et des opérateurs indépendants plus petits mènent l’activité de signalement, tandis que de grands pools, dont Foundry, Antpool, ViaBTC et F2pool, n’ont pas bougé pour soutenir la proposition. Les nœuds joignables exécutant le logiciel d’application du BIP-110 se situent autour de 22%.
Comment le système de vote de Foundry pour le BIP-110 fonctionne-t-il ?
Foundry a mis en place un système de vote basé sur le hashrate côté client vers le 17 juillet 2026, où la puissance de vote dépend du hashrate moyen de chaque client. Les clients qui ne répondent pas sont automatiquement comptés comme « Non », et la position par défaut de Foundry reste de signaler contre la proposition. Seuls les votes « Oui » dépassant 51% du hashrate pondéré des participants feront basculer le pool et passeront l’ensemble de ses blocs en support de signalement.
